outline r TCP m segment structure m reliable

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

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

TCP Flow control: how it works (currently) TCP data application IP unused buffer (in buffer) process datagrams space rwnd Rcv. Buffer (suppose TCP receiver discards out-of-order segments) r unused buffer space: r receiver: advertises unused buffer space by including rwnd value in segment header r sender: limits # of un. ACKed bytes to rwnd m guarantees receiver’s buffer doesn’t overflow = rwnd = Rcv. Buffer-[Last. Byte. Rcvd Last. Byte. Read] Transport Layer 3 -3

Next: Principles of Congestion Control Transport Layer 3 -4

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) Transport Layer 3 -5

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

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 Transport Layer 3 -7

TCP Slow Start RTT Host A Host B one segme two segme nt nts four segme nts time Transport Layer 3 -8

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 What if a loss happens? r Decrease sending rate r Set the threshold value to half of current cwnd r loss: decrease cwnd to 1 and start the slowstart again Transport Layer 3 -9

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

Summary: TCP Congestion Control r when cwnd < ssthresh, sender in slow-start phase, window grows exponentially. r when cwnd >= ssthresh, sender is in congestion- avoidance phase, window grows linearly. r when loss/timeout occurs, ssthresh set to cwnd/2, cwnd set to 1 Transport Layer 3 -11

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 Transport Layer 3 -12

UDP: User Datagram Protocol 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 [RFC 768] 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 Transport Layer 3 -13

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