Subject: Re: perhaps time to check our TCP against spec?
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Kevin M. Lahey <kml@nas.nasa.gov>
List: tech-net
Date: 04/07/1998 18:59:07
In message <199804080111.SAA10763@Whisk.DSG.Stanford.EDU>Jonathan Stone writes
>Isn't the requirement for accepting 576 byte IP datagrams still around
>even in IPv6?  even there, some reasonable non-PMTU solution is needed
>for IPmulticast.

[As an aside, the minimum MTU for IPv6 has been moved up to 1280 bytes.  
Link layers that have smaller MTUs will have to have link layer driver 
hacks to fragment and reassemble across the link.  If anybody wants
to scream about it, now would be a real good time...]

>But there, someone I'd say someone doing in_maxmtu has decided they
>*do* want fragmentation, and to heck with it.  But that's another case
>where I'd prefer the historic `negotiation' and to punt on in_maxmtu
>altogether.  Same with adding extra headers for mobile encapsulation.

>Until, that is, PMTU becomes ubiqutious. Which it isn't, and won't be
>for some time.  (Maybe as long as SACK, mmm?.) I think you and Jason
>have a real group-think problem going there: you do want PMTU, and are
>prepared to ignore the lossage it causes non-PMTU hosts.  To the point
>where, it seems, you refuse to even acknowledge the severity of the
>problems it causes to people who aren't so fortunate.

I have the same fear, and lots more besides.  I'm a paranoid kinda
guy.  That's why I'm happy to be having a discussion about this stuff.
I checked back with the TCPIMPL mailing list archives 
(ftp://ftp.sgi.com/other/tcp-impl/mail.archive), and found
that my memory wasn't totally shot -- this stuff was discussed 
there, too, with inconclusive results.  The MSS advertisement issue was 
specifically beaten to death.

Since you'll all just run out and read the archive, I know
I better point out that it looked to me like the consensus on
a conservative value was the interface MTU, rather than
max(all interfaces).  If no one objects, I'd be delighted 
to add a knob to allow that tweak.  There was significant
enthusiasm for max(all interfaces) [and I want it] so I'll
leave that in as well.  There was not much enthusiasm for, 
and there was no insistance on, "negotiated MSS".

>The simple solution is for me to stop using NetBSD and to advise other
>people here at Stanford to do the same thing.
>Is that really what you want?

Frankly, it doesn't matter to me.  If I wanted everybody in the
world to run my code, I'd be hacking Linux.  Now, OTOH, if somebody 
looks me in the eye and says politely, "Gee, Kevin, I 
think you missed a case, and if you put this knob into the
stack, it sure would help me (and possibly others) out...",
THAT would matter to me.  I already spent my morning ride on 
CalTrain trying to fix up the loopback MSS to do what you said 
you needed it to do.

I'm perfectly willing, even delighted, to discuss this stuff 
with you; you and I been discussing TCP performance issues in 
private mail for at least a couple of years, and I appreciate
your input.  I just feel more than a little patronized here, 
which is not what I feel when I deal with lots of other TCP 
wizards.  I've read every paper in your bibliography, and then 
some.  I read about a third of Vern Paxson's dissertation 
over the winter holiday, and I plan to read the rest of it RSN.  
I know that lots of other NetBSD folks can say the same, or 
better...

>Should I stop?  If you'd rather I did, I will.

Not at all.  We want to get this right;  I'd just like to
turn down the flame-o-meter a bit.  It'd be better if
I did it first, but, oh, well.

Kevin