Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 TCP, TCP Congestion Control and Common AQM Schemes: Quick Revision Shivkumar Kalyanaraman Rensselaer

  • View
    215

  • Download
    0

Embed Size (px)

DESCRIPTION

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 3 Multiplexing / demultiplexing application transport network M P2 application transport network receiver H t H n segment M application transport network P1 MMM P3 P4 segment header application-layer data source port #dest port # 32 bits header/payload fields

Transcript

Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 1 TCP, TCP Congestion Control and Common AQM Schemes: Quick Revision Shivkumar Kalyanaraman Rensselaer Polytechnic InstituteBased in part upon slides of Prof. Raj Jain (OSU), Srini Seshan (CMU), J. Kurose (U Mass), I.Stoica (UCB) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 2 q Quick introduction to TCP Services q TCP Reliability Model, Mechanisms q TCP Congestion Control Model and Mechnisms q TCP Versions: Reno, NewReno, SACK, Vegas etc q AQM schemes: common goals, RED, Overview Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 3 Multiplexing / demultiplexing application transport network M P2 application transport network receiver H t H n segment M application transport network P1 MMM P3 P4 segment header application-layer data source port #dest port # 32 bits header/payload fields Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 4 Checksum Sender: q Treat segment contents as sequence of 16-bit integers q Checksum: addition (1s complement sum) of segment contents q Sender puts checksum value into UDP checksum field Receiver: q Compute checksum of received segment q Check if computed checksum equals checksum field value: q NO - error detected q YES - no error detected. But maybe errors nonetheless? Goal: detect errors (e.g., flipped bits) in transmitted segment (I.e., payload + header) Note: IP only has a header checksum. Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 5 Introduction to TCP q Communication abstraction: close equivalent to UNIX file-system interface => programmer productivity! q Reliable q Ordered q Point-to-point q Byte-stream q Full duplex q Flow and congestion controlled Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 6 TCP Header Source portDestination port Sequence number Acknowledgement Advertised windowHdrLen Flags 0 ChecksumUrgent pointer Options (variable) Data Flags: SYN FIN RESET PUSH URG ACK Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 7 Principles of Reliable Data Transfer q Characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 8 Temporal Redundancy Model Packets Sequence Numbers CRC or Checksum Status Reports ACKs NAKs, SACKs Bitmaps Packets FEC information Retransmissions Timeout Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 9 Types of errors and effects q Forward channel bit-errors (garbled packets) q Forward channel packet-errors (lost packets) q Reverse channel bit-errors (garbled status reports) q Reverse channel bit-errors (lost status reports) q Protocol-induced effects: q Duplicate packets q Duplicate status reports q Out-of-order packets q Out-of-order status reports q Out-of-range packets/status reports (in window-based transmissions) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 10 Reliability Mechanisms q Mechanisms: q Checksum: detects corruption in pkts & acks q ACK: packet correctly received q Duplicate ACK: packet incorrectly received q Sequence number: identifies packet or ack q 1-bit sequence number used both in forward & reverse channel q Timeout only at sender q Provides reliable transmission over: q An error-free channel q A forward & reverse channel with bit-errors q Detects duplicates of packets/acks q NAKs eliminated q Forward & reverse channel w/ packet-errors (loss) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 11 Example: Three-Way Handshake q TCP connection-establishment: 3-way-handshake necessary and sufficient for unambiguous setup/teardown even under conditions of loss, duplication, and delay Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 12 Stop-and-Wait (Handshake) Efficiency Data Ack Data t frame t prop = t prop t frame = Distance/Speed of Signal Frame size /Bit rate = Distance Bit rate Frame size Speed of Signal = 1 2 + 1 U= 2t prop +t frame t frame U Light in vacuum = 300 m/ s Light in fiber = 200 m/ s Electricity = 250 m/ s No loss or bit-errors! Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 13 Sliding Window Protocols Data Ack t frame t prop U= Nt frame 2t prop +t frame = N 2 +1 1 if N>2 +1 Note: no loss or bit-errors! Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 14 Receiver Sender Sliding Window: Details Sent & AckedSent Not Acked OK to SendNot Usable Max acceptable Receiver window Max ACK receivedNext seqnum Received & AckedAcceptable Packet Not Usable Sender window Next expected Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 15 acknowledgedsentto be sentoutside window Source Port Dest. Port Sequence Number Acknowledgment HL/Flags Window D. Checksum Urgent Pointer Options.. Source Port Dest. Port Sequence Number Acknowledgment HL/Flags Window D. Checksum Urgent Pointer Options.. Packet Sent Packet Received App write Window Flow Control: Header Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 16 Go-Back-N Retransmission q If you hear of packet loss, retransmit the whole window! q k-bit seq # in pkt header q Allows upto N = 2 k 1 packets in-flight, unacked q ACK(n): ACKs all pkts up to, including seq # n - cumulative ACK q Sender may receive duplicate ACKs q Robust to ack losses on the reverse channel q Can pinpoint the first packet lost, but cannot identify blocks of lost packets in window q One timer for oldest-in-flight pkt Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 17 Selective Repeat: Sender, Receiver Windows Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 18 Timeout and RTT Estimation q Problem: q Unlike a physical link, the RTT of a logical link can vary, quite substantially q How long should timeout be ? q Too long => underutilization q Too short => wasteful retransmissions q Solution: adaptive timeout: based on a good estimate of maximum current value of RTT Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 19 How to estimate max RTT? q RTT = prop + queuing delay q Queuing delay highly variable q So, different samples of RTTs will give different random values of queuing delay q Chebyshevs Theorem: q MaxRTT = Avg RTT + k*Deviation q Error probability is less than 1/(k**2) q Result true for ANY distribution of samples q In TCP: q Timeout = AverageRTT + 4*Deviation q Rounded up to timer granularity ( ms) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 20 Recap: Stability of a Multiplexed System Average Input Rate > Average Output Rate => system is unstable! How to ensure stability ? 1.Reserve enough capacity so that demand is less than reserved capacity 2.Dynamically detect overload and adapt either the demand or capacity to resolve overload Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 21 Congestion Problem in Packet Switching A B C 10 Mbs Ethernet 1.5 Mbs 45 Mbs D E statistical multiplexing queue of packets waiting for output link If capacity is sized to be less than peak demand (statistical muxing!), need to either reserve resources or dynamically detect/adapt to overload for stability Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 22 Congestion: A Close-up View q knee point after which q throughput increases very slowly q delay increases fast q cliff point after which q throughput starts to decrease very fast to zero (congestion collapse) q delay approaches infinity q Note (in an M/M/1 queue) q delay = 1/(1 utilization) Load Throughput Delay kneecliff congestion collapse packet loss Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 23 Congestion Control vs. Congestion Avoidance q Congestion control goal q stay left of cliff q Congestion avoidance goal q stay left of knee q Right of cliff: q Congestion collapse q Increase in network load results in decrease of useful work done Load Throughput kneecliff congestion collapse Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 24 End-to-End Congestion Control q 1. End-to-end model: q End-system estimate the timing and degree of congestion and reduces its demand appropriately q Intermediate nodes relied upon to send timely and appropriate penalty indications (eg: packet loss rate) during congestion q Enhanced routers could send more accurate congestion signals (eg: early congestion notifications, I.e. ECNs) q Key: trust and complexity resides at end-systems q Issue: What about misbehaving flows? Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 25 Packet Conservation: Self-clocking PrPr PbPb ArAr AbAb Receiver Sender AsAs q Implications of ack-clocking: q More batching of acks => bursty traffic q Less batching leads to a large fraction of Internet traffic being just acks (overhead) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 26 Additive Increase/Multiplicative Decrease (AIMD) Policy q Assumption: decrease policy must (at minimum) reverse the load increase over-and-above efficiency line q Implication: decrease factor should be conservatively set to account for any congestion detection lags etc x0x0 x1x1 x2x2 Efficiency Line Fairness Line User 1s Allocation x 1 User 2s Allocation x 2 Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 27 TCP Congestion Control q Maintains three variables: q cwnd congestion window q rcv_win receiver advertised window q ssthresh threshold size (used to update cwnd) q Rough estimate of knee point q For sending use: win = min(rcv_win, cwnd) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 28 TCP: Slow Start q Whenever starting traffic on a new connection, or whenever increasing traffic after congestion was experienced: q Set cwnd =1 q Each time a segment is acknowledged increment cwnd by one (cwnd++). q Does Slow Start increment slowly? Not really. In fact, the increase of cwnd is exponential!! q Window increases to W in RTT * log 2 (W) Shivkumar Kalyanaraman Rensselaer Polytechnic Institute 29 Slow Start Example q The congestion window size grows very rapidly q TCP slows down the increase of cwnd when cwnd >= sst

Recommended

View more >