Re: [IPv6] FW: I-D Action: draft-templin-6man-ipid-ext-00.txt

["Templin (US), Fred L" <[e-mail]>]

Tom, to the point on performance:

> Please provide references to these studies. Also, note IP
> fragmentation is only one possibility, PMTUD and transport layer
> segmentation is another and that latter seems more prevalent.

If by transport layer segmentation you mean GSO/GRO, it is not the same thing
as IP fragmentation at all. GSO/GRO provide a means for the application of the
source to transfer a block of data containing multiple MTU- or smaller-sized
segments to the kernel in a single system call, then the kernel breaks the
segments out into individual packets that are all no larger than the path MTU
and sends them to the destination. The destination kernel then gathers them
up and posts them to the local application in a reassembled buffer possibly
as large as that used by the original source. But, if some packets are lost,
the destination kernel instead sends up what it has gathered so far which
may be less than the block used by the original source.

IP fragmentation is very different and operates on a single large transport
layer segment instead of multiple smaller ones. And, the studies I am referring
to show that performance was most positively affected by increasing the
segment size even to larger than the path MTU. I implemented GSO/GRO
in the ion-dtn LTP/UDP implementation and noted that the performance
increase I saw was very minor and related to more efficient packaging
and not a system call bottleneck. Conversely, when I increased the segment
sizes to larger than the path MTU and intentionally invoked IP fragmentation
the performance increase was dramatic. You can see this in the charts I
showed at IETF118 intarea here:

https://datatracker.ietf.org/meeting/118/materials/slides-118-intarea-identification-extension-for-the-internet-protocol-00

Again, GSO/GRO address performance limitations of the application/kernel
system call interface which seems to have a positive performance effect for
some applications. But, IP fragmentation addresses a performance limitation
of transport layer protocols in allowing the transport protocol to use larger
segment sizes and therefore have fewer segments to deal with. This latter
service showed significant performance increases for LTP/UDP and historically
provided better performance for services like NFS over UDP. GSO/GRO does
not show a similar performance increase for LTP/UDP.

Fred

> In a
> lossy network, transport layer segmentation will likely have better
> performance than IP fragmentation since we can do selective ACKs (i.e.
> if a fragment is dropped the whole chain needs to be retransmitted). I
> suggest removing this and just provide the need for a larger
> identification field in IP fragmentation (the second half of the
> paragraph).

