Re: Should the specifications hard-refer to UDP?

[Ian Swett <[e-mail]>]

I don't believe anyone has implemented QUIC over anything besides UDP,
which makes me think it's too early to specify it.

I'm also pretty risk averse and would agree with most of Martin's points.
I'd support editorial changes that make the text a bit less tightly coupled
to UDP, and identification of design changes which could be put into
potential QUICv2 work, but I doubt I'd support any design changes specific
to this at this stage.

Willy, I think it'd be very cool to see this run over UNIX dgram sockets.

On Tue, Aug 18, 2020 at 6:20 AM Lucas Pardue <[e-mail]>
wrote:

> (Chair hat off)
>
> +1 to Martin's points.
>
> I think there is a risk that trying to piecemeal abstract language into
> the core transport document will reduce the document comprehension, and tie
> up time with reviewers etc. I'm of the opinion that this challenge, at this
> late stage in the document lifecycle, is too large..
>
> However, there is a concrete use case in the IETF for exchanging QUIC
> packets not in plain old UDP datagrams - MASQUE [1]. Perhaps that could be
> a suitable venue for some of the things you have in mind?
>
> Cheers
> Lucas
>
> [1] - https://datatracker.ietf.org/wg/masque/about/
>
> On Tue, Aug 18, 2020 at 5:37 AM 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
>> >
>> >
>>
>>