Subject: Re: TCP MSS not adhered to properly when options present
To: Mark Allman <mallman@grc.nasa.gov>
From: Rick Byers <rb-netbsd@BigScaryChildren.net>
List: tech-net
Date: 11/30/2001 09:32:59
On Fri, 30 Nov 2001, Mark Allman wrote:
> > I am pretty much a novice when it comes to the networking code but
> > the way I understand it is the MSS options are exchanged when a
> > connection is created. However the option length may not be
> > constant during the lifetime of the connection (a host that sends
> > SACK blocks, something I'm currently working on, is a good example
> > of this).
>
> The SACK issue is pretty thin, I think. The only time that comes
> into play is when you have bi-directional bulk transfer, I think.
> And, that is pretty rare. I.e., SACK makes the size of the ACKs
> variable. (Some people have suggested that timestamps should be
> changed so that we only use them if our sending rate becomes "large"
> such that we need them for PAWS, but that is just a theory at this
> point.) It seems to me that the end-point that opens the connection
> passively can solve this problem. That end-point know whether or
> not timestamps will be used and can adjust things accordingly.
In my understanding of the specs, even if an end-point knew it would
allways be including 12 bytes of TCP options, its not supposed to use that
to adjust the MSS value it advertises. The MSS is the maximum IP packet
size minus 40 (i.e. doesn't include any options), and then the actuall
maximum data payload must be determined on a per packet basis after taking
any options into account...
Rick