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<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
