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 ≤ LastByteExpected;   
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.

Protecting against Wrap Around

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 links exists and are even more likely to wrap if only 32 bits are used. 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 64KB of window says, so we are restricted to less than what could even be potentially carried by a T1 line.
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 window is open 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 Nagel'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.

TCP Sliding Window

Outline