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

[Tim Chown <[e-mail]>]

On 19 May 2019, at 02:30, Doug Barton <[e-mail]<mailto:[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]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------