Presentation is loading. Please wait.

Presentation is loading. Please wait.

Transport Layer 3-1 Fast Retransmit r time-out period often relatively long: m long delay before resending lost packet r detect lost segments via duplicate.

Similar presentations


Presentation on theme: "Transport Layer 3-1 Fast Retransmit r time-out period often relatively long: m long delay before resending lost packet r detect lost segments via duplicate."— Presentation transcript:

1 Transport Layer 3-1 Fast Retransmit r time-out period often relatively long: m long delay before resending lost packet r detect lost segments via duplicate ACKs. m sender often sends many segments back-to- back m if segment is lost, there will likely be many duplicate ACKs for that segment r If sender receives 3 ACKs for same data, it assumes that segment after ACKed data was lost: m fast retransmit: resend segment before timer expires

2 Transport Layer 3-2 Host A timeout Host B time X resend seq X2 seq # x1 seq # x2 seq # x3 seq # x4 seq # x5 ACK x1 triple duplicate ACKs

3 Transport Layer 3-3 outline r TCP m segment structure m reliable data transfer m flow control m congestion control

4 Transport Layer 3-4 TCP Flow Control r receive side of TCP connection has a receive buffer: r speed-matching service: matching send rate to receiving application’s drain rate r app process may be slow at reading from buffer sender won’t overflow receiver’s buffer by transmitting too much, too fast flow control IP datagrams TCP data (in buffer) (currently) unused buffer space application process

5 Transport Layer 3-5 TCP Flow control: how it works (suppose TCP receiver discards out-of-order segments)  unused buffer space: = rwnd = RcvBuffer-[LastByteRcvd - LastByteRead]  receiver: advertises unused buffer space by including rwnd value in segment header  sender: limits # of unACKed bytes to rwnd m guarantees receiver’s buffer doesn’t overflow IP datagrams TCP data (in buffer) (currently) unused buffer space application process rwnd RcvBuffer

6 Transport Layer 3-6 Next: Principles of Congestion Control

7 Transport Layer 3-7 Principles of Congestion Control Congestion: r informally: “too many sources sending too much data too fast for network to handle” r different from flow control! r manifestations: m lost packets (buffer overflow at routers) m long delays (queuing in router buffers)

8 Transport Layer 3-8 Causes/costs of congestion: scenario 1 r two senders, two receivers r one router, infinite buffers r large delays when congested unlimited shared output link buffers Host A in : original data Host B out

9 Transport Layer 3-9 Causes/costs of congestion: scenario 2 r one router, finite buffers r sender retransmission of lost packet finite shared output link buffers Host A in : original data Host B out ' in : original data, plus retransmitted data

10 Transport Layer 3-10 Causes/costs of congestion: scenario 3 r four senders r multihop paths r timeout/retransmit Q: what happens as number of senders increase? finite shared output link buffers Host A in : original data Host B out ' in : original data, plus retransmitted data

11 Transport Layer 3-11 TCP congestion control: r goal: TCP sender should transmit as fast as possible, but without congesting network m Q: how to find rate just below congestion level r decentralized: each TCP sender sets its own rate, based on implicit feedback: m ACK: segment received (a good thing!), network not congested, so increase sending rate m lost segment: assume loss due to congested network, so decrease sending rate

12 Transport Layer 3-12 TCP congestion control: bandwidth probing r “probing for bandwidth”: increase transmission rate on receipt of ACK, until eventually loss occurs, then decrease transmission rate m continue to increase on ACK, decrease on loss (since available bandwidth is changing, depending on other connections in network) ACKs being received, so increase rate X X X X X loss, so decrease rate sending rate time r Q: how fast to increase/decrease? TCP’s “sawtooth” behavior

13 Transport Layer 3-13 TCP Congestion Control: details r sender limits rate by limiting number of unACKed bytes “in pipeline”:  cwnd: differs from rwnd (how, why?)  sender limited by min(cwnd,rwnd) r roughly,  cwnd is dynamic, function of perceived network congestion rate = cwnd RTT bytes/sec LastByteSent-LastByteAcked  cwnd cwnd bytes RTT ACK(s)

