AFAICT, the only significance of 1500 bytes is that it is the traditional MTU for 10/100 Ethernet gear - that, plus per [RFC2460] it is the minMRU for IPv6.
Given the tradition to want to "make everything look like an Ethernet", some have suggested that 1500 bytes can be considered as the practical "Internet cell size" in today's Internet. By that measure, perhaps 1501 bytes could be considered as a "jumbogram"? It might be convenient to have an 'N' such that we could say: "for packets no larger than N, we support doing things the old way and for packets larger than N we recommend doing things the new way". Is 1500 a reasonable value for N? (Or *is* there even a reasonable value for N?) Thanks - Fred [EMAIL PROTECTED] > -----Original Message----- > From: Fred Baker [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 31, 2007 2:55 PM > To: Templin, Fred L > Cc: John Heffner; Internet Area > Subject: Re: [Int-area] Larger MTUs > > for the moment, trying to distinguish between 10/100's 1500 byte > datagram and GigEthernet's 9K datagram, 9K is a jumbogram. The > numbers may not transfer, but the concept should transfer to other > distinctions. > > On Aug 1, 2007, at 5:46 AM, Templin, Fred L wrote: > > > I may have missed this, but how are we defining "jumbogram"? > > Is it anything larger than 1500bytes? Will it still be the > > same value going forward into the future? > > > > Thanks - Fred > > [EMAIL PROTECTED] > > > >> -----Original Message----- > >> From: Fred Baker [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, July 31, 2007 2:34 PM > >> To: John Heffner > >> Cc: Internet Area > >> Subject: Re: [Int-area] Larger MTUs > >> > >> personally, I would detect the speed (Macs do that) and set to 1500 > >> for 10/100 and 9K for 1000 (and 10000). It might be of value to try > >> sending a jumbogram to a neighbor, perhaps in the context > of an ARP/ > >> ND request (send a 9K packet containing an ARP request or ND > >> solicitation and see if you get a response) before doing so. > >> > >> On Jul 31, 2007, at 8:47 PM, John Heffner wrote: > >> > >>> Fred Baker wrote: > >>>> On Jul 28, 2007, at 2:05 AM, John Heffner wrote: > >>>>> The difficult problem is the router's behavior. If a subnet is > >>>>> running a mixed MTU, it's not clear what that router's interface > >>>>> MTU to that subnet should be. It would be nice for it to > >> forward > >>>>> the largest packets that it can support; however, to be > >> compliant > >>>>> with the spec it must generate ICMP PTB messages for any packets > >>>>> that are too large to be delivered. > >>>> here's an interesting gotcha. Macs run a 1000/100/10 Ethernet > >>>> interface and run a 1500 byte MTU/MRU regardless. The router can > >>>> correctly observe that it is 1 GBPS and send the jumbogram, the > >>>> switch can support the jumbogram, and have the Mac not accept the > >>>> packet. > >>>> Hence, there are variations of this that are beyond the router's > >>>> knowledge. > >>> > >>> Exactly. > >>> > >>> > >>>> I would suggest that the router respond with the ICMP when the > >>>> packet is too big for the configured interface MTU and not try to > >>>> predict the end system's or the switch's behavior. 4821 > >> encourages > >>>> the sender to use the largest segment size that it can verify > >>>> delivery of. Leave that to the end system. > >>> > >>> The question then is how to configure the router's MTU. The only > >>> safe way that won't break 1122/1981 for an Ethernet > >> interface would > >>> be to set it to 1500 bytes. But then it won't forward larger > >>> packets so jumbo-capable devices don't get the benefit of jumbo > >>> frames beyond their local subnet. Setting the router MTU larger > >>> will allow 4821 probing to work for jumbo-capable hosts, but then > >>> you risk breaking connectivity to hosts on your subnet with > >> smaller > >>> MTUs, from outside hosts/protocols with larger MTUs that rely on > >>> classical PMTUD (and aren't protected by the TCP MSS option). > >>> > >>> -John > >> > >> > >> _______________________________________________ > >> Int-area mailing list > >> [email protected] > >> https://www1.ietf.org/mailman/listinfo/int-area > >> > _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
