[Int-area] Re: [tsvwg] Re: UDP options [was IP Parce ls and Advanced Jumbos (AJs)]
Gorry Fairhurst <[email protected]> Mon, 18 Nov 2024 17:44:47 +0000
| Newsgroups | gmane.ietf.int,gmane.ietf.ipv6,gmane.ietf.tsvwg |
|---|---|
| Organization | UNIVERSITY OF ABERDEEN |
| Message-ID | <[email protected]> |
On 18/11/2024 17:35, Templin (US), Fred L wrote: > > Tom, yes a form of PMTUD called “Parcel Path Probing” is needed but > it is based on the RFC9268 “Minimum Path MTU Hop-by-Hop” option and > not traditional RFC4821, RFC8201 or RFC8899-style large packet probing. > Great, but RFC9268 on its own likely only works across simple paths between devices. Across an Internet path, you'll need PLPMTUD or something like this to run the probing and state machine. Fortunately this can be added to TCP and is cited as a part of the QUIC specification. > Parcel Path Probing ensures that all leading hops in the path can > support parcels up to either a restricting hop or the final > destination. And, the parcel path MTU could be quite a bit larger than > conventional path MTUs – sometimes even exceeding 64KB. > I'd expect something has to probe the entire path for the size of PMTU to be used for any conventional IP packets? > > It is important to understand that the goal is to keep the parcel > buffer intact as long as possible either up to the point that a > restricting hop has to apply packetization or (preferably) all the way > to the final destination. As you say, this same discipline applies for > large singleton parcels (known as “Advanced Jumbos”) where the entire > path all the way to the final destination must support. > > Fred > Gorry P.S. This thread seems to span a lot of lists in CC, do all the lists really need to discuss this proposal? > *From:* Tom Herbert <[email protected]> > *Sent:* Monday, November 18, 2024 9:15 AM > *To:* Templin (US), Fred L <[email protected]> > *Cc:* C. M. Heard <[email protected]>; Gorry Fairhurst > <[email protected]>; Joe Touch <[email protected]>; int-area > <[email protected]>; 6man <[email protected]>; TSVWG <[email protected]> > *Subject:* Re: [tsvwg] Re: UDP options [was IP Parcels and Advanced > Jumbos (AJs)] > > On Mon, Nov 18, 2024 at 8:36 AM Templin (US), Fred L > <[email protected]> wrote: > > Thank you, Tom. With GSO, upper layer protocols prepare a buffer > that contains the concatenation of N segments (N <= 64), each of > which contains upper layer protocol information allowing it to be > processed independently of the others. This multi-segment buffer > (call it a “parcel buffer”) is then presented to progressively > lower layers until it reaches the ultimate point of preparation > for transmission over an Internetwork. At that point, existing GSO > implementations break the parcel buffer apart and transmit each of > the N segments as an individual IP packet through a process called > “packetization”. With IP parcels, however, the parcel buffer is > kept intact and a Parcel Integrity Block (PIB) is appended ahead > of the buffer. Next, a Parcel Payload Option (PPO) IP extension > header is included, then the entire parcel is transmitted over the > Internetwork without first applying packetization. > > IP parcels therefore use exactly the same code as GSO up to the > decision point of whether to apply packetization or send as a > whole IP parcel. At that point, extra code is needed to append the > PIB and PPO. Yes, this means that a parcel will look different > than an ordinary packet over the wire and that the path must have > a sufficiently large MTU, which is why the path must first be > probed to ensure all hops can support delivery. (Note, this is > only the send side consideration; an analogous sequence of events > is applied at the receive side according to GRO.) > > HI Fred, > > So we need to do PMTU discovery and ensure that IP parcels don't > exceed MTU size? Why not just report the PMTU to the application and > let them send bigger packets if PMTU is greater than minimum MTU > thereby avoiding complexities of additional on-the-wire protocol? TCP > over UDP encapsulation would already work this way, and I imagine QUIC > could be adapted to opportunistically send larger packets if that's > not already supported. Also, GRO/GSO solve the problem of application > sending or receiving greater than PMTU size "packets", so it's not > clear to me how IP parcels helps either performance in the local stack > or on the wire. Maybe I'm missing something... > > Tom > > Fred > > *From:* Tom Herbert <[email protected]> > *Sent:* Saturday, November 16, 2024 12:06 AM > *To:* Templin (US), Fred L <[email protected]> > *Cc:* C. M. Heard <[email protected]>; Gorry Fairhurst > <[email protected]>; Joe Touch <[email protected]>; int-area > <[email protected]>; 6man <[email protected]>; TSVWG <[email protected]> > *Subject:* Re: [tsvwg] Re: UDP options [was IP Parcels and > Advanced Jumbos (AJs)] > > On Fri, Nov 15, 2024, 7:22 PM Templin (US), Fred L > <[email protected]> wrote: > > Tom, > > >Let me rephrase. Does the GRO/GSO implementation need to > change because of IP parcels? > > You are more qualified to answer this question than I am. > > Fred, > > I have some understanding of how GRO/GSO works today, but no idea > what the interaction would be with IP parcels. IMO, it's a matter > of design and implementation. > > A key design point of GRO/GSO is that there is no change to > protocols and in fact they're transparent on the wire. For UDP we > can do GRO/GSO in two modes: generic model collects UDP payloads > into a single packet where the application can deduce the > individual datagrams (this is critical for QUIC performance); we > can also do TCP GRO/GSO when TCP is encapsulated in UDP like VXLAN. > > IP parcels seems to be a significant change to the protocol, so I > imagine proper support for GRO/GSO needs to be implemented. Even > before that, understanding the interaction with checksum offload > might be more pertinent. > > I'd also point out that the interaction with GRO/GSO and checksum > offload are also open questions for UDP Options, so it seems to me > that trying to define how IP parcels and UDP Options work together > is a bit premature. I think we need running code for each of them > first. > > Tom > > *From:* Tom Herbert <[email protected]> > *Sent:* Friday, November 15, 2024 10:43 AM > *To:* Templin (US), Fred L <[email protected]> > *Cc:* C. M. Heard <[email protected]>; Gorry Fairhurst > <[email protected]>; Joe Touch <[email protected]>; > int-area <[email protected]>; 6man <[email protected]>; TSVWG > <[email protected]> > *Subject:* Re: [tsvwg] Re: UDP options [was IP Parcels and > Advanced Jumbos (AJs)] > > On Fri, Nov 15, 2024, 6:30 PM Templin (US), Fred L > <[email protected]> wrote: > > Tom, > > >Is there any interaction between GRO/GSO and IP parcels then? > > An IP parcel is exactly a multi-segment GSO buffer > packaged for transmission over an Internetwork. > > Hi Fred, > > Let me rephrase. Does the GRO/GSO implementation need to > change because of IP parcels? > > Tom > > Fred > > *From:* Tom Herbert <[email protected]> > *Sent:* Friday, November 15, 2024 10:09 AM > *To:* Templin (US), Fred L <[email protected]> > *Cc:* C. M. Heard <[email protected]>; Gorry Fairhurst > <[email protected]>; Joe Touch <[email protected]>; > int-area <[email protected]>; 6man <[email protected]>; TSVWG > <[email protected]> > *Subject:* Re: [IPv6]Re: [EXTERNAL] Re: [tsvwg] Re: UDP > options [was IP Parcels and Advanced Jumbos (AJs)] > > On Fri, Nov 15, 2024, 6:01 PM Templin (US), Fred L > <[email protected]> wrote: > > Hi Mike, > > This is exactly what happens with Generic Segment > Offload (GSO) and Generic Receive Offload (GRO) in > real networks today. After a multi-segment GSO buffer > is broken into individual IP packets during > packetization, the receiver applies GRO to restore the > multi-segment buffer if possible; otherwise, it > delivers the individual IP packets to the upper layer. > Each individual IP packet is an atomic unit that will > be understood by upper layers even if it is not > restored into the original multi-segment buffer > originally prepared by GSO. This is the way GSO/GRO > work today, and IP parcels does not change that. > > Hi Fred, > > Is there any interaction between GRO/GSO and IP parcels then? > > Tom > > Fred > > *From:* C. M. Heard <[email protected]> > *Sent:* Friday, November 15, 2024 9:36 AM > *To:* Templin (US), Fred L <[email protected]> > *Cc:* Gorry Fairhurst <[email protected]>; Joe > Touch <[email protected]>; int-area > <[email protected]>; 6man <[email protected]>; TSVWG > <[email protected]> > *Subject:* [EXTERNAL] Re: [tsvwg] Re: UDP options [was > IP Parcels and Advanced Jumbos (AJs)] > > > > > EXT email: be mindful of links/attachments. > > Fred, > > I very strongly disagree with your statement that it > is not an error to "it will instead deliver each of > the individual IP packets to upper layers without > restoring the parce." > > That amounts to delivering PIECES of the UDP packet > sent by the originator to the upper layer. This would > be exactly equivalent to allowing a receiver that does > not understand the UDP FRAG option to deliver the > payload of each individual fragment to the upper > layer. The UDP options draft goes to considerable > effort to ensure that this does not happen. > > There is long-standing precedent that the boundaries > of UDP datagrams are preserved during transmission > across the Internet. Many if not all UDP-based > protocols depend on that, explicitly or implicitly. I > do not understand why this point is even considered > open for discussion. > > Mike > > On Fri, Nov 15, 2024 at 8:26 AM Templin (US), Fred L > <[email protected]> wrote: > > Hi Mike, > > Thank you for looking and commenting. A UDP/IP > parcel containing N segments that undergoes > packetization somewhere along the path will arrive > at the final destination as N individual IP > packets, each containing a Parcel Parameters UDP > option. If the destination recognizes the option, > it will restore the N segment parcel within the > kernel before delivering the entire parcel as a > single unit to upper layers. If the destination > does not recognize the option, it will instead > deliver each of the individual IP packets to upper > layers without restoring the parcel which is not > an error. Very significantly, each of the > individual IP packets can be dealt with as > standalone units once packetization has been > applied; it is just that if the receive-side does > not apply restoration (i.e., GRO) the performance > optimization will be lost at that end. So, I don’t > think there is any problem to worry about. > > Fred Templin > > *From:* C. M. Heard <[email protected]> > *Sent:* Thursday, November 14, 2024 4:55 PM > *To:* Templin (US), Fred L <[email protected]> > *Cc:* Gorry Fairhurst <[email protected]>; Joe > Touch <[email protected]>; int-area > <[email protected]>; 6man <[email protected]>; TSVWG > <[email protected]> > *Subject:* Re: [tsvwg] Re: UDP options [was IP > Parcels and Advanced Jumbos (AJs)] > > > Fred and WG participants, > > I have finally freed up some cycles to read > draft-templin-6man-parcels2-14 > <https://datatracker.ietf.org/doc/html/draft-templin-6man-parcels2-14>, > and I have found some issues with it that need to > be addressed with respect to its handling of UDP. > > The big one -- if I have correctly understood what > I have read -- is that it's possible for a single > parcel of a parcellated UDP packet to be turned > into a stand-alone UDP packet (see Section 7.1 > <https://datatracker.ietf.org/doc/html/draft-templin-6man-parcels2#name-packetization-over-non-parc>) > and delivered to an end system as such (see > Section 7.4 > <https://datatracker.ietf.org/doc/html/draft-templin-6man-parcels2#name-final-destination-restorati>). > That packet would contain a Parcel Parameters UDP > Option to tell the endpoint host that the packet > is a parcel and not a complete UDP datagram, but > the option kind is taken from the SAFE option > space (KIND = 127; see > draft-ietf-tsvwg-udp-options#section-10 > <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options#section-10>). > Legacy endpoints that do not understand UDP > options will ignore that SAFE option and will > deliver the parcel as if it were a complete UDP > datagram. That, to my mind, is completely > unacceptable. Unlike TCP, which is a byte-stream > protocol in which segment boundaries have no > meaning for the upper layer, UDP is a datagram > protocol in which message boundaries are > meaningful to the upper layer. The protocol has a > contract with the upper layer to deliver a message > as it was submitted or not at all. Delivering a > parcel in a manner that can be misinterpreted as a > complete datagram violates that contract. > > It is possible to repair this defect by making the > Parcel Parameters Option, or something with > equivalent functionality, into an UNSAFE option. > My suggestion would be to define an UNSAFE version > of the existing FRAG option (see > draft-ietf-tsvwg-udp-options#section-11.4 > <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options#section-11.4>) > -- let's call it UFRAG -- that would allow for > packet sizes greater than 65,535 bytes. The same > option could be used to send singleton advanced > jumbo packets as atomic fragments. This would > avoid any need to modify the base UDP and UDP > Options specifications. > > Additionally: during the review of > draft-ietf-tsvwg-udp-options > <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options>, > Joe Touch correctly pointed out that RFC 2675 > <https://datatracker.ietf.org/doc/html/rfc2675> (and > its predecessor RFC 2147 > <https://datatracker.ietf.org/doc/html/rfc2147>) > failed to note that it updated RFC 768 > <https://datatracker.ietf.org/doc/html/rfc768>. > Similar concerns apply to TCP. If this draft foes > forward, it should note that it updates the UDP > and TCP specifications, and it should get buy-in > from TSVWG and TCPM. > > Thanks and regards, > > Mike Heard > > On Sun, Sep 29, 2024 at 3:51 PM C. M. Heard > <[email protected]> wrote: > > Fred, > > I currently hold the editing pen for the > changes to the UDP Options draft that have > been requested prior to the shepherd report, > and my intention is to remain silent about > how, if at all, IP Parcels and Advanced Jumbos > (AJs) will support UDP Options. > > I'll provide comments on the IP Parcels and > Advanced Jumbos work at a later date, when I > have spare intellectual cycles to fully > comprehend the contents > of draft-templin-6man-parcels2. At this point > I must confess that, like Brian, I do not > understand how a receiver will locate the > options trailer in the case of an IP Payload > Length exceeding 65535. Like Joe, I think it > would be better to put the options just after > the UDP header and make a new UNSAFE option to > delimit the position where the options end and > the user data begins.. But that discussion > (and the corresponding update to the UDP > options draft) can occur when it is ripe; IMO > that is not the case at this time. > > Respectfully, > > Mike Heard > > On Sun, Sep 29, 2024 at 3:07 PM Templin (US), > Fred L > <[email protected]> > wrote: > > IP parcels and Advanced Jumbos (AJs) of > all sizes ranging from 1 to 2^32 are now > eligible > > for using UDP options. This is just one > way in which they offer a better service > than RFC2675 > > Jumbograms, but there are also many others. > > Joe, you can either note this in your > draft or just leave it be and let my draft > do an > > “updates UDP options”. > > Thank you - Fred > > *From:* Brian Carpenter > <[email protected]> > *Sent:* Saturday, September 28, 2024 2:20 AM > *To:* Gorry (erg) <[email protected]> > *Cc:* Joe Touch <[email protected]>; > Templin (US), Fred L > <[email protected]>; Tim Chown > <[email protected]>; Internet Area > <[email protected]>; IPv6 List > <[email protected]>; tsvwg IETF list > <[email protected]> > *Subject:* [EXTERNAL] Re: [tsvwg] Re: UDP > options [was IP Parcels and Advanced > Jumbos (AJs)] > > > > > EXT email: be mindful of links/attachments. > > That works for me.. > > (via tiny screen & keyboard) > Regards, > Brian Carpenter > > On Sat, 28 Sept 2024, 19:08 Gorry (erg), > <[email protected]> wrote: > > See below > > > On 28 Sep 2024, at 04:05, Brian E > Carpenter > <[email protected]> wrote: > > > > Joe, > > On 28-Sep-24 03:13, > [email protected] wrote: > >>>> On Sep 27, 2024, at 7:58 AM, Templin (US), Fred L <[email protected]> wrote: > >>> > >>>> Indeed. But if sendmsg() and recvmsg() can and do generate RFC2675 packets, it means > that any discussion of obsoleting > RFC2675 should be > >>>> off the table. > >>> > >>> No one that I know of has > suggested obsoleting RFC2675 - my > documents do not say "obsoletes" (nor > even "updates”). > >> That approach to UDP jumbo grams is > incompatible with UDP options. > >> And yes, there was a proposal to > move that RFC to historic: > >> Jones, T., G. Fairhurst, "Change > Status of RFC 2675 to Historic," > draft-jones-6man-historic-rfc2675, May > 2019. > >> We COULD have a new option with a > longer length, but that’s not in our > baseline draft. > > > > Wouldn't that be tricky, because the > options follow the whole payload as I > understand it? So a JumboUDPgram has > to be received in full, however big it > is, before the option saying that it's > a jumbo can be received and interpreted. > > > > Where the udp-options draft says: > > > >>> The technique has been proposed > for deprecation [Jo19]. > > > > I think you'd better change it to > something like: > > > > The technique is known to be in > active use in special situations, so > cannot reasonably be deprecated. > However, users of this technique > cannot simultaneously use UDP options. > > > > Brian > > > I do not think the I-D needs to say > anything about the deployment status > of jumbograms, that another topic. > > I suggest if people wish, we just say > that users of this technique can or > cannot simultaneously use UDP options. > > Gorry > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > List Info: > https://mailman3.ietf.org/mailman3/lists/[email protected]/ > -------------------------------------------------------------------- > _______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]