14 Transport Layer 3-14 TCP Congestion Control: more details segment loss event: reducing cwnd r timeout: no response from receiver  cut cwnd to 1 r 3 duplicate ACKs: at least some segments getting through (recall fast retransmit)  cut cwnd in half, less aggressively than on timeout ACK received: increase cwnd r slowstart phase: m increase exponentially fast (despite name) at connection start, or following timeout r congestion avoidance: m increase linearly

15 Transport Layer 3-15 TCP Slow Start  when connection begins, cwnd = 1 MSS m example: MSS = 500 bytes & RTT = 200 msec m initial rate = 20 kbps r available bandwidth may be >> MSS/RTT m desirable to quickly ramp up to respectable rate r increase rate exponentially until first loss event or when threshold reached  double cwnd every RTT  done by incrementing cwnd by 1 for every ACK received Host A one segment RTT Host B time two segments four segments

16 Transport Layer 3-16 Transitioning into/out of slowstart ssthresh: cwnd threshold maintained by TCP  on loss event: set ssthresh to cwnd/2  remember (half of) TCP rate when congestion last occurred  when cwnd >= ssthresh : transition from slowstart to congestion avoidance phase slow start timeout ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0 retransmit missing segment timeout ssthresh = cwnd/2 cwnd = 1 MSS dupACKcount = 0 retransmit missing segment  cwnd > ssthresh cwnd = cwnd+MSS dupACKcount = 0 transmit new segment(s),as allowed new ACK dupACKcount++ duplicate ACK  cwnd = 1 MSS ssthresh = 64 KB dupACKcount = 0 congestion avoidance

17 Transport Layer 3-17 TCP: congestion avoidance  when cwnd > ssthresh grow cwnd linearly  increase cwnd by 1 MSS per RTT m approach possible congestion slower than in slowstart  implementation: cwnd = cwnd + MSS/cwnd for each ACK received  ACKs: increase cwnd by 1 MSS per RTT: additive increase  loss: cut cwnd in half (non-timeout-detected loss ): multiplicative decrease AIMD AIMD: Additive Increase Multiplicative Decrease

18 Transport Layer 3-18 Popular “flavors” of TCP ssthresh TCP Tahoe TCP Reno Transmission round cwnd window size (in segments)

19 Transport Layer 3-19 Summary: TCP Congestion Control  when cwnd < ssthresh, sender in slow-start phase, window grows exponentially.  when cwnd >= ssthresh, sender is in congestion- avoidance phase, window grows linearly.  when triple duplicate ACK occurs, ssthresh set to cwnd/2, cwnd set to ~ ssthresh  when timeout occurs, ssthresh set to cwnd/2, cwnd set to 1 MSS.

20 Transport Layer 3-20 UDP r multimedia apps often do not use TCP m do not want rate throttled by congestion control r instead use UDP: m pump audio/video at constant rate, tolerate packet loss

21 Transport Layer 3-21 UDP: User Datagram Protocol [RFC 768] r “no frills,” “bare bones” Internet transport protocol r “best effort” service, UDP segments may be: m lost m delivered out of order to app r connectionless: m no handshaking between UDP sender, receiver m each UDP segment handled independently of others Why is there a UDP? r no connection establishment (which can add delay) r simple: no connection state at sender, receiver r small segment header r no congestion control: UDP can blast away as fast as desired

22 Transport Layer 3-22 UDP: more r often used for streaming multimedia apps m loss tolerant m rate sensitive r other UDP uses m DNS m SNMP r reliable transfer over UDP: add reliability at application layer m application-specific error recovery! source port #dest port # 32 bits Application data (message) UDP segment format length checksum Length, in bytes of UDP segment, including header


Download ppt "Transport Layer 3-1 Fast Retransmit r time-out period often relatively long: m long delay before resending lost packet r detect lost segments via duplicate."

Similar presentations


Ads by Google