On Wed, Nov 20, 2024 at 10:23 AM Templin (US), Fred L <Fred.L.Templin=40boeing....@dmarc.ietf.org> wrote: > > Hi Tom, > > > -----Original Message----- > > From: Tom Herbert <tom=40herbertland....@dmarc.ietf.org> > > Sent: Wednesday, November 20, 2024 10:08 AM > > To: Templin (US), Fred L <fred.l.temp...@boeing.com> > > Cc: Gorry Fairhurst <go...@erg.abdn.ac.uk>; lloyd.w...@yahoo.co.uk; C. M. > > Heard <he...@pobox.com>; to...@strayalpha.com; int-area > > <int-area@ietf.org>; 6man <i...@ietf.org>; TSVWG <ts...@ietf.org> > > Subject: Re: [IPv6]Re: [tsvwg] Re: UDP options [was IP Parcels and Advanced > > Jumbos (AJs)] > > > > On Wed, Nov 20, 2024 at 9:51 AM Templin (US), Fred L > > <Fred.L.Templin=40boeing....@dmarc.ietf.org> wrote: > > > > > > Hi Gorry, a point of clarification is that IP parcels and AJs are not > > > necessarily only about huge payloads. > > > It is true that an IP parcel can be as large as 2**24 and an AJ can be as > > > large as 2**32, but a minimal > > > IP parcel is one with a single segment of 1-octet in length and a minimal > > > AJ is one with a NULL payload. > > > All sizes in between (ranging from very small to very large) are > > > possible, and there is no longer anything > > > special about 64KB. > > > > Fred, > > > > What is the use case for sending a single segment of 1-octet? What > > I don't have a use case, but such a parcel would be compliant with the spec. > I don't see a reason to constrain the spec to forbid such a construct. > > > would be the use case of sending segments with size less than Minimum > > MTU? > > In the LTP protocol at least, the receiver waits to receive many segments > before sending > back a series of very small (less than 100 octet) acknowledgements. When > there are lots > of segments, LTP often sends back a barrage of short acknowledgements in > ordinary IP > packets. These could instead be bundled as IP parcels.
Fred, That is an interesting use case, but I think packing multiple acks into a single packet is more of a transport layer issue than a network layer issue and is independent of using larger MTUs. I suggest that this can be solved by changing LTP to carry more information in a packet, or if changing the protocol is prohibitive then maybe a new UNSAFE UDP option would do the trick. Either way this seems like an end-to-end issue so we shouldn't have to expose this to routers (i.e. a HBH option isn't warranted). Tom > > Thank you - Fred > > > Tom > > > > > > > > Fred > > > > > > > -----Original Message----- > > > > From: Gorry Fairhurst <go...@erg.abdn.ac.uk> > > > > Sent: Wednesday, November 20, 2024 12:06 AM > > > > To: lloyd.w...@yahoo.co.uk; C. M. Heard <he...@pobox.com>; > > > > to...@strayalpha.com > > > > Cc: 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 19/11/2024 23:58, lloyd.w...@yahoo.co.uk 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 > > > > > lloyd.w...@yahoo.co.uk > > > > > > > > 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. > > > > > > > > Best wishes, > > > > > > > > Gorry > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wednesday 20 November 2024 at 05:12:00 GMT+11, > > > > > to...@strayalpha.com <to...@strayalpha.com> 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 <he...@pobox.com> 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 <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/ > > > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > > > 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
