Subject: Re: perhaps time to check our TCP against spec?
To: Jonathan Stone <jonathan@dsg.stanford.edu>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: tech-net
Date: 04/06/1998 23:00:09
On Mon, 6 Apr 1998 21:05:53 -0700 (PDT) 
 Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:

 > Yup. Now, try this one on for size:
 > 
 >    --FDDI ring A---
 >        |
 >      Host A
 >        |
 >      --------------------------  Ethernet ----  router R
 >                                                   |
 >                                                   |
 >                                              --FDDI ring B---
 > 					              |
 > 					              |
 > 					              |
 >  					           Host B
 > 
 > Again, assume no PMTU, and that the two FDDI rings are disjoint.
 > 
 > With in_maxmtu, and without PMTU, as far as I can tell, A and B
 > negotiate FDDD-sized MSS.  That means traffic from B to A ends up
 > getting fragmented at the router R.

They don't "negotiate" anything.  MSS is _advertised_.  In "traditional"
BSD implementations, MSS was "negotiated", but this is extremely broken
on assymetric links, and is actually incorrect given the definition of
MSS!  Indeed, in the "traditional" implementation, if the peer was doing
Path MTU discovery, and in_localaddr -> FALSE (see below), we would
advertise an MSS that would completely defeat the peer's use of Path
MTU Discovery.

 > Doing this the traditional way, A advertises an Ethernet-sized MSS, so
 > TCP connections between A and B have A's MTU as an upper bound on MSS.

No, doing it the "traditional" way would depend on the setting of
subnetsarelocal, and the IP addresses of the hosts in question.

If in_localaddr -> TRUE, advertise:

	MTU of interface we're currently using to get to peer, minus
	size of TCP + IP headers.

...which means you could encounter fragmentation at the router.

If in_localaddr -> FALSE, advertise tcp_mssdflt (512).

...which means you're sending smaller segments than you could be.

Seems equally, if not more, broken as not using Path MTU Discovery and
advertising MSS the way we currently do.

 > Call me oldfashioned, but I tend to see this as a bug.

Call me newfangled, but if you're not using Path MTU Discovery in your
example above, you're going to encounter potential fragmentation problems,
period, regardless of MSS advertisement (unless you advertise tcp_mssdflt,
which is just silly, and won't happen if the subnet is considered "local").
So use it, that's what it was invented for.  Don't whine at me if you choose
not to use a feature of modern TCPs which was specifically designed to
address the above problem!

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 415 428 6939