Tom, the LTP protocol presents its segment acknowledgements in the form of segments themselves such that each one is sent out as a separate conventional IP packet - that is just the way the protocol works. But, to your point, the IP parcels spec says that the IP parcel segment size must be 256 octets or larger so my assertion that truly tiny segments could be packaged in a multi-segment parcel was incorrect - unless we want to change the parcels spec to accept a non-final segment size less than 256 octets.
Fred > -----Original Message----- > From: Tom Herbert <tom=40herbertland....@dmarc.ietf.org> > Sent: Thursday, November 21, 2024 7:39 AM > To: Templin (US), Fred L <Fred.L.Templin=40boeing....@dmarc.ietf.org> > Cc: Gorry Fairhurst <go...@erg.abdn.ac.uk>; lloyd.w...@yahoo.co.uk; > to...@strayalpha.com; int-area <int-area@ietf.org>; 6man > <i...@ietf.org>; TSVWG <ts...@ietf.org> > Subject: Re: [IPv6]Re: Re: UDP options [was IP Parcels and Advanced Jumbos > (AJs)] > > 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
