1 / 32

TCP

TCP. TCP Adaptive Retransmission Algorithm - Original. Theory Estimate RTT Multiply by 2 to allow for variations Practice Use exponential moving average (A = 0.1 to 0.2) Estimate = (A) * measurement + (1- A) * estimate Problem Did not handle variations well

rradke
Télécharger la présentation

TCP

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 CS/ECE 438 - UIUC, Fall 2006

  2. TCP Adaptive Retransmission Algorithm - Original • Theory • Estimate RTT • Multiply by 2 to allow for variations • Practice • Use exponential moving average (A = 0.1 to 0.2) • Estimate = (A) * measurement + (1- A) * estimate • Problem • Did not handle variations well • Ambiguity for retransmitted packets • Was ACK in response to first, second, etc transmission? CS/ECE 438 - UIUC, Fall 2006

  3. TCP Adaptive Retransmission Algorithm – Karn-Partridge • Algorithm • Exclude retransmitted packets from RTT estimate • For each retransmission • Double RTT estimate • Exponential backoff from congestion • Problem • Still did not handle variations well • Did not solve network congestion problems as well as desired CS/ECE 438 - UIUC, Fall 2006

  4. TCP Adaptive Retransmission Algorithm – Jacobson • Algorithm • Estimate variance of RTT • Calculate mean interpacket RTT deviation to approximate variance • Use second exponential moving average • Deviation = (B) * |RTT_Estimate – Measurement| + (1–B) * deviation • B = 0.25, A = 0.125 for RTT_estimate • Use variance estimate as component of RTT estimate • Next_RTT = RTT_Estimate + 4 * Deviation • Protects against high jitter • Notes • Algorithm is only as good as the granularity of the clock • Accurate timeout mechanism is important for congestion control CS/ECE 438 - UIUC, Fall 2006

  5. Client Server listen Synchronize (SYN) J SYN K, acknowledge (ACK) J+1 ACK K+1 Time flows down TCP Connection Establishment • 3-Way Handshake • Sequence Numbers • J,K • Message Types • Synchronize (SYN) • Acknowledge (ACK) • Passive Open • Server listens for connection from client • Active Open • Client initiates connection to server CS/ECE 438 - UIUC, Fall 2006

  6. Client Server Finished (FIN) J ACK J+1 FIN K ACK K+1 Time flows down TCP Connection Termination • Message Types • Finished (FIN) • Acknowledge (ACK) • Active Close • Sends no more data • Passive close • Accepts no more data CS/ECE 438 - UIUC, Fall 2006

  7. TCP Connection Management (cont) TCP server lifecycle TCP client lifecycle CS/ECE 438 - UIUC, Fall 2006

  8. TCP State Descriptions CS/ECE 438 - UIUC, Fall 2006

  9. Active open/SYN Passive open Close Close SYN/SYN + ACK LISTEN Send/SYN SYN_RCVD SYN_SENT SYN/SYN + ACK ACK SYN + ACK/ACK Close/ACK Close/FIN FIN/ACK FIN/ACK FIN_WAIT_1 CLOSE_WAIT ACK CLOSING Close/FIN FIN_WAIT_2 LAST_ACK ACK FIN + ACK/ACK TIME_WAIT ACK FIN/ACK Timeout TCP State Transition Diagram CLOSED ESTABLISHED CLOSED CS/ECE 438 - UIUC, Fall 2006

  10. TCP State Transition Diagram • Questions • State transitions • Describe the path taken by a server under normal conditions • Describe the path taken by a client under normal conditions • Describe the path taken assuming the client closes the connection first • TIME_WAIT state • What purpose does this state serve • Prove that at least one side of a connection enters this state • Explain how both sides might enter this state CS/ECE 438 - UIUC, Fall 2006

  11. Active open/SYN Passive open SYN/SYN + ACK SYN/SYN + ACK LISTEN Send/SYN SYN_RCVD SYN_SENT SYN/SYN + ACK ACK SYN + ACK/ACK SYN + ACK/ACK TCP State Transition Diagram Active open/SYN CLOSED Passive open Close Close Send/SYN SYN/SYN + ACK ACK ESTABLISHED TCP A TCP B 1. CLOSED LISTEN 2. SYN-SENT --> <SEQ=100><CTL=SYN> --> SYN-RECEIVED 3. ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED 4. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK> --> ESTABLISHED 5. ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED CS/ECE 438 - UIUC, Fall 2006

  12. LISTEN SYN_RCVD SYN_SENT Close/FIN Close/FIN Close/FIN FIN/ACK FIN/ACK FIN_WAIT_1 CLOSE_WAIT ACK CLOSING Close/FIN FIN_WAIT_2 LAST_ACK ACK FIN + ACK/ACK TIME_WAIT ACK FIN/ACK Timeout Timeout Timeout TCP State Transition Diagram Active open/SYN CLOSED Passive open Close Close SYN/SYN + ACK Send/SYN SYN/SYN + ACK ACK SYN + ACK/ACK Close/FIN Close/FIN ESTABLISHED FIN/ACK FIN/ACK ACK Close/FIN ACK FIN + ACK/ACK ACK FIN/ACK Timeout CLOSED CS/ECE 438 - UIUC, Fall 2006

  13. TCP Sliding Window Protocol • Sequence numbers • Indices into byte stream • ACK sequence number • Actually next byte expected as opposed to last byte received • Advertised window • Enables dynamic receive window size • Receive buffers • Data ready for delivery to application until requested • Out-of-order data out to maximum buffer capacity • Sender buffers • Unacknowledged data • Unsent data out to maximum buffer capacity CS/ECE 438 - UIUC, Fall 2006

  14. Maximum buffer size Advertised window Data available, but outside window Last byte sent First unacknowledged byte TCP Sliding Window Protocol – Sender Side • LastByteAcked <= LastByteSent • LastByteSent <= LastByteWritten • Buffer bytes between LastByteAcked and LastByteWritten CS/ECE 438 - UIUC, Fall 2006

  15. Maximum buffer size Advertised window Buffered, out-of-order data Next byte expected (ACK value) Next byte to be read by application TCP Sliding Window Protocol – Receiver Side • LastByteRead < NextByteExpected • NextByteExpected <= LastByteRcvd + 1 • Buffer bytes between NextByteRead and LastByteRcvd CS/ECE 438 - UIUC, Fall 2006

  16. Maximum buffer size Available buffer size Next byte expected (ACK value) Next byte to be read by application TCP ACK generation - 1 • Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed • Delayed ACK. Wait up to 500ms for next segment. CS/ECE 438 - UIUC, Fall 2006

  17. Maximum buffer size Available buffer size Next byte expected (ACK value) Next byte to be read by application TCP ACK generation - 2 • Arrival of in-order segment with expected seq #. One other segment has ACK pending • Immediately send single cumulative ACK, ACKing both in-order segments CS/ECE 438 - UIUC, Fall 2006

  18. Maximum buffer size Available buffer size Next byte expected (ACK value) Next byte to be read by application TCP ACK generation - 3 • Arrival of out-of-order segment higher-than-expect seq. # Gap detected • Immediately send duplicate ACK, indicating seq. # of next expected byte CS/ECE 438 - UIUC, Fall 2006

  19. Maximum buffer size Available buffer size Next byte expected (ACK value) Next byte to be read by application TCP ACK generation - 4 • Arrival of segment that partially or completely fills gap • Immediate send ACK, provided that segment starts at lower end of gap CS/ECE 438 - UIUC, Fall 2006

  20. TCP ACK generation[RFC 1122, RFC 2581] 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 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, provided that segment starts at lower end of gap CS/ECE 438 - UIUC, Fall 2006

  21. What’s the problem with time-out? time-out period often relatively long 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 Why 3? Fast Retransmit CS/ECE 438 - UIUC, Fall 2006

  22. 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 CS/ECE 438 - UIUC, Fall 2006

  23. Maximum buffer size Available buffer size What if? Buffered, out-of-order data Next byte expected (ACK value) Next byte to be read by application A 4th situation? • Receiver side CS/ECE 438 - UIUC, Fall 2006

  24. Maximum buffer size Maximum buffer size Available buffer size Buffered, out-of-order data TCP Flow Control Sender Sliding window First unacknowledged byte Data available, but outside window Last byte sent Receiver Avoid? Next byte to be read by application CS/ECE 438 - UIUC, Fall 2006 Next byte expected (ACK value)

  25. Flow Control vs. Congestion Control • Flow control • Preventing senders from overrunning the capacity of the receivers • Congestion control • Preventing too much data from being injected into the network, causing switches or links to become overloaded • TCP provides both • flow control based on advertised window • congestion control discussed later in class CS/ECE 438 - UIUC, Fall 2006

  26. TCP Flow Control • Receiving side • Receive buffer size = MaxRcvBuffer • LastByteRcvd - LastByteRead < = MaxRcvBuffer • AdvertisedWindow = MaxRcvBuffer - (NextByteExpected - NextByteRead) • Shrinks as data arrives and • Grows as the application consumes data • Sending side • Send buffer size = MaxSendBuffer • LastByteSent - LastByteAcked < = AdvertisedWindow • EffectiveWindow = AdvertisedWindow - (LastByteSent - LastByteAcked) • EffectiveWindow > 0 to send data • LastByteWritten - LastByteAcked < = MaxSendBuffer • block sender if (LastByteWritten - LastByteAcked) + y > MaxSenderBuffer CS/ECE 438 - UIUC, Fall 2006

  27. TCP Flow Control • Problem: Slow receiver application • Advertised window goes to 0 • Sender cannot send more data • Non-data packets used to update window • Receiver may not spontaneously generate update or update may be lost • Solution • Sender periodically sends 1-byte segment, ignoring advertised window of 0 • Eventually window opens • Sender learns of opening from next ACK of 1-byte segment CS/ECE 438 - UIUC, Fall 2006

  28. TCP Flow Control • Problem: Application delivers tiny pieces of data to TCP • Example: telnet in character mode • Each piece sent as a segment, returned as ACK • Very inefficient • Solution • Delay transmission to accumulate more data • Nagle’s algorithm • Send first piece of data • Accumulate data until first piece ACK’d • Send accumulated data and restart accumulation • Not ideal for some traffic (e.g. mouse motion) CS/ECE 438 - UIUC, Fall 2006

  29. TCP Flow Control • Problem: Slow application reads data in tiny pieces • Receiver advertises tiny window • Sender fills tiny window • Known as silly window syndrome • Solution • Advertise window opening only when MSS or 1/2 of buffer is available • Sender delays sending until window is MSS or 1/2 of receiver’s buffer (estimated) CS/ECE 438 - UIUC, Fall 2006

  30. TCP Bit Allocation Limitations • Sequence numbers vs. packet lifetime • Assumed that IP packets live less than 60 seconds • Can we send 232 bytes in 60 seconds? • Less than an STS-12 line • Advertised window vs. delay-bandwidth • Only 16 bits for advertised window • Cross-country RTT = 100 ms • Adequate for only 5.24 Mbps! CS/ECE 438 - UIUC, Fall 2006

  31. TCP Sequence Numbers – 32-bit CS/ECE 438 - UIUC, Fall 2006

  32. TCP Advertised Window – 16-bit CS/ECE 438 - UIUC, Fall 2006

More Related