Thanks for these thoughts, Herbie, and see below for follow-up: Fred
> -----Original Message----- > From: Robinson, Herbie [mailto:herbie.robin...@stratus.com] > Sent: Tuesday, March 22, 2022 12:58 PM > To: Templin (US), Fred L <fred.l.temp...@boeing.com>; int-area@ietf.org > Subject: RE: IP Parcels improves performance for end systems > > I think this is a really good idea; although, it could be a bridge too far. > It certainly won’t get implemented quickly. I still remember > implementing path MTU discovery thinking about the big performance win I was > going to get in IPv6 from 9K packets (vs 1500 byte packets) > only to discover that certain router vendors had interpreted one of the RFCs > to mean they didn’t have to send packet-too-big messages if > the packet in question was larger then 1500 bytes (because one of the RFCs > stated that IPv6 implementations only have to support 1500 > bytes). Yes, the RFCs could be interpreted that way, but that interpretation > clearly violates the intent (to make path MTU reliable). The real > world upshot of that is that anything over 1500 bytes is still a black hole > and using path MTU can really only get you a whopping 300 bytes > (from 1200 to 1500). Yes, the limitations of traditional path MTU discovery have been well understood for a long time, which have motivated active probing schemes such as RFC4821 and RFC8899. But even these tools alone are not likely to find MTUs in excess of ~9KB in the near future - maybe not even in our lifetimes. But, fortunately, we can do much better than that with IP Parcels in the very near term. > Not trying to be negative, but 4M parcels are really looking to the future > and that's only a good thing if we realize > what we are doing. Fortunately, we know what we are doing. IP Parcels can be supported in all size ranges in the very near future and without changing out any hardware, including links, bridges switches and routers. They can be supported in the near term by establishing an Adaptation Layer for the Internet using AERO/OMNI. All that is required is for Parcel-capable end systems to configure an OMNI interface as point of connection to a virtual link spanning the network. The interface provides entry into an adaptation layer below the IP layer but above the data link layer. The adaptation layer uses encapsulation and two levels of fragmentation so that even the largest possible parcel (~4MB) can be conveyed across the virtual link with no change to any underlying network gear. In my talk, perhaps I spent too much time trying to explain the scenarios for discovering and using Parcel-capable links. When in fact, if the OMNI virtual link is extended nearly to the edges of the network then the only need for Parcel-capable (physical) links would be at the very extreme edges. And, no middleboxes would need to change. > Getting into the details: > > Using "segment" as the term to describe the individual parcel contents is > probably not a good idea, because TCP has segments but most > other ULPs do not. The term "segment" is also used by the Licklider Transmission Protoocl in the same way as for TCP, and I assume QUIC also has an ULP unit of data that becomes the retransmission unit in case of loss. Perhaps I can add a definition to the document that defines "segment" as "the ULP data unit that becomes the retransmission unit in case of loss"? > I don't completely follow the description as to exactly how one forms a > parcel. For example, does each segment include in IPvX header? I > think I read no, but it could be a little clearer. This is a fair point, and the text can certainly be made clearer. As you surmised, there is only a single IPvX header and J ULP segments, with J ranging from 1 to 64. > I think that requiring all the segments to be exactly the same size (except > the last one) is a problem. It's definitely a problem for UDP. Even > with TCP, it becomes difficult to use exactly N bytes in a packet -- It > involves a very fragile dance between the ULP and the IP layer to > communicate the exact size of the options being used. Things like IPSec make > it impossible to use some MTU values and one needs to go a > little under (so does fragmentation; although, that doesn't apply here). > Given how difficult and fragile is it for an implementation to > completely fill up to the MTU (or "L" in the context of your document), a > reasonable design choice would be to make worse case > assumptions when they tell ULP how many bytes it has to work with. The requirement of all segments being exactly the same size except possibly the final one was borrowed from GSO/GRO and is practical for all applications that are capable of using GSO/GRO. The same size requirement means that segments can be re-ordered in flight between the source and destination (i.e., if any parcel re-packaging occurs in the path) and then put back together in a slightly different order than their original packaging. And, that is OK because ULPs need to handle a modest amount of re-ordering in the network. And, the final size being smaller is an indication that: "this is the end of (this) Parcel". It is the logical equivalent of an IP fragment with the "More Fragments" bit set to 0. So, the simple requirement of all segments being the same size except for the final one makes everything more flexible and easier to deal with. I think others more versed in GSO/GRO like Tom Herbert may even have more perspective to add to this. > If a packet is longer than 1500 bytes, some routers will not return ICMPv6 > messages. You shouldn't depend on that for performance. With AERO/OMNI and the Adaptation Layer approach, all Parcels will get through regardless of their size and regardless of what the underlying path MTU may be, i.e., even if the underlying path MTU is smaller than the minimum IPv6 path MTU. _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
