1 / 25

TCP continued

Understand how TCP manages flow and congestion control to avoid network overload and achieve efficiency and fairness.

trevormason
Download Presentation

TCP continued

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. TCP continued

  2. TCP flow/congestion control • Sometimes sender shouldn’t send a pkt whenever its ready • Receiver not ready (e.g., buffers full) • React to congestion • Many unACK’ed pkts, may mean long end-end delays, congested networks • Network itself may provide sender with congestion indication • Avoid congestion • Sender transmits smoothly to avoid temporary network overloads

  3. TCP congestion control • To react to these, TCP has only one knob – the size of the send window • Reduce or increase the size of the send window • In our project, the size is fixed • The size of the send window is determined by two things: • The size of the receiver window the receiver told him in the TCP segment • His own perception about the level of congestion in the network

  4. TCP Congestion Control • Idea • Each source determines network capacity for itself • Uses implicit feedback, adaptive congestion window • ACKs pace transmission (self-clocking) • Challenge • Determining the available capacity in the first place • Adjusting to changes in the available capacity to achieve both efficiency and fairness

  5. flow control TCP Flow Control • receiver: explicitly informs sender of (dynamically changing) amount of free buffer space • RcvWindow field in TCP segment • sender: keeps the amount of transmitted, unACKed data less than most recently received RcvWindow sender won’t overrun receiver’s buffers by transmitting too much, too fast RcvBuffer= size of TCP Receive Buffer RcvWindow = amount of spare room in Buffer receiver buffering

  6. What is Congestion? • Informally: “too many sources sending too much data too fast for network to handle” • Different from flow control, caused by the network not by the receiver • How does the sender know whether there is congestion? Manifestations: • Lost packets (buffer overflow at routers) • Long delays (queuing in router buffers)

  7. two senders, two receivers one router, infinite buffers no retransmission large delays when congested maximum achievable throughput lout lin : original data unlimited shared output link buffers Host A Host B Causes/costs of congestion

  8. Window-based, implicit, end-end control Transmission rate limited by congestion window size, Congwin, over segments: w * MSS throughput = Bytes/sec RTT TCP Congestion Control Congwin w segments, each with MSS bytes sent in one RTT: Computer Science, FSU

  9. two “phases” slow start congestion avoidance important variables: Congwin threshold: defines threshold between slow start phase and congestion avoidance phase “probing” for usable bandwidth: ideally: transmit as fast as possible (Congwin as large as possible) without loss increaseCongwin until loss (congestion) loss: decreaseCongwin, then begin probing (increasing) again TCP Congestion Control

  10. exponential increase (per RTT) in window size (not so slow!) loss event: timeout (Tahoe TCP) Slowstart algorithm time TCP Slowstart Host A Host B one segment RTT initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event OR CongWin > threshold) two segments four segments

  11. Why Slow Start? • Objective • Determine the available capacity in the first place • Idea • Begin with congestion window = 1 pkt • Double congestion window each RTT • Increment by 1 packet for each ack • Exponential growth but slower than one blast • Used when • First starting connection • Connection goes dead waiting for a timeout

  12. TCP Congestion Avoidance Congestion avoidance /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 perform slowstart

  13. Fairness goal: if N TCP sessions share same bottleneck link, each should get 1/N of link capacity TCP connection 1 bottleneck router capacity R TCP connection 2 TCP Fairness

  14. Two competing sessions: Additive increase gives slope of 1, as throughput increases multiplicative decrease decreases throughput proportionally Why is TCP fair? equal bandwidth share R However, TCP is not perfectly fair. It biases towards flows with small RTT. Connection 2 throughput loss: decrease window by factor of 2 congestion avoidance: additive increase Connection 1 throughput R

  15. Time-out period often relatively long: long delay before resending lost packet Detect lost segments via duplicate ACKs. Sender often sends many segments back-to-back If segment is lost, there will likely be many duplicate ACKs. If sender receives 3 ACKs for the same data, it supposes that segment after ACKed data was lost: fast retransmit:resend segment before timer expires Fast Retransmit

  16. Fast retransmit algorithm: event: ACK received, with ACK field value of y if (y > SendBase) { SendBase = y if (there are currently not-yet-acknowledged segments) start timer } else { increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) { resend segment with sequence number y } a duplicate ACK for already ACKed segment fast retransmit

  17. Fast Retransmit and Fast Recovery – TCP Reno • The fast retransmit and fast recovery algorithms are usually implemented together as follows. • When the third duplicate ACK is received, set ssthresh to no more than the value given in equation 3. • Retransmit the lost segment and set cwnd to ssthresh plus 3*SMSS. This artificially "inflates" the congestion window by the number of segments (three) that have left the network and which the receiver has buffered. • For each additional duplicate ACK received, increment cwnd by SMSS. This artificially inflates the congestion window in order to reflect the additional segment that has left the network. • Transmit a segment, if allowed by the new value of cwnd and the receiver's advertised window. • When the next ACK arrives that acknowledges new data, set cwnd to ssthresh (the value set in step 1). This is termed "deflating" the window. This ACK should be the acknowledgment elicited by the retransmission from step 1, one RTT after the retransmission (though it may arrive sooner in the presence of significant out- of-order delivery of data segments at the receiver). Additionally, this ACK should acknowledge all the intermediate segments sent between the lost segment and the receipt of the third duplicate ACK, if none of these were lost. • http://www.faqs.org/rfcs/rfc2581.html

  18. TCP ACK generation[RFC 1122, RFC 2581] TCP Receiver action Delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK Immediately send single cumulative ACK, ACKing both in-order segments Immediately send duplicate ACK, indicating seq. # of next expected byte Immediate send ACK Event at Receiver Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed Arrival of in-order segment with expected seq #. One other segment has ACK pending Arrival of out-of-order segment higher-than-expect seq. # . Gap detected Arrival of segment that partially or completely fills gap

  19. TCP Deadlock • The receiver window is full because the application is not reading the data fast enough. • The receiver sends ACK back advertising window size 0. • The sender will not send anything. • The receiver finally frees up some space, but the sender does not know, because the receiver does not send ACK when no data is received. • Solution: TCP provide option for the sender to send a 1-byte segment to probe the receiver.

  20. TCP sender • TCP sender does not have to send the data you give him immediately. The implementations typically waits until get some more data to send. Remember TCP regards the data as a byte stream. • This is the reason why the template code took some measures to make sure that always a complete packet is delievered.

  21. RTT samples • Most TCP implementations only get an RTT sample for the segment that has not been retransmitted. • Once a timeout happens, the sender doubles timeout.

  22. Silly Window Syndrome • The receiver may advertise small windows. • The sender then sends small segments --- not very efficient. • TCP requires the receiver only advertise window of one MSS or half of its buffer, which ever is smaller.

  23. ECN • Explicit Congestion Notification • RFC 3168 • “An ECN-aware router may set a bit in the IP header instead of dropping a packet in order to signal the beginning of congestion. The receiver of the packet echoes the congestion indication to the sender, which must react as though a packet drop were detected. “ –from wiki

  24. DCCP • Sometimes you don’t need reliability, but need to exercise some congestion control! • For applications with timing constraints, data may be useless if outdated. • http://read.cs.ucla.edu/dccp/

  25. Useful Linux Network Commands • ifconfig • route • tracert • netstat • ping • tcpdump

More Related