[General boards] [Fall 2018 courses] [Summer 2018 courses] [Winter 2018 courses] [Older or newer terms]

TCP Flow Control Question


Consider a scenario with two hosts, Alice and Bob. A web server running on Alice is trying to send data to a browser on Bob. For each TCP connection, Alice’s TCP stack maintains a buffer of 512 bytes and Bob’s TCP stack maintains a buffer of 1024 bytes. For simplicity, assume TCP sequence numbers began at 0 in this problem.

a) Bob’s stack received up to byte 560 in order from Alice, although its browser has only read up to the first 60 bytes. What will be the ACK and window in the TCP headers that Bob next sends to Alice?

Answer: Seq Number = 561 and window = 524

Why does the answer give a sequence number? Isn’t the question asking for ACK? Will the ACK be 560? Lecture 6 slide 42 makes me think it would be 560.


Yes there are places in the notes that don’t use the +1 to the received byte number but from my understanding, if the receiver gets byte with sequence number 1, it will ack with sequence number 2 (in the simplest case with no cumulative ack).

To answer your question, the ack IS a sequence number. To confirm receipt of byte with sequence number x, the ack will contain sequence number x + 1 (again in the simplest case without considering cumulative ack). With cumulative acks, the ack sent will be the highest byte, in order, received plus 1.

So if I receive all bytes through sequence number 4, I will ack with 5 because I have received 1 to 4 and need 5 now.
If the sender now gives sequence number 6, I will ack again with 5.
Sender gives 7, I will ack again with 5.
Sending gives 8, I will ack again with 5. This is the third duplicate ack, the sender should now give me 5 (in this simple scenario).
Sender gives 5, I will ack with 9 (i have received 1 to 8).

If someone else can confirm the above, that would be great. Thanks.


this is correct, the returned ACK will send the sequence number +1 since all bytes up to and including 560 were received in order. If it wasn’t in order it’d be sending the sequence number of the last packet received IN ORDER +1. So yeah 561 is right.


I think in slide 42, the sequence number start from 0. So 2K will take 0-2047, and the ack is 2048 which is 2047 + 1.


The review slides were inconsistent on this…slide 35, wouldn’t it be 91 for the ACK?


First, the answer should be ACK Number = 561.
Note that in each packet, we have an ACK number which represents what is the next byte that we are waiting to receive from the other side, and a sequence number, which is the number of the first byte in this packet.
Now if we receive a packet with sequence number N that contains K bytes, the bytes in that packet will have numbers N, N+1, N+2, …, N+K-1. As a result, if the packet only contains one byte, then the ACK that the other side will send will be equal to the sequence number + 1.
Now about the review slides case, the other side was expecting byte 90. This side sent a packet that contains bytes 90, 91, …, 109. The other packet has bytes 110, 111, … . Now because the first packet is lost, the other side still waits for byte 90, which is why the sequence number is 90.