Re: [internet-drafts@ietf.org: New Version Notification for draft-jones-6man-historic-rfc2675-00.txt]

6MAN

Here is my take on jumbograms as I have done extensive research, testing and deployment of Jumbo frames within enterprises as well as super jumbo.

Jumbo = any frame size greater then 1500 = 1501 to 8999
Super Jumbo = any frame sizes greater then 9000 = 9000 to 65535
Jumbograms 16 bit to 32 bit field change 65536 to roughly 4.2Billion bytes

So really the two manor benefits of Jumbo is cpu processing and throughout gains as you in

Sent from my iPhone

> On May 9, 2019, at 5:45 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
>> On 09-May-19 18:29, Tom Jones wrote:
>> On Wed, May 08, 2019 at 06:07:51PM +0200, Ole Troan wrote:
>>>> Hello 6man,
>>>> 
>>>> We have put this together to change the status of RFC2675 to Historic
>>>> and would like to request discussion in the working group.
>>> 
>>> IPv6 jumbograms was intended for some super computer inter connect with a massive MTU.
>>> I don't know of any use of it, but is it harmful if the specification is left there in place?
>>> 
>>> I don't expect any implementation supporting it unless they also support data-link layers with an MTU > 64K.
>>> Or is that the problem you are trying to solve, that a TCP implementation must handle datagrams larger than 64K?
>>> Is there any other solution?
>> 
>> I came to this from as an operating system maintainer, removing
>> Jumbograms is a one time ~350 line diff and it saves us maintaining
>> complexity in our v6 stack. 
>> 
>> Preparing this draft it is clear to me that Jumbograms are being carried
>> forward in the RFC series 'just because'.
> 
> Yes, just because the original motivation still remains potentially valid.
> 
> But since the RFC itself states that support is optional, and only applies where there is a physical interface capable of supporting in, each stack maintainer may freely choose whether to support it.
> 
>> Most of the time they are an
>> off hand mention, in some cases there are changes to protocol formats to
>> handle the protocol. 
> 
> I'd have thought there was also work in not supporting it, too, to send the required ICMP errors in reply to a Jumbo Payload option or IPv6 Payload Length == 0. Even if we obsoleted the option, that would remain necessary.
> 
>> This seems like a lot of work for a protocol with no known deployments
>> on the Internet.
> 
> There is less work involved in leaving the RFC alone than in obsoleting it.
> 
>   Brian
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------