[Int-area] Re: [IPv6]Re: Re: UDP options [was IP P arcels and Advanced Jumbos (AJs)]

Tom, reaching back several messages you said:

>> If IP parcels is pursued in IETF, I really hope we get running code and deployment experience ASAP

There is already an implementation of an earlier draft version available at:

https://github.com/fltemplin/ip-parcels

This will need to be updated to be reflect what is in the most recent draft version, but it
at least provides a sketch of what an updated implementation would look like.

Thank you - Fred

> -----Original Message-----
> From: Tom Herbert <[email protected]>
> Sent: Wednesday, November 20, 2024 7:27 AM
> To: Gorry Fairhurst <[email protected]>
> Cc: [email protected]; [email protected]; int-area <[email protected]>; 6man <[email protected]>; TSVWG <[email protected]>
> Subject: [EXTERNAL] [tsvwg] Re: [IPv6]Re: Re: UDP options [was IP Parcels and Advanced Jumbos (AJs)]
> 
> EXT email: be mindful of links/attachments.
> 
> 
> 
> On Wed, Nov 20, 2024 at 12:07 AM Gorry Fairhurst <[email protected]> wrote:
> >
> > On 19/11/2024 23:58, [email protected] wrote:
> > > These proposed changes to UDP are thoughtprovoking.
> > >
> > > When UDP-Lite (RFC3828) was proposed, it was eventually shunted to its own IP protocol number, rather than risk messing up existing
> UDP implementations and semantics for even a very minor change. I gather that move to a different port was done very late in the process.
> > >
> > > The changes proposes in UDP options and in parcelling seem much much larger. Surely they should be treated as UDP-Lite was, and as
> UDP-alike but not as UDP, and given their own IP protocol number?
> > >
> > > thanks
> > >
> > >
> > > Lloyd Wood
> > > [email protected]
> >
> > I think Lloyd this set of therads is conflating two things:
> >
> > UDP Options has been developed over many years as a specification, and
> > (at least in tsvwg) is thought complete - we have evidence the method
> > works across existing networks and the WG has analysed whether we can
> > extend it safely. It's been through WGLC and should hopefully complete
> > AD review soon. It's an addition to UDP.
> >
> > IP parcels has been presented at the IETF, but as far as I know, hasn't
> > yet been adopted. I don't expect this to be ready for quite some time,
> > especially since it anticipates new devices on-path that have been
> > optimised for very large packets.  In most parts of the network, we are
> > still struggling to support near 1500B. If packets are > 64 KB as
> > imagined, there will be many more conbsiderations, not least how
> > fragmentation is handled within the network and the relationship to loss
> > recovery, congestion control, etc. If the IETF decides this is an
> > important use-case, I see this as further out, with many things to decide.
> >
> 
> Gorry,
> 
> "evidence" != "proof"-- I think this is one thing that UDP Options and
> IP Parcels have in common. Both of these are heavy on the protocol
> theory and anecdotes, but neither have really delved into the
> particular what's needed for viable implementation and the realities
> of deploying a new protocol at scale. For example, even interaction
> with something as simple as checksum offload, which is well
> established and pervasive across host implementations, remains an open
> issue.
> 
> If IP parcels is pursued in IETF, I really hope we get running code
> and deployment experience ASAP-- that's especially important since the
> goal of the protocol seems to be performance improvement and the only
> way we can prove performance improvement is by running the code and
> getting the numbers. In this regard, I think QUIC might be the poster
> child for how a new protocol should be developed-- even before the RFC
> was published there was open source implementation and significant
> deployment.
> 
> Tom
> 
> > Best wishes,
> >
> > Gorry
> >
> >
> > >
> > >
> > >
> > >
> > >
> > > On Wednesday 20 November 2024 at 05:12:00 GMT+11, [email protected] <[email protected]> wrote:
> > >
> > >
> > >
> > >
> > >
> > > Hi, all,
> > >
> > > I have not investigated this issue. Any new UDP option proposal would need to be evaluated in detail AND would need to follow the design
> requirements in the UDP options doc.
> > >
> > > Further, I would urge any option that is per-IP packet to be an IP option; UDP options are intended for user endpoints, not the (existing)
> protocol subsystem per se. I don’t yet understand whether the proposed parcel parameters should be an IP option or UDP option, but UDP
> options are NOT intended as a place you can put info that you don’t want to or can’t put in IP options per se. IP options are per IP packet; UDP
> options are per UDP message. We’d need to understand why parcels are fiddling with UDP option space - which may already be used by the
> UDP endpoints.
> > >
> > > Joe
> > >
> > >
> > > —
> > > Dr. Joe Touch, temporal epistemologist
> > > www.strayalpha.com
> > >
> > >
> > >> On Nov 14, 2024, at 4:54 PM, C. M. Heard <[email protected]> wrote:
> > >>
> > >> Fred and WG participants,
> > >>
> > >> I have finally freed up some cycles to read 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) and delivered to an end system as such (see Section 7.4). 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). 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) --
> 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, Joe Touch correctly pointed out that RFC 2765 (and its predecessor RFC
> 2147) failed to note that it updated RFC 768. 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]