[tsvwg] Re: UDP options [was IP Parcels and Advanced Jumbos (AJs)]

[Brian Carpenter <[e-mail]>]

That works for me..

(via tiny screen & keyboard)
Regards,
        Brian Carpenter

On Sat, 28 Sept 2024, 19:08 Gorry (erg), <[e-mail]> wrote:

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