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