On Fri, Nov 15, 2024, 7:22 PM Templin (US), Fred L <Fred.L.Templin= 40boeing....@dmarc.ietf.org> 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 <tom=40herbertland....@dmarc.ietf.org> > *Sent:* Friday, November 15, 2024 10:43 AM > *To:* Templin (US), Fred L <fred.l.temp...@boeing.com> > *Cc:* C. M. Heard <he...@pobox.com>; Gorry Fairhurst <go...@erg.abdn.ac.uk>; > Joe Touch <to...@strayalpha.com>; int-area <int-area@ietf.org>; 6man < > i...@ietf.org>; TSVWG <ts...@ietf.org> > *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 <Fred.L.Templin= > 40boeing....@dmarc.ietf.org> 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 <tom=40herbertland....@dmarc.ietf.org> > *Sent:* Friday, November 15, 2024 10:09 AM > *To:* Templin (US), Fred L <fred.l.temp...@boeing.com> > *Cc:* C. M. Heard <he...@pobox.com>; Gorry Fairhurst <go...@erg.abdn.ac.uk>; > Joe Touch <to...@strayalpha.com>; int-area <int-area@ietf.org>; 6man < > i...@ietf.org>; TSVWG <ts...@ietf.org> > *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 <Fred.L.Templin= > 40boeing....@dmarc.ietf.org> 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 <he...@pobox.com> > *Sent:* Friday, November 15, 2024 9:36 AM > *To:* Templin (US), Fred L <fred.l.temp...@boeing.com> > *Cc:* Gorry Fairhurst <go...@erg.abdn.ac.uk>; Joe Touch < > to...@strayalpha.com>; int-area <int-area@ietf.org>; 6man <i...@ietf.org>; > TSVWG <ts...@ietf.org> > *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 < > fred.l.temp...@boeing.com> 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 <he...@pobox.com> > *Sent:* Thursday, November 14, 2024 4:55 PM > *To:* Templin (US), Fred L <fred.l.temp...@boeing.com> > *Cc:* Gorry Fairhurst <go...@erg.abdn.ac.uk>; Joe Touch < > to...@strayalpha.com>; int-area <int-area@ietf.org>; 6man <i...@ietf.org>; > TSVWG <ts...@ietf.org> > *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 <he...@pobox.com> 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 <Fred.L.Templin= > 40boeing....@dmarc.ietf.org> 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 <brian.e.carpen...@gmail.com> > *Sent:* Saturday, September 28, 2024 2:20 AM > *To:* Gorry (erg) <go...@erg.abdn.ac.uk> > *Cc:* Joe Touch <to...@strayalpha.com>; Templin (US), Fred L < > fred.l.temp...@boeing.com>; Tim Chown <tim.ch...@jisc.ac.uk>; Internet > Area <Int-area@ietf.org>; IPv6 List <i...@ietf.org>; tsvwg IETF list < > ts...@ietf.org> > *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), <go...@erg.abdn.ac.uk> wrote: > > See below > > > On 28 Sep 2024, at 04:05, Brian E Carpenter <brian.e.carpen...@gmail.com> > wrote: > > > > Joe, > > On 28-Sep-24 03:13, to...@strayalpha.com wrote: > >>>> On Sep 27, 2024, at 7:58 AM, Templin (US), Fred L <Fred.L.Templin= > 40boeing....@dmarc.ietf.org> 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 > i...@ietf.org > List Info: https://mailman3.ietf.org/mailman3/lists/i...@ietf.org/ > -------------------------------------------------------------------- > >
_______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
