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

[Tom Herbert <[e-mail]>]

On Thu, Dec 7, 2023 at 7:58 AM Templin (US), Fred L
<Fred.L.Templin=[e-mail]> wrote:
>
> 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.

Hi Fred,

Fewer segments, but NOT fewer packets. The net amount of work in the
system is unchanged when sending larger segments instead of smaller so
there won't be any material performance differences other than maybe
implementation effects at the host and no effect at routers. Segments
are the unit of congestion management and retransmission in a
transport protocol, but fragments are transparent to the transport
protocol-- this distinction can cause material issues in performance.

It's pretty easy to see why this is. Consider that the minimum number
of segments for a connection would be to use 64K segments and fragment
them. For a 1500 MTU one segment then would be sent in 43 fragments.
The problem is that if just one fragment is dropped in a segment then
the whole segment is retransmitted. Furthermore, the fragments
themselves are likely to be the cause of the congestion at routers. So
there is a high likelihood of creating congestion in the network and
needing a lot of retransmissions. Even if CWND goes to one, each
connection can still send 43 packets and SACKs don't help because
there's no granularity at 64K segments so congestion control really
wouldn't be effective. The net effect is likely to be very poor TCP
performance.

While I think there might be some incidental positive performance
effects in host implementation by using fragmentation, I really don't
see how it addresses any fundamental performance limitation in a
transport layer protocol like TCP. In fact, I don't see how IP
fragmentation could possibly be better than doing PMTUD with SACKs
especially on the Internet.

Tom




> 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
> > > --------------------------------------------------------------------
>