Download presentation
Presentation is loading. Please wait.
Published byChloe Wiggins Modified over 8 years ago
1
Computer Networks Group Universität Paderborn Computer Networks Chapter 8: Transport layer Holger Karl
2
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer2 Goal of this chapter We will discuss the mechanisms in addition to congestion control that are required to build a reliable, connection- oriented, end-to-end transport protocol With TCP as the evident case study, intermixed with the presentation We will draw heavily on the material from the link layer, as there many similar problems are solved in similar fashion – e.g., sliding window for error control A brief discussion of other transport protocols complements the chapter Namely, UDP and RPC
3
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer3 Overview Services & addressing Connection setup Connection release Flow control Timer and timeouts TCP summary UDP & RPC Performance issues
4
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer4 Transport protocols – Services to upper layer Connection-less and connection-oriented transport service Connection management necessary as auxiliary service – setup and teardown Reliable or unreliable transport In-order, all packets Be a good citizen in the network – perform congestion control Allow several transport endpoints in a single host Demultiplexing Support different interaction models Byte stream, messages, remote procedure invocation
5
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer5 Addressing Provide multiple service access points to multiplex several applications SAPs can identify connections or data flows E.g., “port numbers” Dynamically allocated Predefined for “well- known services” – port 80 for Web server
6
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer6 Overview Services & addressing Connection setup Connection release Flow control Timer and timeouts TCP summary UDP & RPC Performance issues
7
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer7 Connection establishment How to establish a joint context, a connection, between sender and receiver? Note: only relevant in end-system, network layer assumed to be connection-less Naïve solution: Sender sends a CONNECTION REQUEST Receiver answers by a CONNECTION ACCEPTED Sender proceeds once that message is received CONNECTION REQUEST CONN ACCEPTED DATA
8
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer8 Failure of naïve solution Naïve solution fails in realistic networks Where packets can be lost, stored/reorder, and duplicated Example failure scenario All packets are duplicated and delayed Due to congestion, errors,... and re-routing, e.g. In a banking application, e.g. Result: two independent transactions performed, where only one was intended Problem are delayed duplicates Transfer money CONNECTION REQUEST CONN ACCEPTED TRANSFER OK CONN ACCEPTED ??? DROP OK ??? DROP OK
9
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer9 Adding an additional handshake First idea: the sender has to re-confirm to the receiver that it actually wants to set up this connection ! Add a third message to the connection setup phase Three-way handshake This third message can already carry data CONNECTION REQUEST CONN ACCEPTED CONN CONFIRMED
10
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer10 Is three-way handshake sufficient? No, it does not protect against delayed duplicates! Problem: If both the connection request and the connection confirmation are duplicated and delayed, receiver again has no way to ascertain whether this is fresh or an old copy Solution: Have the sender answer a question that the receiver asks! Actually: Put sequence numbers into connection request connection acknowledgement, and connection confirmation Have to be copied by the receiving party to the other side Connection only established if the correct number is provided
11
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer11 Three-way handshake + sequence numbers Two examples for critical cases (which are handled correctly): Connection request appears as an old duplicate: Connection request & confirmation appear as old duplicates:
12
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer12 Connection setup – further issues Further problems due to crashing nodes, need some memory Sequence numbers negotiated here are also used for the following data packets Terminology for TCP Connection setup – SYN (synchronize) packet Connection accepted – SYN/ACK packet (because both the previous sequence number is acknowledged and a new sequence number from the receiver is proposed) Connection confirmation – ACK packet (combined with DATA, as a rule) Problem: SYN attack – flooding with nonsense SYN packets
13
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer13 Connection identification in TCP A TCP connection is setup Between a single sender and a single receiver More precisely, between application processes running on these systems TCP can multiplex several such connections over the network layer, using the port numbers as Transport SAP identifiers A TCP connection is thus identified by a four tuple: (Source Port, Source IP Address, Destination Port, Destination IP Address)
14
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer14 Overview Services & addressing Connection setup Connection release Flow control Timer and timeouts TCP summary UDP & RPC Performance issues
15
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer15 Connection release Once connection context between two peers is established, releasing a connection should be easy Goal: Only release connection when both peers have agreed that they have received all data and have nothing more to say I.e., both sides must have invoked a “Close”-like service primitive It fact, it is impossible Problem: How to be sure that the other peer knows that you know that it knows that you know … that all data have been transmitted and that the connection can now safely be terminated? Analogy: Two army problem
16
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer16 Two army problem Coordinated attack Two armies form up for an attack against each other One army is split into two parts that have to attack together – alone they will lose Commanders of the parts communicate via messengers who can be captured Which rules shall the commanders use to agree on an attack date? Provably unsolvable if the network can loose messages How to coordinate?
17
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer17 Connection release in practice Two army problem equivalent to connection release But: when releasing a connection, bigger risks can be taken Usual approach: Three-way handshake again Send disconnect request (DR), set timer, wait for DR from peer, acknowledge it
18
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer18 Problem cases for connection release with 3WHS Lost ACK solved by (optimistic) timer in Host 2 Lost second DR solved by retransmission of first DR Timer solves (optimistically) case when 2 nd DR and ACK are lost
19
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer19 State diagram of a TCP connection TCP uses three-way handshake for connection setup and release FIN, FIN/ACK for release Complicated by ability to have asymmetric, have-open connections and data in transit while close is in progress (Partial) state diagram Expresses both “server” and “client” aspects Each has a separate copy Legend: event/action, segments all caps, local events normal capitalization
20
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer20 Overview Services & addressing Connection setup Connection release Flow control Timer and timeouts TCP summary UDP & RPC Performance issues
21
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer21 Flow control Recall: Flow control = prevent a fast sender from overrunning a slow receiver Similar issue in link and transport layer In transport layer more complicated Many connections, need to adapt the amount of buffer per connection dynamically (instead of just simply allocating a fixed amount of buffer space per outgoing link) Transport layer PDUs can differ widely in size, unlike link layer frames Network’s packet buffering capability clouds the picture
22
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer22 Flow control – buffer allocation In order to support outstanding packets, the sender either Has to rely on the receiver to process packets as they come in (packets must not be reordered) – unrealistic, or Has to assume that the receiver has sufficient buffer space available The more buffer, the more outstanding packets Necessary to obtain highly efficient transmission, recall bandwidth- delay product! How does sender have buffer assurance? Sender can request buffer space Receiver can tell sender: “I have X buffers available at the moment” For sliding window protocols: Influence size of sender’s send window
23
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer23 Example of flow control with ACK/permit separation Arrows show direction of transmission, “…” indicates lost packet Potential deadlock in step 16 when control PDU is lost and not retransmitted
24
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer24 Flow control – permits and acknowledgements Distinguish Permits (“Receiver has buffer space, go ahead and send more data”) Acknowledgements (“Receiver has received certain packets”) Should be separated in real-world protocols! Can be combined with dynamically changing buffer space at the received Due to, e.g., different speed with which the application actually retrieves received data from the transport layer Example: TCP
25
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer25 Send and receive buffers in TCP TCP maintains buffer at Sender, to assist in error control Receiver, to store packets not yet retrieved by application or received out of order Old TCP implementations used GoBack-N, discarded out-of-order packets Sending application LastByteWritten TCP LastByteSentLastByteAcked Receiving application LastByteRead TCP LastByteRcvd NextByteExpected SenderReceiver
26
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer26 TCP flow control: Advertised window In TCP, receiver can advertise size of its receiving buffer Buffer space occupied: (NextByteExpected-1) – LastByteRead Maximum buffer space available: MaxRcvdBuffer Advertised buffer space (Advertised window): MaxRcvdBuffer – ((NextByteExpected-1) – LastByteRead) Recall: Advertised window limits the amount of data that a sender will inject into the network TCP sender ensures that LastByteSent – LastByteAcked · AdvertisedWindow Equvialently: EffectiveWindow = AdvertisedWindow – (LastByteSent – LastByteAcked)
27
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer27 Nagle’s algorithm – self-clocking and windows Recall TCP self-clocking: Arrival of an ACK is an indication that new data can be injected into the network What happens when an ACK for only small amount of data (e.g., 1 byte arrives)? Send immediately? Network will be burdened by small packets (“silly window syndrome”) Nagle’s algorithm describes how much data TCP is allowed to send When application produces data to send if both available data and advertised window · MSS send a full segment else if there is unacked data in flight, buffer new data until MSS is full else send all the new data now
28
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer28 Overview Services & addressing Connection setup Connection release Flow control Timer and timeouts TCP summary UDP & RPC Performance issues
29
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer29 Timeout computations Timeouts necessary to protect against lost packets Timeouts should reflect round-trip time between sender and receiver Problem: RTTs can be highly variable, range over several orders of magnitude Has to be adapted dynamically Simple approach: Keep a running average of RTTs Computed by an autoregressive model: EstimatedRTT n = EstimatedRTT n-1 + (1- ) RTTSample n Timeout = 2 EstimatedRTT as a conservative choice Parameter smoothes estimation ( = 0.8 … 0.9, typically)
30
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer30 Problem: ACKs do not refer to a transmission! Simple algorithm described above cannot obtain correct RTT samples if packets have been retransmitted ACKs refer to data/sequence numbers, not to individual packets! Two examples: SenderReceiver Original transmission ACK SampleR TT Retransmission SenderReceiver Original transmission ACK SampleR TT Retransmission Solution: Do not take RTT samples for retransmitted packets (Karn/Partridge algorithm)
31
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer31 Problem: Variance not considered Previous estimation does not consider variance of RTTs If low, estimate is good; no need to set timeout = 2 * RTT If high, be more careful when computing timeout from RTTs; estimate is likely to be of low quality Jacobsen/Karels algorithm for new estimation: Difference n = SampleRTT n – EstimatedRTT n-1 EstimatedRTT n = EstimatedRTT n-1 + ( Difference n ) Deviation n = Deviation n-1 + (|Difference| n – Deviation n-1 ) Timeout n = EstimatedRTT n + Deviation n 2 (0,1) a constant, typically = 1, = 4 (in TCP) Deviation is an upper bound of standard deviation, but easier to compute
32
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer32 Timer and packet loss What happens after a packet loss? Recall Ethernet behavior: Become more and more careful, back off Same idea here: After packet loss detected by timeout, use successively larger timeout values Exponential backoff: Double timeout value for each additional retransmission The estimation of RTT and “basic” timeout value is performed as described on previous slide The multiplicative factor for exponential backoff is reset upon ACK arrival
33
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer33 Timeouts & timer granularity Timeout calculation can suffer from coarse-grained timer resolution in the operating system Example: some Unixes only have 500 ms resolution Also: firing a timer heavily depends on relatively precise timer interrupts to be available Sometimes, timeouts can happen only seconds after a packet has been transmitted – far too sluggish
34
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer34 Overview Services & addressing Connection setup Connection release Flow control Timer and timeouts TCP summary UDP & RPC Performance issues
35
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer35 TCP – Summary TCP consists of Reliable byte stream – error control via GoBack-N or Selective Repeat (depending on version) Congestion control – window-based, AIMD, slow start, congestion threshold Flow control – advertised receiver window Connection management – three-way handshake for setup and teardown TCP is perhaps the single most complicated and subtle protocol in the internet Many little details and extensions are not discussed here Interaction of TCP with other layers is more complicated than it looks (e.g., wireless) because of hidden, implicit assumptions max. TCP BandWidth Max. Segment Size Round Trip Time loss probability
36
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer36 TCP fairness & TCP friendliness TCP attempts to Adjust dynamically to the available bandwidth Fairly share this bandwidth among all connections I.e.: If n connections share a given bottleneck link, each connection obtains 1/n of its bandwidth Interaction with other protocols Bottleneck bandwidth depends on load of other protocols as well, e.g., UDP – which is NOT congestion-controlled I.e., UDP traffic can “push aside” TCP traffic Consequence: Transport protocols should be TCP friendly They should not consume more bandwidth than a TCP connection in a comparable situation
37
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer37 TCP header
38
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer38 Overview Services & addressing Connection setup Connection release Flow control Timer and timeouts TCP summary UDP & RPC Performance issues
39
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer39 A simple demultiplexer transport protocol – UDP An example for an unreliable, datagram protocol: User Datagram Protocol (UDP) Only real function: (de)multiplex several data flows onto the IP layer and back to the applications In addition: ensures packet’s correctness Checksum out of UDP header + data + “pseudoheader” (pivotal IP header fields) UDP header
40
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer40 Remote Procedure Call (RPC) UDP and TCP have essentially simple semantics: Transport data from A to B A bit like “goto” in sequential languages: no structure in data flow More complex interactions can be directly captured in communication primitives Example: Invocation of a procedure as a primitive, as opposed to two separate gotos ! Remote procedure call Remote object invocation is really the same thing from a communication perspective
41
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer41 Remote procedure call – Structure Important goal: transparency to caller/callee Achieved (partially) by stubs Caller (client) Client stub RPC protocol Return value Arguments ReplyRequest Callee (server) Server stub RPC protocol Return value Arguments ReplyRequest Network
42
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer42 Overview Services & addressing Connection setup Connection release Flow control Timer and timeouts TCP summary UDP & RPC Performance issues
43
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer43 A few words on performance Performance is still important … Measuring performance Measure relevant metrics Make sure that the sample size is big enough Make sure that samples are representative Be careful when using a coarse-grained clock Be sure that nothing unexpected is going on during your tests Caching can wreak havoc with measurements Understand what your are measuring and what is going on Be careful about extrapolating results Use a proper experimental design to finish in one human lifetime
44
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer44 System design for better performance CPU speed is more important than network speed Or interfaces like NIC $ CPU Reduce packet count to reduce software overhead Minimize context switches Minimize copying You can buy more bandwidth but not lower delay Avoiding congestion is better than recovering from it Avoid timeouts Optimize for the common case Depending on network: design for speed, not utilization Think about the right performance metric, it can be, e.g., energy efficiency rather than throughput or delay
45
WS 05/06, v 1.1Computer Networks - Ch. 8 - Transport layer45 Conclusion Transport protocols can be anything from trivial to highly complex, depending on the purpose they serve They determine to a large degree the dynamics of a network and – in particular – its stability It is trivial to build “faster” than TCP protocols, but they are unstable The interdependencies of various mechanisms in a transport protocols can be very subtle with big consequences E.g., fairness, coexistence of different TCP versions
Similar presentations
© 2024 SlidePlayer.com Inc.
All rights reserved.