Should the specifications hard-refer to UDP?

[John Ericson <[e-mail]>]

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