Subject: Re: Transmission of IPv6 Jumbograms as Atomic Fragments

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 17 Nov 2021 23:39:37 +0000

Let me add a bit more clarity, then. IPv6 made a bit of a mistake when it presumed that the
only reason a packet might need an Identification value was to support the fragmentation
and reassembly process. Hence, the Identification was strictly tied to the Fragment Header.
But, it turns out there are other reasons to include an unpredictable ID with an IPv6 packet
(jumbos included) that have nothing to do with fragmentation. Since the only way to get
an Identification in IPv6-land is to include a Fragment Header, then that is just what we are
going to have to do. – again, jumbos included.

Thanks - Fred

From: David Farmer [mailto:[email-masked]]
Sent: Wednesday, November 17, 2021 3:27 PM
To: Templin (US), Fred L <[email-masked]>
Cc: 6man <[email-masked]>; Brian E Carpenter <[email-masked]>
Subject: Re: [EXTERNAL] Re: Transmission of IPv6 Jumbograms as Atomic Fragments

While I see no reason to depreciate RFC2675, without evidence of actual active use of jumbograms or at least an intent to use them, but for the issue you describe prevents it, I see no reason to advance the update you propose.

Even in the R&E networking community where we make regular use of data grams larger than 1500 bytes, I’m not aware of the use of, or even a desire to use, jumbograms.

Thanks

On Wed, Nov 17, 2021 at 16:45 Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Brian, I came through the supercomputer lab at NASA Ames in Mt View CA in 1996/7
where HiPPI was heavily used. I didn't spend much time there, but enough to get a
rough read that large packets are plausible.

At some time not long after that, I had the good fortune to meet Dave Borman and
asked him about RFC2675 with a "YMBK" pre-disposition toward the concept. Dave
assured me that the document was serious, and I do not see evidence that it has
been deprecated.

So, do I know of any such mega-links? Not offhand, but AFAICT RFC2675 is still part
of the IPv6 architecture and needs to be honored as such.

Thanks - Fred

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]<mailto:[email-masked]>]
> Sent: Wednesday, November 17, 2021 1:39 PM
> To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
> Subject: [EXTERNAL] Re: Transmission of IPv6 Jumbograms as Atomic Fragments
>
> EXT email: be mindful of links/attachments.
>
>
>
> Fred,
>
> Is there any evidence of usage of jumbograms? To my knowledge, even the high energy phsyics community, one of the main proponents of
> jumbograms back in the days when HIPPI seemed important, doesn't use them, despite extensive use of IPv6 for bulk data.
>
> Regards
>     Brian
>
> On 18-Nov-21 06:54, Templin (US), Fred L wrote:
> > Here is a new draft that may be of interest. It is a quick read (~2pgs) and proposes to
> > update RFC2675 by permitting transmission of IPv6 jumbograms as atomic fragments.
> >
> > Please post comments to the list.
> >
> > Fred
> >
> > -----Original Message-----
> > From: I-D-Announce [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
> > Sent: Wednesday, November 17, 2021 9:09 AM
> > To: [email-masked]<mailto:[email-masked]>
> > Subject: I-D Action: draft-templin-6man-jumbofrag-00.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >
> >
> >          Title           : Transmission of IPv6 Jumbograms as Atomic Fragments
> >          Author          : Fred L. Templin
> >     Filename        : draft-templin-6man-jumbofrag-00.txt
> >     Pages           : 4
> >     Date            : 2021-11-17
> >
> > Abstract:
> >     Internet Protocol, Version 6 (IPv6) provides a service for
> >     transmission of IPv6 packets larger than 65,535 octets known as
> >     "jumbograms".  Such large packets are not eligible for fragmentation,
> >     and the current specification forbids the inclusion of a fragment
> >     header of any kind.  However, some implementations may wish to
> >     include an Identification value with each jumbogram; hence this
> >     document proposes the transmission of IPv6 jumbograms as "atomic
> >     fragments".
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-templin-6man-jumbofrag/
> >
> > There is also an htmlized version available at:
> > https://datatracker.ietf.org/doc/html/draft-templin-6man-jumbofrag-00
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > [email-masked]<mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email-masked]<mailto:[email-masked]>
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--
===============================================
David Farmer               Email:[email-masked]<mailto:[email-masked]>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Bob Hinden <[email-masked]>
Date: Wed, 17 Nov 2021 16:41:04 -0800

Fred,

> On Nov 17, 2021, at 3:39 PM, Templin (US), Fred L <[email-masked]> wrote:
> 
> and reassembly process.

If what you want is some sort of identification field, it would be easier for you to propose an extension header that does that and see if you can build a consensus around that.

In my view, trying to do that by modifying IPv6 Jumbograms (that I don’t know of anyone uses these days) to include a fragment header, makes little sense to me.

Bob

> Hence, the Identification was strictly tied to the Fragment Header.
> On Wed, Nov 17, 2021 at 16:45 Templin (US), Fred L <[email-masked]> wrote:
> > From: Brian E Carpenter [mailto:[email-masked]]
> > To: Templin (US), Fred L <[email-masked]>; 6man <[email-masked]>
> > > From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
> > > To: [email-masked]
> > > [email-masked]
> > > [email-masked]
> [email-masked]
> David Farmer               Email:[email-masked]
> [email-masked]

---

