Re: Transmission of IPv6 Jumbograms as Atomic Fragments

On Fri, Nov 19, 2021 at 1:00 AM Justin Iurman <justin.iurman@uliege.be> wrote:
>
> Brian,
>
> > Great news if... they are actually using it for production. Do you know anything
> > about that?
>
> 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

> Justin
>
> > Regards
> >    Brian
> >
> > On 19-Nov-21 03:00, Justin Iurman 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.
> >>
> >> Justin
> >>
> >>    [1] https://netdevconf.info/0x15/session.html?BIG-TCP
> >>
> >>> Fred,
> >>>
> >>>> On Nov 17, 2021, at 3:39 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com>
> >>>> 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:farmer@umn.edu]
> >>>> Sent: Wednesday, November 17, 2021 3:27 PM
> >>>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> >>>> Cc: 6man <ipv6@ietf.org>; Brian E Carpenter <brian.e.carpenter@gmail.com>
> >>>> 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 <Fred.L.Templin@boeing.com>
> >>>> 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:brian.e.carpenter@gmail.com]
> >>>>> Sent: Wednesday, November 17, 2021 1:39 PM
> >>>>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>; 6man <ipv6@ietf.org>
> >>>>> 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:i-d-announce-bounces@ietf.org] On Behalf
> > Of
> >>>>>> internet-drafts@ietf.org
> >>>>>> Sent: Wednesday, November 17, 2021 9:09 AM
> >>>>>> To: i-d-announce@ietf.org
> >>>>>> 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
> >>>>>> I-D-Announce@ietf.org
> >>>>>> 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
> >>>>>> ipv6@ietf.org
> >>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>>>> --------------------------------------------------------------------
> >>>>>>
> >>>>
> >>>> --------------------------------------------------------------------
> >>>> IETF IPv6 working group mailing list
> >>>> ipv6@ietf.org
> >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>> --------------------------------------------------------------------
> >>>> --
> >>>> ===============================================
> >>>> David Farmer               Email:farmer@umn.edu
> >>>> 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
> >>>> ===============================================
> >>>> --------------------------------------------------------------------
> >>>> IETF IPv6 working group mailing list
> >>>> ipv6@ietf.org
> >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>> --------------------------------------------------------------------
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> IETF IPv6 working group mailing list
> >>> ipv6@ietf.org
> >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> --------------------------------------------------------------------
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------