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

[Gorry Fairhurst <[e-mail]>]

On 18/03/2019, 16:27, Tom Herbert wrote:
> 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
So I wa sthinking that the app "knows" what is "negotiated". It could be 
that the app decides it needs security or enhanced integrity check and 
therfore configures to add this at the sender and check at the receiver. 
Whether this "knowing" is hard-coded or uses an upper layer handshake 
isn't so significant to me. An upper layer handshake/protocol could also 
include some sort of fall-back.

For an apps that is itself stateless it just has to be designed to use a 
UDP Option or not. In the same way that it chooses TCP or could use SCTP 
etc.
>> Tom
>>
>>> Am I misunderstanding something?
>>>
>>> Gorry
>>>>> Mike Heard
Gorry