Flow Control

In method TCPSender.handle(), Listing 2-1 // called by IP layer when ACK arrives in Lines 36 - 38:

if ((lastByteAcked < lastByteSent) {

calculate the new value of the RTO timer using Eq. (2.2);

re-start the RTO timer;

}

In method TCPSender.RTOtimeout(), Listing 2-1 // called when RTO timer timeout in Line 43:

double the TimeoutInterval; // see Eq. (2.1) start the timer;

An important peculiarity to notice about TCP is as follows. When a window-size worth of segments is sent, the timer is set for the first one, assuming that the timer is not already running (Line 24 in Listing 2-1). For every acknowledged segment of the burst, the timer is restarted for its subsequent segment in Line 37 in Listing 2-1. Thus, the actual timeout time for the segments towards the end of a burst can run quite longer than for those near the beginning of the burst. An example will be seen later in Section 2.2 in the solution of Example 2.1.

2.1.3 Flow Control

TCP receiver accepts out-of-order segments, but they are buffered and not delivered to the application above the TCP layer before the gaps are filled. For this, the receiver allocates memory space of the size RcvBuffer, which is typically set to 4096 bytes, although older versions of TCP set it to 2048 bytes. The receive buffer is used to store in-order segments as well, because the application may be busy with other tasks and does not fetch the incoming data immediately.

For the sake of simplicity, in the following discussion we will assume that in-order segments are immediately fetched by the application, unless stated otherwise.

To avoid having its receive buffer overrun, the receiver continuously advertises the remaining buffer space to the sender using a field in the TCP header; we call this variable RcvWindow. It is dynamically changing to reflect the current occupancy state of the receiver’s buffer. The sender should never have more than the current RcvWindow amount of data outstanding. This process is called flow control. Figure 2-5 illustrates the difference between the flow control as opposed to congestion control, which is described later in Section 2.2.

Figure 2-6 shows how an actual TCP session might look like. The notation 0:512(512) means transmitted data bytes 1 through but not included 512, which is a total of 512 bytes. The first action is to establish the session, which is done by the first three segments, which represent the three-way handshake procedure. Here I briefly summarize the three-way handshake. The

interested reader should consult another source for more details, e.g., [Stevens 1994; Peterson &

Davie 2007; Kurose & Ross 2010].

The first three segments are special in that they do not contain data (i.e., they have only a header), and the SYN flag in the header is set (Figure 2-2). In this example, the client offers RcvWindow = 2048 bytes, and the server offers RcvWindow = 4096 bytes. In our case, the client happens to be the “sender,” but server or both client and server can simultaneously be senders and receivers.

They also exchange the size of the future segments, MSS (to be described later, Table 2-1), and settle on the smaller one of 1024 and 512 bytes, i.e., 512 bytes. During the connection-establishment phase, the client and the server will transition through different states, such as LISTEN, SYN_SENT, and ESTABLISHED (marked in Figure 2-6 on the right-hand side). As stated earlier, both sender and receiver instantiate their sequence numbers randomly. In Figure 2-6, the sender selects 122750000, while the receiver selects 2363371521. Hence, the sender sends a zero-bytes segment

122750000:122750000(0)

The receiver acknowledges it and sends its own initial sequence number by sending 2363371521:2363371521(0); ack 122750000

Flow control Congestion control

Feedback:

“Receiver overflowing”

Feedback:

“Not much getting through”

Sender

Receiver Sender

Receiver

Sender

Receiver Sender

Receiver

Figure 2-5: Flow control compared to congestion control.

i.e., it sends zero data bytes and acknowledges zero data bytes received from the sender (the ACK flag is set). To avoid further cluttering the diagram, I am using these sequence numbers only for the first three segments. For the remaining segments, I simply assume that the sender starts with the sequence number equal to zero. In Figure 2-6, the server sends no data to the client, so the sender keeps acknowledging the first segment from the receiver and acknowledgements from

Client ConnectionEstablishment Data Transport(Initial phase: “Slow Start”)

Gap in sequence!

1024:1536(512), ack 0, win 2048

1536:2048(512), ack 0, win 2048

ack 1536, win 4096

2560:3072(512)

ack2048, win 3584

ack 3584, win 4096

4096:4608(512)

4608:5120(512), ack 0, win 2048 512:1024(512), ack 0, win 2048

ack 512, win 4096 SYN 2363371521:2363371521(0) ack 122750000, win 4096, <mss 512>

2048:2560(512), ack 0, win 2048 3072:3584(512), ack 0, win 2048 0:512(512), ack 0, win 2048

3584:4098

(512), ack0, win 2048

5120:5632(512), ack 0, win 2048

ack 5632, win 4096

ack 2048, win 4096 #7

CongWin = 4+1 = 5

CongWin = 8+1+1+1+1 = 12

#7

2560:3072(512)

2048:2560(512), ack 0, win 2048

3072:3584(512), ack 0, win 2048

#7

#8

#9

ack 2048, win 4096 #7

ack2048, win 3584(duplicate)

Figure 2-6: Initial part of the time line of an example TCP session. Time increases down the page. See text for details. (The CongWin parameter on the left side of the figure will be described later in Section 2.2.)

sender to receiver carry the value 0 for the sequence number (recall that the actual value of the server’s sequence number is 2363371521).

After establishing the connection, the sender starts sending packets. Figure 2-6 illustrates how TCP incrementally increases the number of outstanding segments. This procedure is called slow start, and it will be described later. TCP assigns byte sequence numbers, but for simplicity we usually show packet sequence numbers. Notice that the receiver is not obliged to acknowledge individually every single in-order segment—it can use cumulative ACKs to acknowledge several of them up to the most recent contiguously received data. Conversely, the receiver must immediately generate (duplicate) ACK—dupACK—for every out-of-order segment, because dupACKs help the sender detect segment loss (as described in Section 2.2).

Notice that receiver might send dupACKs even for successfully transmitted segments because of random re-ordering of segments in the network. This is the case with segment #7 (detail at the bottom of Figure 2-6), which arrives after segment #8. Thus, if a segment is delayed further than three or more of its successors, the duplicate ACKs will trigger the sender to re-transmit the delayed segment, and the receiver may eventually receive a duplicate of such a segment.