Re: SACK oddity
Mouse <[email protected]>
| Newsgroups | gmane.os.netbsd.devel.network |
|---|---|
| Message-ID | <[email protected]> |
> 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 [email protected]
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B