do we need to keep track of the window size sent from the receiver?
The window size that the receiver sends is the advertised window size and will be an upper limit for the actual window size in the sender. However, we have no way of knowing the actual TCP window size because we do not know the congestion window size in the sender.
Furthermore, we do not need the congestion window size or advertised window size when we estimate the RTT.
How so? Consider a series of (seq, ack), it is clear for the first two packet that the sample RTT should be the difference in capture time between the first two packets. But what about the RTT for packet with seq 1966093826? Which packet’s ack should we match it to?
The first ACK. The other ACKs are simply in reply to future packets that arrive at the destination but are not the packet that it expects. For example, if one packet is lost and next packets arrive successfully, then you will see a similar case of duplication ACKs. And is we discussed in the lectures, we are using any three duplicate ACKs as a sign that a packet is lost and retransmit that packet and update the congestion window size by cutting it into half.
Do we match seq 4006982773, 4006983404, 4006984784 to anything here? The last ACK 4006981393 is smaller than these, and 4006985268 is larger, we don’t capture any packet in between either. Also, wouldn’t piggybacking the ACK make RTT estimate larger than it should be by artificially delaying ACK?
We observed a set of packets of (seq, ack) of
even after we filtered for retransmitted packages, why would 1966099765 be sent before the ACK for it is received? Thanks.
Note that you will not necessarily get an ACK for every packet that you sent. For example, if you send packets 1, 2, and 3, you may only receive an ACK for 3, which will implicitly also ACK 1 and 2. In this case, you only have one sampled RTT by matching the ACK with packet 3 that you sent.