Re: SACK oddity

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> It is useful to tcpdump on both sides and then you can see loss more
> clearly.

Yes, it would be.

In this case, I'm investigating because ssh to `them' hangs; I have no
good way to tcpdump on that end without an hour or so of travel time
each way (it's physically remote).

>   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.

Yes...but a second and a half seems long for a retransmit when a
typical RTT (send to ACK, as seen by `me') is <200ms.  Admittedly, TCP
has seen only a half-dozen packets, so it wouldn't have a very
confident RTT estimate.

>   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.

Ooh, well spotted.  Good point.  That probably means _something_.  The
second and a half delay between sending that segment and getting its
ACK/SACK almost certainly means something too.  Just not sure what.

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

Okay, so it's not just me, at least.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B