Re: [[e-mail]: New Version Notification for draft-jones-6man-historic-rfc2675-00.txt]

[Doug Barton <[e-mail]>]

On 5/9/19 2:45 PM, Brian E Carpenter 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.

I agree with Brian's reasoning, and wanted to raise one other point that 
I haven't seen mentioned.

In IPv4 world the only way to increase throughput is to send the same <= 
1500 packets faster and faster, because "PMTU is hard." 4821 didn't 
really help in this area, and as the speed of light isn't likely to 
change any time soon, we're pretty much stuck.

We have a little more hope for IPv6 though. My understanding is that by 
and large folks are being smarter about filtering ICMPv6, so "better" 
PMTU support is at least a reasonable goal.

We currently face limitations for massive packets in hardware/silicon, 
but that will get better over time. In some measure on its own, and will 
continue to improve for network gear if the market demands it.

For some time now I've been kicking around the idea in my brain that one 
way we could get more of both content and eyeball networks enthused 
about IPv6 would be to promote widespread support for 9k packets. I was 
doing that on an internal network 10 years ago, and I'd like to hope 
that both the hardware and software have improved since then. There will 
no doubt be some pain involved, but if people are willing to put the 
effort in it will have a large upside.

We may never get to the point where jumbograms are practical, and if we 
do, we may not want to implement them as 2675 describes. But if it's not 
hurting anything now, why put it out to pasture?

Doug