Re: Should the specifications hard-refer to UDP?

[Mark Nottingham <[e-mail]>]

Just to add to what Martin has said - 

This reminds me of the HTTP/1.1 specification very much. A fair amount of effort has been put in over the years to preserve some independence from TCP, so that it can be layered on top of other protocols. Apparently that is sometimes done, but I don't think at Internet scale (i.e., between parties who don't have some  previous agreement).

So it *is* of some value to have this sort of abstraction in protocol specification. However, it comes at a price -- both in interoperability (as Martin mentions), and in clarity. For HTTP, we're still working through the consequences of this early documentation choice (e.g., with bugs like 'what does a TCP half-closed connection mean?').

Also, as Martin mentions all abstractions are leaky; we like to think of them as barriers that we can build on top of without knowledge of anything beneath, but in practice they're rarely so absolute. If we were to factor UDP out, we'd have to replace it with an abstraction; if that abstraction wasn't 'exactly what UDP offers', the delta would essentially be a set of assumptions begging to be violated.

Cheers,


> On 18 Aug 2020, at 2:36 pm, Martin Thomson <[e-mail]> wrote:
> 
> Hi John,
> 
> Thanks for your email.  This is something I recall discussing, but it might not have made it onto a record (it might have been in an in-person meeting), so it's good that someone raises it.
> 
> There are reasons that we might not want too much abstraction here.  To take the most obvious example, if you were to seek an IP protocol number for QUIC, there are a few things that need attention.  You lose the UDP port number, so references to those in the protocol are invalid.  We encode those in just a few places, so maybe you can just pretend that any value is OK, or set them to zero always.  Maybe you tweak the MTU to account for the lower overhead.  But we mostly just talk about "address" in the abstract, and we already deal with MTU variation between IPv4 and IPv6.  After that, there isn't much more to say.  So then you have a protocol that interoperates.
> 
> Whatever you call this new thing, it won't interoperate with QUIC.  
> 
> This also carries a risk, because this "porting" exercise is different based on the target.  If you were to overlay the abstract protocol on a different medium entirely, you need to consider how other IP services are used by QUIC.  A protocol defined directly atop IP still benefits from ICMP and ECN and the other facilities provided by IP, but if you wanted to layer this in some other way those facilities might not be available.  Maybe you don't miss those facilities, and it is almost certainly not work of the same magnitude as a full protocol design, but it requires careful analysis.
> 
> Now, I'm not saying that there isn't value in understanding the exact shape of the protocol's dependency on UDP.  That's a great exercise.  Personally, I would want to see that this didn't adversely affect the ability of a new reader to comprehend what is already a complicated mess of a protocol (300+ pages of old-fashioned text).
> 
> Getting a split right is challenging.  It's more than just understanding the structure of specification text.  You have to discover all the places that the abstraction leaks through.  That could be a useful contribution, but we haven't prioritized it in this working group.  That doesn't mean it's not possible, only that changes on that magnitude would need to be careful.  That's a non-trivial exercise in a document on this scale.
> 
> The split for TLS was originally much cleaner, but reality set in and I'm not sure that we'd be able to unwind the resulting tangle (though we have an issue on file).  That interface is probably more involved than the interface to UDP though; maybe a clean abstraction is more achievable in this case.
> 
> I don't want to discourage you from trying if you are so inclined, but I do want to set expectations appropriately.  We regard this documentation to be almost done, so our tolerance for risk or delays is pretty low.  All I can promise is that we'll give any contributions a fair assessment.
> 
> Cheers,
> Just one of the editors
> 
> On Tue, Aug 18, 2020, at 13:47, John Ericson wrote:
>> To be clear, I have no issue with the pragmatics that QUIC will be 
>> layered atop UDP in practice. I am *not*, for example, trying to dredge 
>> up some years-old discussion about whether QUIC should be assigned an 
>> IP protocol number!
>> 
>> What I am questioning is the editorial/rhetorical choice of whether the 
>> specifications should refer to UDP in particular as the underlying 
>> protocol, or abstractly speak of an underlying protocol that merely 
>> must meet certain criteria, such as preserving message boundaries and 
>> (at least ephemerally) addressing endpoints.
>> 
>> Here are the benefits I think of doing so:
>> 
>> * By speaking about the underlying protocol in abstract terms, the 
>> specification can narrow in on just the qualities of UDP pertinent to 
>> the aspect of QUIC being specified, bringing clarity to the spec.
>> 
>> * Implementations that do use other underlying transports can still 
>> provide a fully-conformant QUIC implementation, rather than a protocol 
>> that is merely QUIC "in spirit". I am thinking of research or 
>> experimental implementations that are coupled with real-world 
>> applications for evaluation, and also of educational projects---perhaps 
>> ones that do so merely to teach students about protocol layering!
>> 
>> * If the underlying protocol is swapped in educational projects, 
>> students would retain the ability to follow the RFC to the letter while 
>> doing their work, rather than having to carefully take creative 
>> license. [I might remark that it's great that the layering **within* 
>> *QUIC is already so wonderful, and that ought to yield educational 
>> dividends.]
>> 
>> * Implementations that rely on the OS's or other external 
>> implementation of UDP (which I'd guess is at least a plurality of them 
>> weighted by usage) are already abstracting over exact details of the 
>> underlying transport mechanism. Even as abstracting over the underlying 
>> transport bring the specification further from how QUIC is **used* *in 
>> practice, one could argue it brings it closer to how it is 
>> **implemented* *in practice.
>> 
>> If there is interest in this, I would be happy to take to the time to 
>> author pull requests replacing references to UDP and port numbers with 
>> more abstract language.
>> 
>> Finally, my sincerest apologies if this has been discussed before. It 
>> certainly seems like the sort of thing that would have been, but I 
>> couldn't find a prior discussion searching the GitHub issue tracker and 
>> mailing list. (The closest I saw was [1], but that was focused on 
>> avoiding the use of 5-tuple altogether, rather than having QUIC 
>> continue to rely on the underlying protocol's addressing/disambiguation 
>> and merely avoid requiring that it be 5-tuple in particular.)
>> 
>> Thanks for your consideration,
>> 
>> John
>> 
>> [1]: https://mailarchive.ietf.org/arch/msg/quic/dPyWlsrhQGyAUae4_Ht5wYbX_vk
>> 
>> 
> 

--
Mark Nottingham   https://www.mnot.net/