Re: non-piggy-backed ACK with total IP length = 52

[Andrej van der Zee <andrejvanderzee () gmail com>]

Hi,

> >
> Sincce selective acking is used (both the SYN and SYN/ACK contain the "Permit SACK" option), I think the following 
> happened:
>
> - The client received the packet with seq 533, but waits to ACK it because of delayed ACK mechanism (which can also 
> be seen in frame 19, where it acks frame 17 after ~200ms)
> - The server has a very low retransmit timer and retransmits the segment with seq 533

I guess it is a matter of coincidence rather than a low retransmit timer. The retransmit timer just "went off" before 
the delayed ACK timer on the client. 

> - The client received the retransmission of the packet with seq 533. But as it sees it already has that data, it uses 
> the sack mechanism instead of the ack mechanism (without first determining if this is the special SACK case where 
> only the last segment was retransmitted).

Yes that could be the scenario i guess...
>

> But with the additional SACK options, no harm is done and it does still compy to the RFC IMHO

I think you are right.

Cheers,
Andrej

>
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe