Re: Transmission of IPv6 Jumbograms as Atomic Fragments

[Justin Iurman <[e-mail]>]

Bob,

> Justin,
> 
> On Nov 18, 2021, at 6:00 AM, Justin Iurman <[e-mail]> wrote:
>> 
>> 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

> Bob
> 
> 
> 
>> Justin
>> 
>>  [1] https://netdevconf.info/0x15/session.html?BIG-TCP
>> 
>>> Fred,
>>> 
>>>> On Nov 17, 2021, at 3:39 PM, Templin (US), Fred L <[e-mail]>
>>>> wrote:
>>>> 
>>>> 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.
>>> 
>>> 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.
>>>> 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:[e-mail]]
>>>> Sent: Wednesday, November 17, 2021 3:27 PM
>>>> To: Templin (US), Fred L <[e-mail]>
>>>> Cc: 6man <[e-mail]>; Brian E Carpenter <[e-mail]>
>>>> 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 <[e-mail]>
>>>> 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:[e-mail]]
>>>>> Sent: Wednesday, November 17, 2021 1:39 PM
>>>>> To: Templin (US), Fred L <[e-mail]>; 6man <[e-mail]>
>>>>> 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:[e-mail]] On Behalf Of
>>>>>> [e-mail]
>>>>>> Sent: Wednesday, November 17, 2021 9:09 AM
>>>>>> To: [e-mail]
>>>>>> 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
>>>>>> [e-mail]
>>>>>> 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
>>>>>> [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
>>>> --------------------------------------------------------------------
>>>> --
>>>> ===============================================
>>>> David Farmer               Email:[e-mail]
>>>> Networking & Telecommunication Services
>>>> Office of Information Technology
>>>> University of Minnesota
>>>> 2218 University Ave SE        Phone: [phone]
>>>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>>>> ===============================================
>>>> --------------------------------------------------------------------
>>>> 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
> >> --------------------------------------------------------------------