Revision history [back]

I didn't notice your link to the tcp_dupack.cap capture so now I can accurately answer your question.

The capture was taken during a TCP Recovery event (i.e., one or more segments were not received or were delivered out-of-order). The receiver was in TCP recovery so ACKed every data segment. Per Fast Retransmit/Fast Recovery RFC 5681 Section 3.2)) the snder waited for 3 duplicate ACKs before it retransmitted the first missing segment. Had that segment filled in the entire gap, the receiver would have resumed ACKing every other segment or two unless for the reasons discussed in my first answer it could not. In this capture the gap was not filled and had the the partners not agreed to use SACK the fast retransmission would have been followed by at least one "RTO" (i.e., a retransmission triggered by timeout). The latency caused by RTOs can greatly reduce throughput depending on the sender's retransmission timer period which varies among implementations from milliseconds (typical of those that set the timer dynamically) to several seconds. RTO latency is directly proportional to round-trip time (RTT) because the sender must wait for an ACK (any ACK) before it can send another segment. The latency caused by packet loss is reduced by TCP Fast Retransmit/Fast Recovery, SACK, and FACK because the reduce or possibly eliminate RTOs. If only when segment is missing, Fast Retransmit/Fast Recovery prevents an RTO provided there is sufficient data sent following that packet to generate 3 dupacks. When more than one packet is missing, an RTO is inevitable unless SACK or SACK+FACK are also employed; however, if the final segment of a PDU is smaller than the MSS, an RTO will occur because only full sized segments are ACKed. The receiver has no idea if a small packet is the end of a PDU or the result of the sender's cwnd (not to mention that TCP knows nothing about PDUs; it's an upper layer concept).

Had the capture been longer, we would have seen more packets sent within the gap without RTT delays thanks to SACK provided the receiver's window and the sender's congestion window sizes allowed.

The right edge of the gap continued to grow in frames 3, 5, and 7, as new data was received which begs the question, why did the gap in the SACK range grow despite the segments received in frames 2, 4, and 6? Those packets were in fact not received which conclusively demonstrates that the capture was taken on the sender's side of the connection. Had it been taken on the receiver's side, those packets would have been absent.

I didn't notice your link to the tcp_dupack.cap capture so now I can accurately answer your question.

The capture was taken during a TCP Recovery event (i.e., one or more segments were not received or were delivered out-of-order). The receiver was in TCP recovery so it ACKed every data segment. Per Fast Retransmit/Fast Recovery RFC 5681 Section 3.2)) the snder sender waited for 3 duplicate ACKs before it retransmitted the first missing segment. Had that segment filled in the entire gap, the receiver would have resumed ACKing every other segment or two unless for the reasons discussed in my first answer answer, it could not. In this capture the gap was not filled and had the the partners not agreed to use SACK the fast retransmission would have been followed by at least one "RTO" (i.e., a retransmission triggered by timeout). The latency caused by RTOs can greatly reduce throughput depending on the sender's retransmission timer period which varies among implementations from milliseconds (typical of those that set the timer dynamically) to several seconds. RTO latency is directly proportional to round-trip time (RTT) because the sender must wait for an ACK (any ACK) before it can send another segment. The latency caused by packet loss is reduced by TCP Fast Retransmit/Fast Recovery, SACK, and FACK because the they reduce or possibly eliminate RTOs. If only when one segment is missing, Fast Retransmit/Fast Recovery prevents an RTO provided there is sufficient data sent following that packet to generate 3 dupacks. When more than one packet is missing, an RTO is inevitable unless SACK or SACK+FACK are is also employed; however, employed. However, if the final segment of a PDU is smaller than the MSS, an RTO will occur because only full sized segments are ACKed. The receiver has no idea if a small packet is the end of a PDU or the result of the sender's cwnd (not to mention that TCP knows nothing about PDUs; PDUs because it's an upper layer concept).

Had the capture been longer, thanks to SACK we would have seen more packets sent within the gap without RTT delays thanks to SACK provided the receiver's window and the sender's congestion window sizes windows allowed.

The right edge of the gap continued to grow in frames 3, 5, and 7, as new data was received which begs the question, why did the gap in the SACK range grow despite the segments received in frames 2, 4, and 6? Those packets were in fact not received which conclusively demonstrates that the capture was taken on the sender's side of the connection. Had it been taken on the receiver's side, those packets would have been absent. absent.