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

[Tom Herbert <[e-mail]>]

On Mon, Mar 18, 2019 at 8:58 AM Tom Herbert <[e-mail]> wrote:
>
> 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.
>
Also, if there is a negotiation then there communicating endpoint is
known to not be a legacy receiver so the extended header can be used.
Then if the packet is received by some other legacy node (e.g. because
of VIP, address corruption, peer rebooted and state is lost) the
packet is "dropped" (a zero length UDP datagram is received by the
peer).

Tom

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