From: Justin Iurman <[email-masked]>
Date: Thu, 18 Nov 2021 15:00:30 +0100 (CET)

Bob,

If this one can help, I remember a talk [1] ("Big TCP", slides and video both available) back to July during the Netdev conference. The main idea is to use IPv6 Jumbograms to reduce the overhead of the TCP stack. It is used internally by Google.

Justin

  [1] https://netdevconf.info/0x15/session.html?BIG-TCP

> If what you want is some sort of identification field, it would be easier for
> you to propose an extension header that does that and see if you can build a
> consensus around that.
> 
> In my view, trying to do that by modifying IPv6 Jumbograms (that I don’t know of
> anyone uses these days) to include a fragment header, makes little sense to me.
> 
> Bob
> 
> 
> 
>> While I see no reason to depreciate RFC2675, without evidence of actual active
>> use of jumbograms or at least an intent to use them, but for the issue you
>> describe prevents it, I see no reason to advance the update you propose.
>> 
>> Even in the R&E networking community where we make regular use of data grams
>> larger than 1500 bytes, I’m not aware of the use of, or even a desire to use,
>> jumbograms.
>> 
>> Thanks
>> 
>> > Is there any evidence of usage of jumbograms? To my knowledge, even the high
>> > energy phsyics community, one of the main proponents of
>> > jumbograms back in the days when HIPPI seemed important, doesn't use them,
>> > despite extensive use of IPv6 for bulk data.
>> >
>> > Regards
>> >     Brian
>> >

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Thu, 18 Nov 2021 15:23:44 +0000

Bob, what I want is exactly the Identification field that is found in the Fragment Header
while simply leaving the rest of the fields of that header set to 0 - there is no cause for
defining a new IPv6 extension header. And, a quick scan of my draft shows how very
minor the updates to RFC2675 really are.

Again, jumbos are part of the architecture (which you helped establish!) and allowing IPv6
packets of all varieties to include an Identification (jumbos included) is how we move the
architecture into the future.

Thanks - Fred

> From: Bob Hinden [mailto:[email-masked]]
> Sent: Wednesday, November 17, 2021 4:41 PM
> Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>
> Subject: Re: Transmission of IPv6 Jumbograms as Atomic Fragments
> 
> Fred,
> 
> > While I see no reason to depreciate RFC2675, without evidence of actual active use of jumbograms or at least an intent to use them, but
> for the issue you describe prevents it, I see no reason to advance the update you propose.
> >

---

From: Bob Hinden <[email-masked]>
Date: Thu, 18 Nov 2021 08:25:55 -0800

Justin,

> If this one can help, I remember a talk [1] ("Big TCP", slides and video both available) back to July during the Netdev conference. The main idea is to use IPv6 Jumbograms to reduce the overhead of…

Thanks, that is interesting.  However, unlike what Fred is proposing, they are using it to send larger packets (that is, what Jumbograms were designed to do), not add a fragmentation header to get an identification field (an not send packets larger than can be done in the IPv6 base header).

Bob

---

From: Justin Iurman <[email-masked]>
Date: Thu, 18 Nov 2021 17:32:15 +0100 (CET)

Bob,

>> If this one can help, I remember a talk [1] ("Big TCP", slides and video both
>> available) back to July during the Netdev conference. The main idea is to use
>> IPv6 Jumbograms to reduce the overhead of the TCP stack. It is used internally
>> by Google.
>> 
> 
> Thanks, that is interesting.  However, unlike what Fred is proposing, they are
> using it to send larger packets (that is, what Jumbograms were designed to do),
> not add a fragmentation header to get an identification field (an not send
> packets larger than can be done in the IPv6 base header).

Indeed, but it was more a reply to your initial question about IPv6 Jumbograms on whether it is used or not (i.e., "that I don’t know of anyone uses these days").

Justin

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 18 Nov 2021 17:16:07 +0000

Templin (US), Fred L wrote on 18/11/2021 15:23:
> while simply leaving the rest of the fields of that header set to 0

Do you have a use case in mind for the ID field?

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Nov 2021 13:39:26 +1300

Great news if... they are actually using it for production. Do you know anything about that?

Regards
    Brian

On 19-Nov-21 03:00, Justin Iurman wrote:
>>> But, it turns out there are other reasons to include an unpredictable 
ID with an
>>> IPv6 packet
>>> So, do I know of any such mega-links? Not offhand, but AFAICT RFC2675 
is still
>>> part
>>>>> From: I-D-Announce [mailto:[email-masked]] On Behalf 
Of
>>>>> [email-masked]

---

From: Justin Iurman <[email-masked]>
Date: Fri, 19 Nov 2021 09:59:41 +0100 (CET)

Brian,

> Great news if... they are actually using it for production. Do you know anything

I'm afraid I don't have more details, sorry. Feel free to contact Eric Dumazet for that.

Justin

---

From: Tom Herbert <[email-masked]>
Date: Fri, 19 Nov 2021 07:47:39 -0800

> I'm afraid I don't have more details, sorry. Feel free to contact Eric Dumazet for that.

Here's a link to slides and video of Eric's presentation:
https://netdevconf.info/0x15/session.html?BIG-TCP. Knowing Eric and
Google, I'd say it's pretty likely they have deployed this, it follows
a trend over the past few years where they've been working to increase
MTU and MSS in their datacenters.

Tom