Re: SACK oddity

Kevin Lahey <[email protected]>
Newsgroups gmane.os.netbsd.devel.network
Message-ID <20240414092333.33d55baa@sode>
On Sun, 14 Apr 2024 08:57:21 -0400 (EDT)
Mouse <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.