Download - Tcp Reliability Flow Control
![Page 1: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/1.jpg)
TCP requirements
• Two key requirements of the protocol:o Reliability: Ensuring that data that is sent
actually arrives at its destination, and if not, detecting this and re-sending the data.
o Data Flow Control: Managing the rate at which data is sent so that it does not overwhelm the device that is receiving it.
![Page 2: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/2.jpg)
PAR
• Reliability in communications follow a rule – a device to send back an acknowledgment each
time it successfully receives a transmission
• If a transmission is not acknowledged after a period of time, it is retransmitted by its sender
• This system is called positive acknowledgment with retransmission (PAR)
• One drawback: the transmitter cannot send next message until the previous is acknowledged.
![Page 3: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/3.jpg)
PAR
![Page 4: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/4.jpg)
TCP sliding window • A variation on the enhanced PAR system • To support TCP’s stream orientation• Each device keeps track of the status of the
byte stream• Dividing Data into four conceptual categories:
– Bytes sent and acknowledged– Bytes sent but not yet acknowledged– Bytes not yet sent but that can be sent
immediately– Bytes not yet sent that cannot be sent until the
recipient signals that it is ready for them.
![Page 5: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/5.jpg)
Data Stream categories
![Page 6: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/6.jpg)
Send, usable windows
• The send window is the key to the entire TCP sliding window system: – it represents the maximum number of
unacknowledged bytes a device is allowed to have outstanding at once.
• The usable window is the amount of the send window that the sender is still allowed to send at any point in time; – it is equal to the size of the send window less the
number of unacknowledged bytes already transmitted.
![Page 7: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/7.jpg)
Send and usable window
![Page 8: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/8.jpg)
Send and usable window
![Page 9: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/9.jpg)
Implementing sliding window
• Three essential fields in the TCP segment– The Sequence Number field indicates the number
of the first byte of data being transmitted. – The Acknowledgment Number is used to
acknowledge data received by the device sending this segment.
– The Window field tells the recipient of the segment the size to which it should set its send window
![Page 10: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/10.jpg)
Window slide
• When a device gets an acknowledgment for a range of bytes, it knows they have been successfully received by their destination.
• It moves them from the “sent but unacknowledged” to the “sent and acknowledged” category.
• This causes the send window to slide to the right, allowing the device to send more data.
![Page 11: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/11.jpg)
TCP window size management
• The receiver on receipt of segment must– Send Acknowledgement– Transfer data from buffer to application
• Receiver delay in transfer can happen
• Danger of buffer overflow
• Varying window size to manage data flow
![Page 12: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/12.jpg)
Flow control
• The TCP sliding window system is used not just for ensuring reliability through acknowledgments and retransmission
• it is also the basis for TCP’s flow control mechanism. • By increasing or reducing the size of its receive window
– a device can raise or lower the rate at which its connection partner sends it data.
– In the case where a device becomes extremely busy, it can even reduce the receive window to zero, closing it
– this will halt any further transmissions of data until the window is reopened
![Page 13: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/13.jpg)
Shrinking window
![Page 14: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/14.jpg)
Silly window syndrome
• Sliding window mechanism does not ensure a min size of segment
• Shrinking window can result in inefficient transmission of small size segment
![Page 15: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/15.jpg)
Silly window syndrome
![Page 16: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/16.jpg)
SWS avoidance algorithm
• Receiver SWS avoidance– Restrict moving right edge of window by too
small amount– Reduce window size to 0– Right edge be moved by half buffer size or
MSS whichever is less
![Page 17: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/17.jpg)
Sender SWS avoidance algorithm
• Nagle’s algorithm – John Nagle– Data can be immediately sent as long as all sent
data is acknowledged– When there is unacknowledged data
• Do not send till all data acknowledged
• Send after accumulating data for full segment
![Page 18: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/18.jpg)
TCP ACK & Retransmission• TCP acknowledgments are cumulative• Tell a transmitter that all the bytes up to the
sequence number indicated in the acknowledgment were received successfully.
• If bytes are received out of order, they cannot be acknowledged until all the preceding bytes are received.
• TCP includes a method for timing transmissions and retransmitting lost segments if necessary.
![Page 19: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/19.jpg)
Managing Retransmissions • Each time a segment is sent, a copy is Placed On
Retransmission Queue• Timer Starts at a predetermined value• Counts down over time• If an acknowledgment is received for a segment before its
timer expires, the segment is removed from the retransmission queue
• If the timer expires before an acknowledgment is received, the segment is retransmitted
• No guarantee that a retransmitted segment will be received• If not, Retransmission timer is reset, the segment will be
retransmitted again and the process repeated
![Page 20: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/20.jpg)
Policies For Dealing with Retransmission
• Retransmit Only Timed-Out Segments
• Retransmit All Outstanding Segments
• TCP selective acknowledgment
![Page 21: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/21.jpg)
Retransmission Time
• Length of time for retransmission timer is very important
• If it is set too low– A segment actually received might be retransmitted
– didn't wait long enough for the acknowledgment
• if it is set too long– waste time waiting for an acknowledgment that will
never arrive
– reducing overall performance
![Page 22: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/22.jpg)
Choosing Retransmission time
• Ideally, the retransmission timer should be of value just slightly larger than the round-trip time (RTT)
• How to determine RTT?– Differences in TCP Connection Distances. – Transient Delays and Variability: The amount of time it
takes to send data between any two devices will vary over time due to various happenings on the internetwork: fluctuations in traffic, router loads and so on.
![Page 23: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/23.jpg)
Adaptive Retransmission Based RTT
• TCP uses a dynamic, or adaptive retransmission scheme
• Average RTT value for the connection• Asmoothing formula:
– New RTT = (a * Old RTT) + ( (1-a) * Newest RTT Measurement); 0 < a < 1
– a ~ 1 -> better smoothing, slow reaction– a ~ 0 -> fast reaction
![Page 24: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/24.jpg)
RTT Calculation by Karn's Algorithm
• Karn's algorithm-Inventor, Phil Karn – Does not use measured round-trip times– Eliminates problem of acknowledgment ambiguity
• Start by setting the timer, based on the current average round-trip time
• On retransmission, the timer is not reset to the same value but is “backed off” (increased) using a multiplier (typically 2) to give the retransmission more time to be received
• The timer continues to be increased until a retransmission is successful, up to a certain maximum value
![Page 25: Tcp Reliability Flow Control](https://reader033.vdocuments.mx/reader033/viewer/2022061300/54cb14c74a795905188b461d/html5/thumbnails/25.jpg)
RTT Calculation by Karn's Algorithm
• The round-trip timer is kept at the longer (backed-off) value until a valid round-trip time can be measured on a segment that is sent and acknowledged without retransmission
• This permits a device to respond with longer timers temporarily, while eventually having the round-trip time settle back to a long-term average when normal conditions resume