Re: SACK oddity

[Greg Troxel <gdt%lexort.com@localhost>]

My standard advice is to use tcpdump2xplot from math/xplot-devel, which
will graph these in a way that makes them vastly easier to understand.

You may have to "jsr pc, munge_perl_to_catch_up_with_tcpdump" (to use the
pdp11 expression), but I suggest that this and then grasping the plots
is faster than staring at lines.

But yes, this looks odd.

I am assuming your tcpdump is on 'me'.
It is useful to tcpdump on both sides and then you can see loss more clearly.



  08:34:50.058240 IP me.64997 > them.22: P 3329:3405(76) ack 3723 win 33580 <nop,nop,timestamp 191 7>

normal segment

  08:34:51.555460 IP me.64997 > them.22: P 3329:3405(76) ack 3723 win 33580 <nop,nop,timestamp 194 7>

apparently normal retransmit presumably after RTO.  This has happened
without anything from the remote.

  08:34:51.556181 IP them.22 > me.64997: . ack 3405 win 4197 <nop,nop,timestamp 197 191,nop,nop,sack sack 1 {3329:3405} >

Notably them is echoing 191, so this is in response to getting the
earlier of the two.

I agree that  the sack block is bizarre and I tentatively sort it into
buggy.