Download presentation
Presentation is loading. Please wait.
1
Transport Layer 3-1 outline r TCP m segment structure m reliable data transfer m flow control m congestion control
2
Transport Layer 3-2 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
3
Transport Layer 3-3 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
4
Transport Layer 3-4 Next: Principles of Congestion Control
5
Transport Layer 3-5 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)
6
Transport Layer 3-6 Causes/costs of congestion r four senders r multihop paths r Loss/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
7
Transport Layer 3-7 TCP congestion control: cwnd 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 each TCP sender sets its own rate, called congestion window (cwnd) based on implicit feedback: m ACK: segment received (a good thing!), m network not congested m so increase sending rate m lost segment: assume loss due to congested network, so decrease sending rate
8
Transport Layer 3-8 TCP Slow Start Host A one segment RTT Host B time two segments four segments
9
Transport Layer 3-9 TCP: congestion avoidance Increasing sending rate: r How far would the doubling of cwnd go? r Till, it reaches a threshold r After that it increases linearly r Decrease sending rate r Set the threshold value to half of current cwnd loss: decrease cwnd to 1 and start the slow- start again What if a loss happens?
10
Transport Layer 3-10 Popular “flavors” of TCP ssthresh TCP Tahoe TCP Reno Transmission round cwnd window size (in segments)
11
Transport Layer 3-11 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 loss/timeout occurs, ssthresh set to cwnd/2, cwnd set to 1
12
Transport Layer 3-12 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
13
Transport Layer 3-13 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
14
Transport Layer 3-14 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
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.