> -----Original Message-----
> From: Tom Herbert <tom=[e-mail]>
> Sent: Monday, December 04, 2023 2:30 PM
> To: Templin (US), Fred L <[e-mail]>
> Cc: IPv6 List <[e-mail]>
> Subject: Re: [IPv6] FW: I-D Action: draft-templin-6man-ipid-ext-00.txt
> 
> On Tue, Nov 28, 2023 at 1:42 PM Templin (US), Fred L
> <Fred.L.Templin=[e-mail]> wrote:
> >
> > 6man, here is a -00 draft that I am moving over here from intarea where it saw some earlier
> > discussion while paring down to focus only on IPv6 aspects. The previous draft version was
> > presented at the intarea session at IETF118, per the minutes:
> >
> > https://datatracker.ietf.org/doc/minutes-118-intarea-202311091400/
> >
> > The draft is titled: "IPv6 Identification Extension", and its goal is to make IPv6 fragmentation
> > and reassembly robust at least within limited domain networks to start with but also for the
> > future of more general open IPv6 Internetworks. This is one aspect of a comprehensive set
> > of services that should support better Internetworking performance through packet size
> > diversity. The draft proposes to update RFC8900.
> >
> > Please review and send comments,
> >
> 
> Hi Fred,
> 
> Here are some comments.
> 
> >From the draft:
> "Studies over many decades have shown that upper layer protocols often
> achieve greater performance by configuring segment sizes that exceed
> the path Maximum Transmission Unit (MTU). When the segment size
> exceeds the path MTU, IP fragmentation at some layer is a natural
> consequence."
> 
> Please provide references to these studies. Also, note IP
> fragmentation is only one possibility, PMTUD and transport layer
> segmentation is another and that latter seems more prevalent. In a
> lossy network, transport layer segmentation will likely have better
> performance than IP fragmentation since we can do selective ACKs (i.e.
> if a fragment is dropped the whole chain needs to be retransmitted). I
> suggest removing this and just provide the need for a larger
> identification field in IP fragmentation (the second half of the
> paragraph).
> 
> >From the draft: "A recent study [I-D.templin-dtn-ltpfrag] proved that
> configuring segment sizes that cause IPv4 packets to exceed the path
> MTU (thereby invoking IPv4 fragmentation and reassembly) provides
> substantial performance increases.. This contradicts decades of
> unfounded assertions to the contrary..."
> 
> It's not clear to me what that draft proves, nor what the substantial
> performance increases are. But even if it did prove something and
> "contradicts decades of unfounded assertions to the contrary", I'm not
> sure it's very relevant since that means there's been decades of
> implementation and burned in deployment based on these assertions. IMO
> this paragraph could be removed since it seems to be more about
> generally promoting the use of IP fragmentation and not extending it
> which is the topic draft.
> 
> >From the draft: "Following reassembly, if the Routing Header is
> present the destination resets the Routing Header Next Header field to
> the value cached in the Extended Fragment Header."
> 
> I think it will be much simpler to just say that the fragmentation
> option cannot be used in Destination Options before a Routing Header.
> 
> The Destination option is type is 00 which means skip if unknown. I
> believe this should be 01 to ensure that the destination host ensures
> that it sees the fragment and properly processes the packet.
> 
> >From the draft: "This allows the source to test whether a destination
> recognizes the Extended Fragment Header by occasionally sending a
> fragmented "probe" packet using the option."
> 
> It should be noted that IP is inherently a stateless protocol so
> probing like this is at most best effort-- it assumes bi-directional
> communications, doesn't work for multicast, or anycast, and has other
> failure cases.
> 
> Section 6 "IPv6 Network Fragmentation" would be major protocol changes
> to IPv6. This would allow IPv6 routers to fragment, and also
> intermediate nodes would be processing Destination Options. I think
> there needs to be a very clear motivation for this and what the exact
> protocol normative requirements are.
> 
> >From the draft: "Extended Fragment Header further MUST appear as the
> first option in the first Destination Options Header". Why is this
> requirement needed?
> 
> >From the draft: "Rather than encourage timely course corrections,
> however, the IETF somehow forgot that IP fragmentation and reassembly
> still serve as essential internetworking functions." This seems
> subjective or potentially provocative. I suggest removing it and
> probably all of Section 9 can be removed without loss of content for
> the main purpose of the draft.
> 
> >From the draft: "The option sets "act" to '00', "chg" to '1'". I'm not
> sure what it means to mark a Destination Options as modifiable in
> flight. I suppose this could be applied to Destination Options before
> the Routing Header, but I don't think that's the intent here. Maybe
> this is related to the idea of network node fragmentation?
> 
> IMO, Multicast and Anycast requirements shouldn't be relegated to an appendix.
> 
> 
> Tom
> 
> 
> 
> 
> 
> 
> 
> 
> > Fred
> >
> > -----Original Message-----
> > From: I-D-Announce <[e-mail]> On Behalf Of [e-mail]
> > Sent: Tuesday, November 28, 2023 1:26 PM
> > To: [e-mail]
> > Subject:  I-D Action: draft-templin-6man-ipid-ext-00.txt
> >
> > Internet-Draft draft-templin-6man-ipid-ext-00.txt is now available.
> >
> >    Title:   IPv6 Identification Extension
> >    Author:  Fred L. Templin
> >    Name:    draft-templin-6man-ipid-ext-00.txt
> >    Pages:   18
> >    Dates:   2023-11-28
> >
> > Abstract:
> >
> >    The Internet Protocol, version 4 (IPv4) header includes a 16-bit
> >    Identification field in all packets, but this length is too small to
> >    ensure reassembly integrity even at moderate data rates in modern
> >    networks.  Even for Internet Protocol, version 6 (IPv6), the 32-bit
> >    Identification field included when a Fragment Header is present may
> >    be smaller than desired for some applications.  This specification
> >    addresses these limitations by specifying an IPv6 Hop-by-Hop option
> >    for Identification Extension; it further provides a messaging service
> >    for fragmentation and reassembly congestion management.
> >
> > The IETF datatracker status page for this Internet-Draft is:
> > https://datatracker.ietf.org/doc/draft-templin-6man-ipid-ext/
> >
> > There is also an HTMLized version available at:
> > https://datatracker.ietf.org/doc/html/draft-templin-6man-ipid-ext-00
> >
> > Internet-Drafts are also available by rsync at:
> > rsync.ietf.org::internet-drafts
> >
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------