James Carlson wrote: > Garrett D'Amore writes: > >> James Carlson wrote: >> >>> Garrett D'Amore writes: >>> >>> >>>> I think its time someone here took a stand. 9000 bytes is a good size >>>> because it is nearly universal, and is sufficient to hold an 8K NFS block. >>>> >>>> >>> "Taking a stand" here means being deliberately incompatible with some >>> other vendors. >>> >>> >> Only a tiny, tiny minority of vendors who for some reason think it is ok >> to support a jumbo frame that is *less* than 9000 bytes. I"ve only seen >> one case of that, from a very low end gigabit NIC. (Which uses around a >> 7K jumbo frame, I think.) I think those devices could just be >> considered "incompatible" with *everyone* else. :-) >> > > No. It's also toxic with those vendors who choose to use something > more than 9000 as well (such as, I think, 9180 on Cisco boxes). > > Your MTU is my MRU, at least when a shared medium is involved. >
True. But I was assuming that all of the Jumbo Frame capable equipment could be configured not to send a frame larger than 9000 bytes. Maybe this was a false assumption. In the case of switches, any value greater than 9000 is sufficient, since they don't generally generate traffic of their own. In the case of *routers*, I would _hope_ that the value would be tunable. > The last survey of this I remember seeing was: > > http://darkwing.uoregon.edu/~joe/jumbo-clean-gear.html > Note that even he marks a boundary at 9000 bytes. :-) If it can't support 9000 bytes, then it really isn't suitable for use with jumbo frames. > >>>> A very few devices support 16K or even higher, but the utility of such >>>> large MTUs is probably somewhat limited... even at 10Gb. And the >>>> >>>> >>> What if one of these other vendors "takes a stand" on 12K just to >>> spite us? Or if the IEEE itself finally decides to set a standard in >>> this area and doesn't pick the same value? >>> >>> >> The former would be hard, because it would be incompatible with a *lot* >> of devices that simply cannot do 12K. They'd be cutting off their nose >> to spite their face. The latter seems incredibly unlikely for the same >> reason. >> > > I agree that 9000 is "likely." I'm not so sure I trust the other > vendors involved here enough to say that it's certain. > > >>> I think we're on really shaky ground here. I completely agree with >>> having a default jumbogram size, I agree with making it 9000, and I >>> agree with making it "hard" to change. I don't agree that we ought to >>> make it completely unchangeable just to force the issue. >>> >>> >> Okay, I didn't necessarily mean to say there would *no* way to change >> it, only that changing it should be something almost never done, and >> only then by opening up the hood, so to speak. A choice of some value >> other than 9000 is akin to choosing a different inter-packet gap >> timing... there may be some unusual application for it, but I'm not sure >> it deserves "first class" support (including the same level of QA >> coverage!) that the reasonable default gets. >> > > Fair enough; it shouldn't be the common path. > > Okay, I think this sounds like consensus. :-) -- Garrett
