Sliding Window in TCP

We are now going to look at the sliding window algorithm used by TCP
The point of using sliding window in the transport layer is to:
- guarantee reliable delivery of data
- ensure data is delivered in order
- enforce flow control between sender and receiver
Rather than have a fixed-size window as in point-to-point sliding window in TCP a window size is advertised using the AdvertisedWindow field in the TCP header.
The sender is then limited to having no more than a value of AdvertisedWindow bytes of unacknowledged data at any given time.
The receiver selects a suitable value for AdvertisedWindow based on the amount of memory allocated to the connection for the purpose of buffering data.

Reliable and Ordered Delivery

In TCP, sender and receiver each maintain buffers.
We imagine these buffers as a sequence of bytes rather than being split into blocks of the size of a segment.
The sender's buffer is used to store data that has been written by the sending application, but not acknowledged yet; the receiver's buffer is used to store data that has arrived out of order and needs to wait for additional data before being passed on to the application process. It could also be used to store data waiting for the receiving application to read it.
For now, we will assume sequence numbers can be arbitrarily large.
The send buffer maintains: LastByteAcked, LastByteSent, and LastByteWritten, and we want:
```
LastByteAcked ≤ LastByteSent;   
and  LastByteSent ≤ LastByteWritten;
```
The receiving side maintains: LastByteRead, NextByteExpected, and LastByteRcvd, and we want:
```
LastByteRead ≤ NextByteExpected;   
and  NextByteExpected ≤ LastByteRcvd + 1;
```

Flow Control

Each buffer in TCP has some maximum size: MaxSendBuffer, MaxRcvBuffer.
Recall that in sliding window, the size of the window sets the amount of data that can be sent without waiting for acknowledgment from the receiver.
The receiver throttles the sender by advertising a window that is no larger than the amount of data that it can buffer. i.e., it sets the advertised window to:
```
AdvertisedWindow = MaxRcvBuffer - ((NextByteExpected - 1) - LastByteRead)
```
It can happen that the advertised window shrinks if the application processing on the receiver doesn't read received data as the data is being received.

The sender computes an EffectiveWindow based on the equation:

EffectiveWindow = AdvertisedWindow - (LastByteSent - LastByteAcked)

This is how much data the sender can still send. If it gets to 0, the sender must wait for more ACK's.
The TCP send side must also block the sending application process if it tries to write too much to its buffer.
That is, whenever this app tries to write y bytes to the buffer, TCP checks if:
```
(LastByteWritten - LastByteAcked) + y > MaxSendBuffer.
```
If so, it blocks the app.
The receiver side does not spontaneously send non-data segments; it only send them in response to an arriving data segment.
If the receiver advertises a window of 0, the sender still sends periodic 1-byte segments to see if any will be accepted. It does this to prevent the situation that the sender hangs because of the 0 byte advertisement.
This strategy is an example of a protocol design strategy known as smart sender/dumb receiver.

In-Class Exercise

Suppose MaxSendBuffer = MaxRcvBuffer = 8192 bytes, LastByteAcked = 1024, LastByteWritten = 9000, LastByteSent = 8500, LastByteRead = 700, NextByteExpected = 1401, LastByteRcvd = 1500
What would be the advertised window, the receiver would send in this situation?
What would the effective window size be?
How many bytes could the sender application still write to the send buffer?
Please post your solution to the Apr 5 In-Class Exercise Thread.

Protecting against Wrap Around

Bandwidth delay for various connection assumming 100ms RTT

TCP's SequenceNum field is 32 bits and its AdvertisedWindow field is 16 bits long.
So it easily satisfies the requirement that we had from our discussion of point-to-point sliding window that the number of sequence numbers needs to be twice as large as the window size.
The relevance of the 32 bit sequence number space is that the sequence number used on a given connection might wrap around -- a byte with sequence number x could be sent at one time, and then at a later time a second byte with the same sequence number x might be sent.
A segment does not live on the internet for longer than 120 seconds.
So we want to make sure the sequence numbers do not wrap around in that period of time.
This in turn depends on how fast the data can be sent over the internet.
Why? Because after the starting sequence number, S, sequence numbers and ACKs refer to the number of bytes since S. So if x is the number of bytes sent so far is bigger than 4 gigabytes the sequence numbers will wrap.
In the worst case, sending on a T1(1.5Mbps) line it takes as little as 6.4 hours before the sequence numbers wrap (assuming unrealistically that each segment was 1 byte long); on the other hand, over an OC-48(2.5 Gbps) line it takes 14 seconds.
OC-192 and 10GigE are even more likely to wrap if only 32 bits are used (would happen in 3 seconds). So the IETF has made extensions to TCP to extend the sequence number space to try to solve this problem.
Another problem is that bandwidth*delay data can be sent before an acknowledgment. With only 16 bits of advertised window we can only advertise up to 64KB window size, so we are restricted to less than what could even be potentially carried by a T3 line (see table above) if the delay were 100ms.
This problem is also addressed by the IETF extension mentioned above.

Triggering Transmission

TCP segments can be of variable size.
How does TCP determine that it has received enough data from the application layer to make a packet and send it?
There are three main triggering mechanisms:
- TCP maintains a maximum segment size (MSS), and will send a segment as soon as it has MSS many bytes.
- It is also possible that the sending process explicitly requests data to be sent -- this is, a push operation that would then flush and send the current TCP buffer.
- TCP also sends if a timer fires; the resulting segment contains as many bytes as are currently buffered for transmission.
Another issue is flow control -- one might have MSS bytes to send but the window may or may not be that large.
If it is, we can send all the data. But what if the window is only half that size?
If one aggressively takes advantage of any available, even small, window, you can get the so-called silly window syndrome -- these small segments will end up staying in the system and eventually all of the segments will end up small.
To solve this problem some mechanism needs to be introduced to coalesce small segments.

