> Please review the UDP options doc. There is no “end *following* UDP options”; > the options consume the entire surplus space.
Yes, so IP parcels and AJs will update the base UDP options spec. For IP parcels and AJs, a 2-octet trailer can then be added beyond the end of the UDP options space. Thank you - Fred From: to...@strayalpha.com <to...@strayalpha.com> Sent: Monday, September 30, 2024 8:00 AM To: Templin (US), Fred L <fred.l.temp...@boeing.com> Cc: C. M. Heard <he...@pobox.com>; Brian Carpenter <brian.e.carpen...@gmail.com>; Gorry (erg) <go...@erg.abdn.ac.uk>; 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: Re: [EXTERNAL] [tsvwg] Re: UDP options [was IP Parcels and Advanced Jumbos (AJs)] EXT email: be mindful of links/attachments. Hi, Fred, Please review the UDP options doc. There is no “end *following* UDP options”; the options consume the entire surplus space. I don’t know yet how or whether parcels with larger than 64K can work with UDP options, but at this time, it does seem premature to even bother with such things (even for parcels) until we start to support packets upwards of what IP / UDP already supports. Joe — Dr. Joe Touch, temporal epistemologist www.strayalpha.com<http://www.strayalpha.com> On Sep 30, 2024, at 7:47 AM, Templin (US), Fred L <fred.l.temp...@boeing.com<mailto:fred.l.temp...@boeing.com>> wrote: Thank you, Mike. The inclusion of UDP options in parcels/AJs is really straightforward and I think could be done as an update to the base UDP options spec at some later time if you don’t think the time is ripe to tackle it now. The idea is that parcels/AJs that are no larger than 64KB will use UDP options exactly the same way as for an ordinary UDP packet, but the source will include a 2-octet “UDP Option Length” field in larger parcels/AJs as a trailer at the very end following the UDP options themselves. The destination can then determine the starting offset and length of the UDP options by reading this length field. Did I mention that parcels/AJs can be smaller than 64KB – often even much smaller? The same is not true for RFC2675 jumbograms which are always larger than 64KB and always set UDP length to 0. Thank you - Fred From: C. M. Heard <he...@pobox.com<mailto:he...@pobox.com>> Sent: Sunday, September 29, 2024 3:52 PM To: Templin (US), Fred L <fred.l.temp...@boeing.com<mailto:fred.l.temp...@boeing.com>> Cc: Brian Carpenter <brian.e.carpen...@gmail.com<mailto:brian.e.carpen...@gmail.com>>; Gorry (erg) <go...@erg.abdn.ac.uk<mailto:go...@erg.abdn.ac.uk>>; Joe Touch <to...@strayalpha.com<mailto:to...@strayalpha.com>>; Tim Chown <tim.ch...@jisc.ac.uk<mailto:tim.ch...@jisc.ac.uk>>; Internet Area <Int-area@ietf.org<mailto:Int-area@ietf.org>>; IPv6 List <i...@ietf.org<mailto:i...@ietf.org>>; tsvwg IETF list <ts...@ietf.org<mailto:ts...@ietf.org>> Subject: Re: [tsvwg] Re: UDP options [was IP Parcels and Advanced Jumbos (AJs)] 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<mailto: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<mailto:brian.e.carpen...@gmail.com>> Sent: Saturday, September 28, 2024 2:20 AM To: Gorry (erg) <go...@erg.abdn.ac.uk<mailto:go...@erg.abdn.ac.uk>> Cc: Joe Touch <to...@strayalpha.com<mailto:to...@strayalpha.com>>; Templin (US), Fred L <fred.l.temp...@boeing.com<mailto:fred.l.temp...@boeing.com>>; Tim Chown <tim.ch...@jisc.ac.uk<mailto:tim.ch...@jisc.ac.uk>>; Internet Area <Int-area@ietf.org<mailto:Int-area@ietf.org>>; IPv6 List <i...@ietf.org<mailto:i...@ietf.org>>; tsvwg IETF list <ts...@ietf.org<mailto: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<mailto:go...@erg.abdn.ac.uk>> wrote: See below > On 28 Sep 2024, at 04:05, Brian E Carpenter > <brian.e.carpen...@gmail.com<mailto:brian.e.carpen...@gmail.com>> wrote: > > Joe, > On 28-Sep-24 03:13, to...@strayalpha.com<mailto:to...@strayalpha.com> wrote: >>>> On Sep 27, 2024, at 7:58 AM, Templin (US), Fred L >>>> <Fred.L.Templin=40boeing....@dmarc.ietf.org<mailto: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 > >
_______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
