I am a bit confused with following capture As I red SACK must acknowledge last/highest in-order segment and hints about subsequent received segments after missing one. But in this capture I see that in SACK option field numbers are not greater than ACK number but smaller instead. Here is the partial damp https://www.cloudshark.org/captures/9b04d7772096 asked 04 Jun '15, 04:37  mongolio edited 05 Jun '15, 03:01 |
One Answer:
That's a D-SACK, not a SACK. D-SACK is an extension to SACK, and is used to tell the sender that one or more segments were retransmitted even though they were already acknowledged. See RFC 2883. answered 04 Jun '15, 05:19  Jasper ♦♦ showing 5 of 8 show 3 more comments |
Thanks a lot. I red RFC 2883 and now can’t understand why in my example receiver sends 3 ACK with D-SACK option instead of sending one - block of duplicated packets forms contiguous sequence of data:
5381090-5382450
5382450-5383810
5383810-5385170
hard to say, because you keep posting screenshots that have been cut off. Screenshots are always a lot harder to read than a real capture file, but if you also leave out IPs and Frame indexes it is basically useless for tracking TCP behavior and identifying why a diagnosis was made.
My guess is that the stack decided to tell the sender each time a spurious retransmission arrives directly that it was not required. Other than acknowledging packets there is not delay mechanism to do that for multiple segments, because a stack has absolutely no reason to expect multiple spurious retransmission in a row.
Added partial capture file to initial post
As I guessed, the D-SACKs are for the three retransmissions.
As I understood RFC2883 this can be done with one ACK containing full range of segments from 5381090 to 5385170, instead of sent ACK for each retransmitted packet. Is it depends on individual TCP algorithm realization or I misunderstand RFC?
And to be honest I can’t understand why we need such an explicit notification of duplicate frames - previously I have thought that if sender would miss some ACKs but would receive some subsequent ACKs it will result in all segments successfully ACKed. For e.g. if ACK for segment 10 and 11 were lost but ACK for segment 12 arrived timely than sender will implicitly ACKs segment 10 and 11 cos TCP use cumulative ACKs.
It depends on the individual TCP stack. And D-SACK is trying to help the sender adjusting it's sending behavior by giving feedback.
Jasper, normally if sender sent retransmit by timeout (not by fast retransmit) then it will decrease CWND not by the MD rule but till the initial CWND value and start with the slow-start algorithm?
Most stacks I've seen do that, yes, so on RTO based retransmissions you see a slow start (that's actually the only time you'll still see a slow start at all these days). Again, this behavior is stack dependent, so it may or may not happen.