Re: [tsvwg] Alternative version of the UDP FRAG option

[Tom Herbert <[e-mail]>]

On Mon, Mar 18, 2019 at 8:40 AM Gorry Fairhurst <[e-mail]> wrote:
>
> I think I missed something between these emails....
>
> On 18/03/2019, 15:13, Tom Herbert wrote:
> > On Mon, Mar 18, 2019 at 7:43 AM C. M. Heard<[e-mail]>  wrote:
> >> On Sat, Mar 16, 2019 at 9:06 AM Tom Herbert wrote:
> >>> Thinking about this, it occurs to me be that the LITE option isn't
> >>> needed. The assumption in the UDP options draft is that a receiver
> >>> needs the UDP payload to immediately follow the UDP header, but the
> >>> UDP payload can be anywhere in the surplus area as long as it's
> >>> aligned to four bytes. A receiver will know how to handle it and
> >>> deliver the UDP data to the application (e.g. by maintaining a pointer
> >>> to the data).
> >>>
> >>> So that allows a format like:
> >>>
> >>> UDP header (Length=8) | Surplus area header | Options | Payload
> >>>
> >>> The surplus area header contains the header length and a checksum
> >>> covering the surplus space (four bytes altogether). The three headers
> >>> can thought of as an extended UDP header, so the format becomes:
> >>>
> >>> Extended UDP header | Payload
> >>>
> >>> Which looks a whole lot like any other protocol format with a variable
> >>> length header such as TCP or IPv4.
> >> A major downside to this approach is that is does not let you add
> >> "optional to process" options such as MSS, Echo Request, and Echo
> >> Response to UDP datagrams that are intended to be processed normally
> >> by legacy receivers that do not understand UDP options or the extended
> >> UDP header format. You can do that with the option trailer as
> >> currently proposed.
> Right, so this really re-designs UDP as a sublayer to another transport.
> To me, this looks very like an encaps like DCCP-in-UDP or GRE-in-UDP,
> etc. So this isn't an "option" it's an encapsulation.
> > Mike,
> >
> > The converse is also true. We can't put options in a trailer that
> > *must* be processed by the receiver (fragmentation, compression,
> > security, etc.).
> >
> > Tom
> Why this? I thought that if you make a request to negotiate to use say
> enhanced integrity checking or some security option, then you can
> require the option to be present at the receiver?

Gorry,

How does negotiation work with a transport protocol that is stateless?
Negotiation implies state is maintained between two endpoints.

Tom

> Am I misunderstanding something?
>
> Gorry
> >> Mike Heard
>