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

[Gyan Mishra <[e-mail]>]

Dough 

I agree with what you and Brian stated that the IETF standards are future looking and not necessarily now in the present or near term future but further down the road.

As I stated I have written some design documents related to super Jumbo 9000 deployment that if my design guidelines are followed any enterprise or Service Provider can easily go Jumbo from and infrastructure perspective and just as overlay architectures  continue to be mainstream like vxlan evpn and vxlan PBB as examples as is IPv6 dual stack the theory of “as you build out a Super Jumbo infrastructure they will come” apps will come on board clammering for high throughout low cpu processing and latency and from that perspective from a network and host OS perspective we are definitely there now for super Jumbo 9000.  Even now in the mpls core I have deployed many networks to date bumping from 9216 to 65535 for future super jumbo for customers and host OS and NIC to eventually have enough memory bump mtu close to 65535 subtracting out mpls and misc overhead bytes.

The IETF being future minded and forward looking I can definitely see way down the road going from 16 bit to 32 bit field supporting up to 4.2Billion byte MTU is futuristic for even IPv6 but does not mean we throw in the towel and say it will never happen.

Cases and point is most networks would never have thought of going to 9000 super jumbo but with MPLS  or SR-MPLS or SRV6 core with customer edge AS overhead bytes such as IPSEC,  IPv6 next headers options evolution overhead, DMVPN overlay dual stack tunnels over MPLS overhead that will continue to be added and evolving requiring larger packet sizes it is impossible to predict the future but having flexibility and options available from a developer perspective always make sense versus being pigeonholed into a corner with no options or workarounds.

Gyan
 
Sent from my iPhone

> On May 20, 2019, at 4:45 AM, Tim Chown <[e-mail]> wrote:
> 
>> On 19 May 2019, at 02:30, Doug Barton <[e-mail]> wrote:
>> 
>>> 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?
> 
> 9K MTU is used pretty widely in R&E networks where large scale data transfers are increasingly routine.  The best example of a community shifting significant data volumes worldwide is probably the WLCG (worldwide Large Hadron Collider computing grid - http://wlcg.web.cern.ch/).  The WLCG is an interesting IPv6 case as they mandated a while ago that all the Tier 1 and 2 distributed storage nodes must be dual-stacked by this year, one reason for which was to support deploying IPv6-only worker CPU clusters which could then draw from those.  How many of their sites use 9K MTU, I don't know.   My colleague at Imperial College London thinks that they do not as yet, despite peaking at 40Gbit/s of data from CERN over IPv6, and recently being upgraded to 100G.  I'll ask further...
> 
> Tim
> 
>> Doug
>> 
>> 
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------