Subject: Re: perhaps time to check our TCP against spec?
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Kevin M. Lahey <firstname.lastname@example.org>
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
[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
>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.