[tsvwg] Re: [EXTERNAL] Re: Re: UDP options [was IP Parcels and Advanced Jumbos (AJs)]

["C. M. Heard" <[e-mail]>]

Fred,

Please provide a reference with evidence for that statement *as it applies
to UDP*.

Mike


On Fri, Nov 15, 2024 at 10:00 AM Templin (US), Fred L <
[e-mail]> 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.
>
>
>
> Fred
>
>
>
> *From:* C. M. Heard <[e-mail]>
> *Sent:* Friday, November 15, 2024 9:36 AM
> *To:* Templin (US), Fred L <[e-mail]>
> *Cc:* Gorry Fairhurst <[e-mail]>; Joe Touch <
> [e-mail]>; int-area <[e-mail]>; 6man <[e-mail]>;
> TSVWG <[e-mail]>
> *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 <
> [e-mail]> 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 <[e-mail]>
> *Sent:* Thursday, November 14, 2024 4:55 PM
> *To:* Templin (US), Fred L <[e-mail]>
> *Cc:* Gorry Fairhurst <[e-mail]>; Joe Touch <
> [e-mail]>; int-area <[e-mail]>; 6man <[e-mail]>;
> TSVWG <[e-mail]>
> *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 <[e-mail]> 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=
> [e-mail]> 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 <[e-mail]>
> *Sent:* Saturday, September 28, 2024 2:20 AM
> *To:* Gorry (erg) <[e-mail]>
> *Cc:* Joe Touch <[e-mail]>; Templin (US), Fred L <
> [e-mail]>; Tim Chown <[e-mail]>; Internet
> Area <[e-mail]>; IPv6 List <[e-mail]>; tsvwg IETF list <
> [e-mail]>
> *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), <[e-mail]> wrote:
>
> See below
>
> > On 28 Sep 2024, at 04:05, Brian E Carpenter <[e-mail]>
> wrote:
> >
> > Joe,
> > On 28-Sep-24 03:13, [e-mail] wrote:
> >>>> On Sep 27, 2024, at 7:58 AM, Templin (US), Fred L <Fred.L.Templin=
> [e-mail]> 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
> >
> >
>
>