Nagle's Algorithm

If there is data to send but the open window is less than MSS, then we may want to wait around some time before sending the available data.

Nagle's algorithm is one way to decide how long to wait: When the application produces data to send

  if both the available data and the window size are >= MSS
     send a full segment
  else
    if there is unACKed data in flight
       buffer the new data until an ACK arrives
  else
    send all the new data now.

Some applications cannot afford a delay for each write that is done to a TCP connection. For these application, TCP supports a way to turn off Nagle's algorithm by setting the TCP_NODELAY option.

Adaptive Retransmission

As TCP guarantees reliable delivery of data, it retransmits each segment if an ACK is not received in a certain period of time.
TCP sets this timeout as a function of the RTT it expects between the two ends of the connection.
However, RTT on the internet is quite variable, so TCP needs an adaptive way of setting these timers.
The original way of doing this was to keep a running average of the RTT and then to compute the timeout as a function of this RTT.
So each time TCP sent a data segment, it records the time. When an ACK arrives it reads the time and takes the difference, denoted as SampleRTT, and adds this in to the current running average according to the formula
```
EstimatedRTT = a*EstimatedRTT + (1-a)* SampleRTT.
```
Here a is some constant between 0 and 1.
The timeout was set to twice this value.

Karn/Partridge Algorithm.

The problem with this original method is that we ACK data not segments.
Data might have been retransmitted several times before the first time it was successfully ACK'd.
This could make the SampleRTT much larger than it really is.
One solution to this is in the running average to only use ACKs that are in reply to segments that were only sent once and not use those that come from re-sent segments.
This is what Karn/Partridge proposed in 1987.

Jacobson/Karels Algorithm

In 1988, Jacobson/Karels proposed several changes to TCP to battle congestion.
One source of congestion is re-sent segments because TCP timed-out too soon on a segment.
The running average approach of the original and Karn/Partridge EstimateRTT algorithms does not take into account the variance one would expect in the RTT.
The reason why variance might be important is that if it is small then the EstimatedRTT can be trusted and there is no reason to multiply it by 2 to compute the timeout; however, if it is large then it suggests the EstimatedRTT is untrustworthy and should not be couple too tightly to the timeout period.
So one thing that Jacobson/Karels proposed was a means to take this into account.

They compute the EstimatedRTT and TimeOut periods as follows:

Difference = SampleRTT - EstimatedRTT
EstimatedRTT = EstimatedRTT + (δ×Difference)
Deviation = Deviation + δ(|Difference| - Deviation)

Timeout = μ×EstimatedRTT + φ×Deviation

Here δ is between 0 and 1 and μ and φ are typically set by hand commonly to the values 1 and 4.
The book shows how to scale things by a factor of 2ⁿ so that the above calculations can be done without the need of floating point.
Another thing to note is that the calculations above are only as good as the clocks on which they are based.
Some old Unix implementations of TCP only checked to see whether a timeout should occur every 500ms, so this actually swamps the 100-200ms RTT for a transcontinental connection.
There are extensions to TCP to make the timing mechanisms more robust.

Record Boundaries

TCP is a byte-stream protocol. The sender sends bytes which happen to be put into segments.
For instance, the sender might send 10 bytes in the first segment 20 in the next.
Usually, the application at the receiver is only aware that there are bytes it can read from the receiving TCP layer, and not the segment boundaries. i.e., for the example above, the receiving application would not know the 10th byte was in one segment and the 11th in the next.
TCP does support two features that can be used to inform the receiver of a message boundary: the URG flag and the push operation.
The URG flag and the UrgPtr in the TCP header were originally supposed to be used to send "out of band data"; that is, to send things like commands to interrupt an operation already underway.
This data would be sent to the receiving process as soon as it arrived, even if this meant delivering it before data with an earlier sequence number.
This original use of the URG flag was not used so often; and over time, the URG pointer switched to be used to signify special data, such as a record marker.
Similarly, the PUSH flag can also be used to flush data from the receiving buffer to a receiving process that supports PUSH, so setting this flag can also be used to indicate record boundaries.

TCP Extensions

We have mentioned a few times that there are extensions to TCP to mitigate against problems in the original design as networks get faster.
These extensions are realized as options that can be added to the end of the TCP header.
Since they are designed to be optional and since they are at the end of header, if a host does not understand these options then it can still communicate using usual TCP.
The first common extension is used to improve TCP's timeout mechanism by including a 32 bit timestamp into the segments header.
The receiver echoes this back to the sender when it acknowledges segments. The sender subtracts the timestamp from the current time to estimate the RTT.
A second use for the timestamp is to extend the SequenceNum. If this is used, TCP accepts or rejects a segment based on the 64 bits consisting of the timestamp in the high 32 bits and the SequenceNum in the low 32 bits.
Another extension to TCP is to use the options to define a scaling factor for the two-byte AdvertisedWindow. i.e., rather than the AdvertisedWindow saying the window in units of bytes it says it in units of some number of bytes given by the scaling factor.
A last common extension is to use the options field to do selective acknowledgements of data received but not contiguous to data that had been previously received.
This enables the sender to resend only the just the segments that have not arrived.

TCP Sliding Window

Outline