Subject: Re: perhaps time to check our TCP against spec?
To: Jason Thorpe <thorpej@lestat.nas.nasa.gov>
From: Kevin M. Lahey <kml@nas.nasa.gov>
List: tech-net
Date: 04/06/1998 18:51:15
In message <199804070126.SAA26749@lestat.nas.nasa.gov>Jason Thorpe writes
>On Mon, 6 Apr 1998 17:42:34 -0700 (PDT) 
> Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:

> > Here's another case:
> >                                                   
> >    Metricom Radio                     Metricom Radio        	
>		
> >    < 1200 byte MTU                    < 1200 byte MTU       
> >    |                                   |                     
> >    |                                   |                     
> >   machine A                           machine B
> >    |                                   |                     
> >    Ethernet NIC,                       Ethernet NIC,         
> >   currently no                        currently no           
> >     external                            external             
> >   connectivity                        connectivity
> > 
> > 
> > (The Ethernet NICs could be connected to an isolated home LAN, or to
> > terminators.)  Now, suppose machine A wants to establish a TCP
> > conection to machien B over the wireless radio.  Again, suppose that
> > both machiesn have the extant NetbSD code and aren' doing PMTU.
> >
> > What MSS will these machines compute and advertise?  Will it result in
> > fragmentation?  that's a really horrid thing ot do to the Metricom
> > radio, where there's a limit of about 10 packets/sec irrespective of
> > size.
>
>Both will advertise an MSS of ETHERMTU - sizeof(struct tcpiphdr), because
>ETHERMTU > METRICOMMTU, that is, assuming the Ethernet has an IP address
>assigned to it.  If not, they will advertise METRICOMMTU -
>sizeof(struct tcpiphdr).  "Where's the problem?"

The key issue here is the difference between the advertised MSS
and the largest packet to be sent.  NetBSD will in fact only
send out as large a packet as the interface will handle[*],
so that in this case, it can advertise an MSS of 1500, but it
will still do the right thing and only send out a packet of <1200
bytes.  Other TCP stacks should do the same.  If they don't,
it seems like a bug to me.  TCP packets should never be fragmented
coming out of the source machine, no matter what MSS has been
advertised.

Cheers,

Kevin
--
[*] I just committed a fix a few weeks ago involving TCP options 
and IP options where we used to fragment packets before sending
them out, in a few special cases. :-)