Sliding Window Protocol and TCP Congestion Control Simon S. Lam Department of Computer Science Th The University of Texas at Austin U i it f T t A ti TCP Congestion Control (Simon S. Lam) 1 1
Reliable data transfer f important in app., transport, link layers characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) p y p ( ) TCP Congestion Control (Simon S. Lam) 2 2
Channel Abstractions Channel Abstract ons Lossy FIFO channel Lossy FIFO channel delivers a subsequence in FIFO order example: delivery service provided by a p y p y physical link Lossy, reordering, duplicative (LRD) L d i d li i (LRD) channel x mpl : d liv example: delivery service provided by IP or by s vic p vid d b IP b UDP protocol TCP Congestion Control (Simon S. Lam) 3 3
Sliding Window Protocol Consider an infinite array, Source, at the sender, and an infinite array, Sink, at the receiver. send window send window Source: Source: P1 s–1 s 0 1 2 a–1 a Sender acknowledged g unacknowledged g next expected r + RW – 1 received Sink : r 0 1 2 P2 delivered receive window Receiver SW send window size (s - a ≤ SW) d d ( ) RW receive window size 4 TCP Congestion Control (Simon S. Lam) 4
Sliding Windows in Action Sl d ng W ndows n Act on Data unit r has just been received by P2 Receive window slides forward Receive window slides forward P2 sends cumulative ack with sequence number it expects to receive next (r+3) number it expects to receive next (r+3) send window Source: P1 a–1 a s–1 s 0 1 2 Sender Sender acknowledged unacknowledged r+3 r + RW – 1 next expected Sink: P2 r 0 1 2 Receiver Receiver delivered receive window TCP Congestion Control (Simon S. Lam) 5 5
Sliding Windows in Action Sl d ng W ndows n Act on P1 has just received cumulative ack with r+3 as next expected sequence number 3 t t d b Send window slides forward send window Source: P1 s–1 s 0 1 2 a–1 a Sender acknowledged next expected next expected r + RW – 1 r RW 1 Sink: P2 r 0 1 2 Receiver delivered delivered receive window receive window TCP Congestion Control (Simon S. Lam) 6 6
Sliding Window protocol Functions provided error control (reliable delivery) in-order delivery flow and congestion control (by varying send window size) i d i ) TCP uses cumulative acks (needed for correctness) Oth Other kinds of acks (to improve performance) ki d f k selective nack selective ack (TCP SACK) selective ack (TCP SACK) bit-vector representing entire state of receive window (in addition to first sequence number of ( q window) TCP Congestion Control (Simon S. Lam) 7 7
Sliding Windows for Lossy FIFO Channels A small number of bits in packet header for A ll b f bi i k h d f sequence number Necessary and sufficient condition for correct Necessary and sufficient condition for correct operation: SW + RW ≤ MaxSeqNum Necessity : RW receive window size SW send window size SW send window size send window Source: P1 a–1 a 0 1 2 Sender unacknowledged acknowledged next expected next expected Sink: Sink: 0 1 2 P2 delivered receive window Receiver TCP Congestion Control (Simon S. Lam) 8 8
Sliding Windows for Lossy FIFO Ch Channels l Sufficiency can only be y y Interesting special cases g p demonstrated by using a SW = RW = 1 formal method to prove alternating-bit that the protocol that the protocol protocol l provides reliable in- SW = 7, RW = 1 order delivery. See out of order arrivals out-of-order arrivals Sh Shankar and Lam, ACM k d L ACM not accepted, e.g., TOPLAS , Vol. 14, No. 3, HDLC July 1992. y SW = RW TCP Congestion Control (Simon S. Lam) 9 9
Sliding Windows for LRD Channels Sl d ng W ndows for LRD Channels Assumption: Packets have bounded lifetime L Assumption: Packets have bounded lifetime L Be careful how fast sequence numbers are consumed (i.e., by arrival of data to be sent m ( , y f into network) (send rate) × L < MaxSeqNum TCP 32-bit sequence numbers counts bytes assumes that datagrams will be discarded by IP if too old if too old TCP Congestion Control (Simon S. Lam) 10 10
Window Size Controls Sending Rate W g RTT RTT 1 2 W 1 2 W Source time ACKs data Destination 1 2 W 1 2 W time ~ W packets per RTT when no loss TCP Congestion Control (Simon S. Lam) 11 11
Throughput Throughput Limit the number of unacked transmitted packets in the network to window size W k ts i th t k t i d si W W Max. throughput packets/sec M th h t k t / RTT × × W W MSS MSS = bytes/sec RTT (assuming no loss, MSS denotes maximum segment size) (assuming no loss, MSS denotes maximum segment size) Where did we apply Little’s Law? Answer : Consider the TCP send buffer Answer : Consider the TCP send buffer TCP Congestion Control (Simon S. Lam) 12 12
Throughput or send rate? Previous formula actually provides an upper bound Average number in the send buffer is less than W unless g m ff packet arrival rate to send buffer is infinite If a packet is lost in the network with probability p, then the average time in send buffer is (1 g ff (1 ) ) − × × + + × × p p RTT RTT p T p T O O Since T O > RTT, actual throughput is smaller. Th The throughput of a host s TCP send buffer is the th hp t f h st’s TCP s nd b ff is th host’s send rate into the network (including original transmissions and retransmissions) TCP Congestion Control (Simon S. Lam) 13 13
Fast Retransmit Time-out period often If sender receives 3 relatively long: relatively long duplicate ACKs for duplicate ACKs for long delay before the same data, it resending lost packet supposes that supposes that Detect lost segments Detect lost segments segment after via duplicate ACKs ACKed data was Sender often sends many segments back-to- lost: back fast retransmit: If segment is lost, resend se ment resend segment there will likely be many h ll l k l before timer expires duplicate ACKs. TCP Congestion Control (Simon S. Lam) 14 14
Host A Host B X X egment r 2 nd se eout for time time Resending a segment after triple duplicate ACK R di t ft t i l d li t ACK without waiting for timeout TCP Congestion Control (Simon S. Lam) 15 15
TCP Flow Control F flow control receiver: explicitly informs sender of (dynamically y y sender won’t overrun changing) amount of receiver’s buffers by free buffer space transmitting too much, too fast RcvWindow field in TCP segment header sender: keeps amount of sender keeps amount of transmitted, unACKed data less than most recently received y RcvWindow value buffer at receive side of a TCP connection TCP Congestion Control (Simon S. Lam) 16 16
Causes/costs of congestion: scenario four senders Q: what happens as and λ in λ ' in multi-hop paths increase at many increase at many Timeout & retransmit senders? positive feedback instability Host A λ in : original data g in λ ' in : original data plus retransmitted data finite shared output li k b ff link buffers Host B λ out TCP Congestion Control (Simon S. Lam) 17 17
Effect of Congestion Effect of Congest on W too big for many flows -> congestion Packet loss -> transmissions on links a packet has Packet loss -> transmissions on links a packet has traversed prior to loss are wasted Congestion collapse due to too many retransmissions and too much wasted transmission capacity October 1986, Internet had its first congestion collapse collapse goodput upper bound upper bound desired collapse collapse load (aggregate send rate) TCP Congestion Control (Simon S. Lam) 18 18
TCP Window Control TCP W ndow Control Receiver flow control Receiver flow control Avoid overloading receiver rcvwindow: receiver’s advertised window (also rwnd) Receiver sends rcvwindow to sender Receiver sends rcvwindow to sender Network congestion control Sender tries to avoid overloading network It infers network congestion from “loss indications” congwin: congestion window (also cwnd) Sender sets W = min (congwin, rcvwindow) TCP Congestion Control (Simon S. Lam) 19 19
TCP Congestion Control How does sender end-to-end control (no network determine CongWin? assistance) loss event timeout or loss event = timeout or sender limits transmission: sender limits transmission: 3 duplicate acks LastByteSent-LastByteAcked TCP sender reduces ≤ CongWin CongWin after a loss CongWin after a loss Roughly the send buffer’s Roughly, the send buffer s event three mechanisms: throughput ≤ CongWin CongWin h h slow start l bytes/sec / RTT reduce to 1 segment where CongWin is in bytes after timeout event AIMD (additive increase AIMD ( ddi i i multiplicative decrease) Note: For now consider RcvWindow to be very large such that the send window size is equal to CongWin. l t C Wi TCP Congestion Control (Simon S. Lam) 20 20
Recommend
More recommend