Re: SACK oddity

[Kevin Lahey <kml%patheticgeek.net@localhost>]

On Sun, 14 Apr 2024 08:57:21 -0400 (EDT)
Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:

> I'm seeing odd TCP behaviour with SACKs.  (It's between two NetBSD
> hosts, but I'm really asking about TCP - the NetBSD versions are
> oldish, but not so old that SACK wasn't well-specced at the time.)
> The trace looks odd to me; I'm wondering if it really is as odd as I
> think or if I'm missing something.

> 08:33:16.759131 IP me.64997 > them.22: . ack 3723 win 33580
> <nop,nop,timestamp 6 7> 08:34:50.058240 IP me.64997 > them.22: P
> 3329:3405(76) ack 3723 win 33580 <nop,nop,timestamp 191 7>
> 08:34:51.555460 IP me.64997 > them.22: P 3329:3405(76) ack 3723 win
> 33580 <nop,nop,timestamp 194 7> 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} >
> 
> The right edge of the SACK block equals the main TCP ACK sequence
> number, meaning it's SACKing data that's already ACKed normally.  This
> is what looks odd to me.  Is it, or am I confused?

At first glance, this looks like D-SACK (RFC2883), but it's kinda early
in the morning, so perhaps I'm missing something?

Good luck,

Kevin