Subject: Re: kern/9085: enabling RFC1323 support causes some TCP connectionsto stall
To: NetBSD Networking Technical Discussion List <email@example.com>
From: Ignatios Souvatzis <firstname.lastname@example.org>
Date: 02/29/2000 10:23:33
On Tue, Feb 29, 2000 at 01:56:58AM -0500, Greg A. Woods wrote:
> [ On Monday, February 28, 2000 at 16:36:35 (-0800), Kevin Lahey wrote: ]
> > Subject: Re: kern/9085: enabling RFC1323 support causes some TCP connectionsto stall
> > In message <m12PZfh-000g5eC@most.weird.com>Greg A. Woods writes
> > >
> > >That reminds me of a question I have been stewing over ever since this
> > >topic was first broached: Is there any way for a gateway machine to
> > >effectively turn off the use of rfc1323 on all traffic it handles?
> > You'd have to rewrite every TCP packet that went past to remove the
> > timestamp options. That seems pretty bogus.
> Yeah, that's a bit much alright, especially when fragmentation gets into
> the picture too....
> > It'd also be impossible
> > to do unless you were *certain* that packets only got out via the gateway.
> Well, if you are the gateway and you're about to copy a packet to the
> outbound interface, it should be pretty obvious whether or not you
> should strip the timestamps....
If you're about to gateway a packet, you shouldn't touch _TCP_ options at
- The only reason this is a small performance problem sometimes is,
that VJ compressed TCP links on SLIP and PPP try to transparently
compress the TCP header, too, and can't do this when TCP options are there.
- The only reason this is an operational problem, leading to _severe_
performance penalties, is that some VJ implementations are (or used to be)
[I guess the latter point also applies to NAT.]
Other than this, the 1323 stuff only works end-to-end, and shouldn't be
noticed by anybody else.
* Progress (n.): The process through which Usenet has evolved from
smart people in front of dumb terminals to dumb people in front of
smart terminals. -- email@example.com (obscurity)