Re: Should the specifications hard-refer to UDP?

[John Ericson <[e-mail]>]

Well, this is about the response I've expected. I'm fully aware I'm finally showing up for this sort of thing at an inconvenient time. Nevertheless, I thought there was just enough positivity, especially in the initial response from Martin, and latest one from Spencer, so I started to give it ago in https://github.com/quicwg/base-drafts/pull/4043.

In it's current state, this WIP PR is just the sort of "piecemeal" introduction of abstract language that Lucas, rightly, warns against. Nevertheless, I think that I could continue that PR, actually covering the interactions of the spec comprehensively, without being substantially more invasive, so I think the WIP PR does have some virtue in indicating the sort of changes I am interested in.

If this attempt looks promising, I'll continue with it, but if this does not escape the pitfalls you all warned about, I'll abandon it and trouble the WG no further.

John

On Wed, Aug 19, 2020, at 10:33 AM, Spencer Dawkins at IETF wrote:
> I've read this thread, so I'm current, but wanted to chime in on one of the encouraging things Martin said .... 
> 
> On Mon, Aug 17, 2020 at 11:37 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. 
> 
> I think that's a great place to start. ISTM that we're used to thinking of UDP as "IP plus ports for path sharing", but that's probably not nearly enough to base implementation over another protocol on. Documenting that dependency is probably useful, thought-provoking, and (best of all) not something that will slow QUICv1 down at all. 
> 
> As pointed out, running directly over IP and running through a sockets interface are two obvious possibilities (and I didn't see "running directly over IP" coming), and they aren't particularly similar, so a document that describes what QUIC expects from an underlying protocol would be helpful. 
> 
> John, thank you for starting this conversation. 
> 
> Best,
> 
> Spencer
>  
>> 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
>> > 
>> >
>>