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

[Gorry Fairhurst <[e-mail]>]

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.

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.

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.

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.
> Tom
>
>> Joe
>>
>>
Gorry