1CS 640CS 640 Introduction to Computer NetworksLecture 26CS 640Today’s lecture• Congestion in networks• TCP congestion control– Additive Increase Multiplicative Decrease–Slow start– Fast retransmit and fast recoveryCS 640Congestion in the Internet• Checksums are effective for detecting bit errors but they are not the only problem…• We know that traffic is bursty– Statistical multiplexing of ON/OFF sources– Heavy-tailed file sizes– Routers have limited buffer capacity– Packets dropped when buffers full• Buffers do protect from short bursts• Congestion lengthens delays and lowers throughput– Standard throughput/load curveOptimalloadLoadThroughput/delay2CS 640How can we deal with congestion?• Over-provision networks– Very expensive– Commonly done• Networks designed to normally operate at 5-50% capacity• Call admission control (phone networks)• Develop protocols to respond to congestion– Route away from congestion• Good idea – how can we do it?– Retransmit in the face of loss• This is the state of the artCS 640Congestion Control Basics• UDP will send packets at any specified rate– Does not have mechanisms to handle congestion• Issues:– Detecting congestion– Reacting to congestion– Avoiding congestion• Shaping traffic• QoS mechanisms• Transport protocol will deal with congestion…CS 640Congestion control in the Internet• TCP implements congestion control– Detects congestion through packet losses– Reduces rate aggressively in response to congestion– Increases rate cautiously to use up available bandwidth– Works well for large flows• Why the Internet doesn’t experience congestion collapse– Backbones overprovisioned– TCP congestion control– Sources’ rate limited by nearest bottleneck link3CS 640Today’s lecture• Congestion in networks• TCP congestion control– Additive Increase Multiplicative Decrease–Slow start– Fast retransmit and fast recoveryCS 640TCP RENO Overview• Standard TCP functions in last lecture– Connections, reliability, RTT calculation, etc.• Congestion control/management– Additive Increase/ Multiplicative Decrease (AIMD)– Fast Retransmit/Fast Recovery–Slow StartCS 640TCP Congestion Control• Idea– Assumes best- effort network (FIFO or FQ routers) each source determines network capacity for itself– Uses implicit feedback– ACKs pace transmission (self-clocking)• Challenge– Determining the available capacity in the first place– Adjusting to changes in the available capacity4CS 640Additive Increase/Multiplicative Decrease• Objective: adjust to changes in the available capacity• New state variable per connection: CongestionWindow– limits how much data source has in transitMaxWin = MIN(CongestionWindow, AdvertisedWindow)EffWin = MaxWin - (LastByteSent -LastByteAcked)• Idea:– increase CongestionWindow when congestion goes down– decrease CongestionWindow when congestion goes upCS 640AIMD (cont)• Question: how does the source determine whether or not the network is congested?• Answer: a timeout occurs– timeout signals that a packet was lost– packets are seldom lost due to transmission error– lost packet implies congestion– RTO calculation is criticalCS 640AIMD (cont)• In practice: increment a little for each ACKIncrement = 1/CongestionWindowCongestionWindow += IncrementMSS = max segment size = size of a single packetSource Destination…• Algorithm– increment CongestionWindow by one packet per RTT (linear increase)– divide CongestionWindow by two on timeouts (multiplicative decrease – fast!!)– CongestionWindow always >= 1 MSS5CS 640AIMD (cont)• Trace: sawtooth behavior60201.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0KBTime (seconds)703040501010.0CS 640Today’s lecture• Congestion in networks• TCP congestion control– Additive Increase Multiplicative Decrease–Slow start– Fast retransmit and fast recoveryCS 640Slow Start• Objective: determine the available capacity when connection opened– Additive increase is too slow• One additional packet per RTT• Idea:– begin with CongestionWindow = 1 pkt– double CongestionWindow each RTT (increment by 1 packet for each ACK)– This is exponential increase to probe for available bandwidth• SSTHRESH indicates when to begin additive increaseSource Destination…6CS 640Slow Start contd.• Exponential growth, but slower than all at once•Used…– when first starting connection– when connection goes dead waiting for timeout• Trace• Problem: lose up to half a CongestionWindow’sworth of data60201.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0KB7030405010CS 640SSTHRESH and CWND• SSTHRESH called CongestionThreshold in book• Typically set to very large value on connection setup• Set to one half of CongestionWindow on packet loss– So, SSTHRESH goes through multiplicative decrease for each packet loss– If loss is indicated by timeout, set CongestionWindow = 1• SSTHRESH and CongestionWindow always >= 1 MSS• After loss, when new data is ACKed, increase CWND– Manner depends on whether we’re in slow start or congestion avoidanceCS 640SS ExampleClientServerSYN (40 bytes)SYN + ACK (40 bytes)ACK + Data (150 bytes)ACK 1461Data 1460Client embeds requestFor 30KB Client advertises receivewindow of 8KBMSS is 1.5kB withstandard 40B headerClient uses delayedacknowledgements(200ms)Begin by sending bytes 1:1460CW=1, DIF=0, SST=44, RW=5Data 4380ACK 4381Data 8760ACK 7301CW=2, DIF=0, SST=44, RW=5CW=3, DIF=0, SST=44, RW=5CW=4, DIF=1, SST=44, RW=5CW=5, DIF=2, SST=44, RW=5ACK 10221Data 131407CS 640SS Example contd.ClientServerData 17520ACK 13141CW=6, DIF=3, SST=44, RW=5 CW=5, DIF=2, SST=44, RW=5 ACK 10221Data 13140ACK 16061Data 20440ACK 18981CW=7, DIF=3, SST=44, RW=5 Data 23360ACK 21901CW=8, DIF=3, SST=44, RW=5 CW=9, DIF=3, SST=44, RW=5 ACK 24821Data 26280Data 29200ACK 27741Data 30000CW=10, DIF=3, SST=44, RW=5 FIN (40 bytes)ACK 30001ACK 27741FIN + ACK (40 bytes)ACK (40 bytes)CW=11, DIF=3, SST=44, RW=5 CW=12, DIF=3, SST=44, RW=5 Server initiates active closeCS 640Today’s lecture• Congestion in networks• TCP congestion control– Additive Increase Multiplicative Decrease–Slow start– Fast retransmit and fast recoveryCS 640Fast Retransmit and Fast Recovery• Problem: coarse TCP timeouts lead to idle periods• Fast retransmit: use 3 duplicate ACKs to trigger retransmission• Fast recovery: start at SSTHRESH and do additive increase after fast retransmitPacket 1Packet
View Full Document
Unlocking...