[Int-area] Re: [tsvwg] Re: UDP options [was IP Parce ls and Advanced Jumbos (AJs)]

"Templin \(US\), Fred L" <[email protected]> Sun, 29 Sep 2024 22:03:37 +0000
Newsgroups gmane.ietf.int,gmane.ietf.ipv6,gmane.ietf.tsvwg
Message-ID <BN0P110MB14208C809529E7D562F8FB7BA375A@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM>
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]<mailto:[email protected]>> wrote:
See below

> On 28 Sep 2024, at 04:05, Brian E Carpenter <[email protected]<mailto:[email protected]>> wrote:
>
> Joe,
> On 28-Sep-24 03:13, [email protected]<mailto:[email protected]> wrote:
>>>> On Sep 27, 2024, at 7:58 AM, Templin (US), Fred L <[email protected]<mailto:[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
>
>

_______________________________________________
Int-area mailing list -- [email protected]
To unsubscribe send an email to [email protected]