Re: [tsvwg] Regarding DTLS and UDP options

[Gorry Fairhurst <[e-mail]>]

On 17/04/2017, 23:31, Tom Herbert wrote:

Joe: How and why should these be different?
>
Tom:

> TCP options are pretty much required for operation of the TCP
> protocol, this is why they will never be ossified and why it's one of
> the few methods of protocol extensibility that is viable on the
> Internet. IP options on the other hand were never required for IP to
> operate hence they were quickly ossified. In this context, UDP options
> are more like IP options since they are not required for use with UDP.
> So there is a possibility that some vendors (e.g. a firewall) may just
> decide that to start dropping packets or throwing packets that might
> have them into a slow path similar to IP options. If something like
> this is not consistently supported in the Internet, then applications
> are unlikely to use it. I wish this wasn't reality and that the end to
> end model was actually adhered to, but when writing Internet
> applications we have to stick with what is known to work... ie. plain
> TCP/IP or UDP/IP (where support for the latter is still a little shaky
> since some network operators refer to think of UDP as nothing more
> than a DOS vector).
>
> Tom
>
I have opinions on this para, in that I think options in TCP can be 
selected by the TCP stack, they do not explicitly need to be turned on 
or off by applications. A simple example: Timestamp or MSS. If we had 
similar options for UDP, this could also be automated by the stack 
(e.g., MSS to know the maximum receive datagram size). I have ideas of a 
number of such things that could be automatable, and plan to try these 
as soon as we have a stack that supports this.

Sure, options may not be supported by specific paths - although I 
suspect that enough paths already do support to make it worth trying in 
many cases. The UDP (plus options) transport stack can then include 
mechanisms to decide how to handle loss of options, just as TCP stacks 
do this today. Applications do not need to be involved - perhaps other 
than to "enable" the sender stack to do the correct thing.

Gorry