Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

[Gorry Fairhurst <[e-mail]>]

On 18/07/2019, 19:38, Tom Herbert wrote:
> On Thu, Jul 18, 2019 at 11:32 AM Gorry Fairhurst<[e-mail]>  wrote:
>> On 18/07/2019, 19:18, Tom Herbert wrote:
>>> On Thu, Jul 18, 2019 at 10:59 AM Gorry Fairhurst<[e-mail]>   wrote:
>>>> On 18/07/2019, 18:25, Tom Herbert wrote:
>>>>> On Thu, Jul 18, 2019 at 9:56 AM Joe Touch<[e-mail]>    wrote:
>>>>>>
>>>>>>
>>>>>> On 2019-07-18 08:35, Tom Herbert wrote:
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> A single bit in the option type to indicate that the option can be
>>>>>> skipped if unrecognized should be sufficient.
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>>
>>>>>>
>>>>>> That bit has two meanings:
>>>>>>
>>>>>> - for legacy receivers, it's simply ignored for legacy data
>>>>>>
>>>>>> - for option-aware, if the flag is set, what does it mean?
>>>>>>      - it should never mean drop the legacy data, otherwise an options-aware endpoint can't decide to act as legacy
>>>>>>      - it could mean drop non-legacy data
>>>>>>
>>>>>> Right now, the onus is on the receiver to decide what to do with the data.. The info is passed to the user - NOT decided by UDP.
>>>>>>
>>>>>> I.e., cuurrently:
>>>>>>
>>>>>> - unknown options are ignored by both legacy and option-aware endpoints
>>>>>> - UDP processing skips over all such options
>>>>>> - users can decide/negotiate what to do with those options on a per endpoint basis
>>>>>>
>>>>>> Note: the first time you send something, if you want a response to help you know what the endpoint will do, you need to set "ignore" anyway, which is what the default does. Otherwise you won't get a response and won't know why (the packet could have been dropped).
>>>>>>
>>>>>> So this only makes sense for negotiated soft-state anyway, at which point the user can either configure the endpoint UDP socket to drop if unknown or accept.
>>>>>>
>>>>>> Why would we NOT give the user this choice?
>>>>>>
>>>>> Joe,
>>>>>
>>>>> Consider that someone invents the compression option a year from now.
>>>>> The option cannot be ignored by a receiver since delivering compressed
>>>>> data to the application would be jibberish. So someone starts using
>>>>> compression and performs a "soft-state" negotiation with a timeout of
>>>>> 30 seconds in the example algorithm you previously described for
>>>>> soft-state negotiation. So the sender is sending compression option to
>>>>> some receiver. But, at some point, say 10 seconds into a timeout
>>>>> period, the receiving host changes to a different configuration that
>>>>> doesn't support the compression option-- maybe the host address is
>>>>> virtual IP and packets are now routed to a different backend, or maybe
>>>>> someone reboots the receiving hosts with a new configuration.
>>>>> The
>>>>> sender doesn't know the receiver has changed and continues sending the
>>>>> compression option. The new receiver sees the options but doesn't
>>>>> recognize it.
>>>>> If the receiver ignores the option and delivers the data
>>>>> to the application then that's data corruption. That's not robust.
>>>> That's where I disagree. I think anything that is not a native UDP
>>>> packet MUST be carried in the options space. That's where I would
>>>> suggest we put the compressed payload. if that means the main payload
>>>> area isnothing", then that would be OK for me.
>>>>
>>> That's already assumed. If there are any options that can't be ignored
>>> then the UDP Length = 8 format must be used. If processing options
>>> fails then the packet can be dropped.
>>>
>>>> When the remote endpoint fails to process the compressed payload (or
>>>> myseriously the option si stripped/ignored - how, but don't worry), then
>>>> the app doesn't respond. It times out and does something.
>>>>
>>> Remote endpoint or remote application? We can't give an application
>>> the compressed payload.
>>>
>> Remote endpoint.
>>>> Personally, unless there was a strong desire to be unidirectional (then
>>>> you have to live with that), I'd send an option to the other end to
>>>> solicit a little feedback - or do the same at the app layer.
>>>>
>>> You can do that, but bear in mind that UDP is a stateless protocol.
>>> The feedback you get from one probe exchange might be completely
>>> invalid on the very next packet sent. Any information gleaned about a
>>> peer can only be considered advisory.
>> yes. If you build on UDP you need to provide machinery.
>>>> Gorry
>>>>> The "drop packet on unknown option" is the conventional and cheap way
>>>>> to avoid situations like this and make stateless options robust.
>>>> Not sure how that now helps?
>>>>
>>>> The receiver already ignores unknown options.
>>> I believe that's the problem. There some options that cannot be
>>> ignored and still maintain correctness. This is already a known issue
>>> with other protocols.
>> OK, let's check. The receiver gets a UDP datagram and...
>>
>> (1) Receiver understands options and it understands this specific option
>> - it processes the option - app gets the data.
> Yes, presuming other options were acceptable.
>
>> (2) Receiver understands options and not this specific option - it does
>> not processes the option - no data to the app.
> Yes, that is the correct behavoir. The question is how does the
> protocol provide for this. Right now the draft says "Receivers MUST
> silently ignore unknown options.". That won't work. Either all unknown
> options cause packet to be dropped, or receiver can can determine
> whether the packet should be be dropped based on the bit.
OK, so do you want the app to be able to process several options, but 
make options processing
dependent on other options.

Gorry
>> (3) Receiver does not understand options - it does not processes the
>> option - no data to the app.
> No data app, but app does receive a zero length message. That corner
> case is already noted.
>
>> Gorry
>>> Tom
>>>
>>>>> Tom
>>>>>
>>>>>> Joe
>>>>>>
>>>>>>
>>>> Gorry
>>>>