Subject: [quicwg/base-drafts] Generalizing QUIC to allow underlying tranports other than UDP (#4061)

From: John Ericson <[email-masked]>
Date: Thu, 27 Aug 2020 20:39:23 -0700

In https://mailarchive.ietf.org/arch/msg/quic/fWbftfhTopjo6O2YjIZZwRQ92GM/ I questioned whether QUIC should be standardized requiring the underlying transport to be UDP.

The main thrust of my argument was that even assuming virtually QUIC usage in practice would be over IP, we might get a nicer RFC text by being somewhat open-ended and instead being forced to spell out the relevant properties of the underlying transport.

The response was mostly skeptical, but with just allowing that it might work out that I started an attempt in https://github.com/quicwg/base-drafts/pull/4043 

Since then, @MikeBishop brought up that other transports might actually be useful in practice, like:
 -  Message-based Websockets across an HTTP proxy
 -  Local datagram sockets for IPC

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4061

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 28 Aug 2020 18:05:40 -0700

Thank you for the intellectual exercise, @Ericson2314. Having seen the accompanying #4043, I'm convinced now that this is not a direction we should pursue, for at least two reasons:
- All implementers of QUIC today are doing this for UDP. Reading the text with the generalization makes it less concrete and, as @DavidSchinazi notes, less readable for the most common usage case that we are targeting with QUICv1.
- It is not clear to me what the driving use-case of such a generalization is, and therefore who benefits from this generalization.
- Without an implementation of it on a different underlying protocol, I'm wary that this would catch all the assumptions we've made.

When there is a need, it's easy enough to do a document that maps QUIC to a different underlying transport. Until then, this generalization seems unnecessary.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4061#issuecomment-683209140

---

From: John Ericson <[email-masked]>
Date: Fri, 28 Aug 2020 19:45:56 -0700

I am a bit confused by the association with concreteness with legibility. To me, this sounds like saying "I prefer to read assembly than C because it's more concrete w.r.t. the machine code". A higher-level description to me better conveys concepts like purpose behind a mechnaism, which cannot in-general be recovered easily from the low-level description, and furthermore no low-level details are actually being removed (It's like C with an appending containing the disassembly, to continue my earlier analogy).

I do understand that a standard can be revised, and so only talking about UDP now doesn't prevent talking about other underlying transports later once they are tried out. But just that there is a risk of specifying the details of other transports without experience, there is the risk of ending up with a "non-portable" protocol that is much more tightly bound to UDP than intended. That can also be a difficult situation to recover from.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4061#issuecomment-683224746

---

From: David Schinazi <[email-masked]>
Date: Fri, 28 Aug 2020 21:21:53 -0700

Could you elaborate on how we might end tying QUIC too closely to UDP? I'm not sure I see how renaming things would help.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4061#issuecomment-683234067

---

From: Martin Thomson <[email-masked]>
Date: Mon, 31 Aug 2020 01:10:09 -0700

As @DavidSchinazi is likely one of the first people to want an abstraction, his opposition is worth paying attention to.

For me, this discussion highlights how abstractions aren't free.  They aren't free in terms of the time that I need to spend in order to review changes, then maintain them.  I appreciate that someone is willing to do the work to create the abstraction, but remember that you are asking editors to maintain that abstraction.  Other such "gifts" have turned out to be extremely expensive in the past as well.

People have talked about comprehension.  I think that the pull request demonstrates a small regression in comprehension.  That might be improved, but, to my previous point, that's not work that I was planning on doing.

Either way, I've taken a look at the work so far and the number of subtle errors makes me disinclined to accept the gift.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4061#issuecomment-683633637

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 31 Aug 2020 12:21:21 -0700

> "there is the risk of ending up with a "non-portable" protocol that is much more tightly bound to UDP than intended."

QUIC was meant to run on UDP, and there was no intention to make this protocol portable in this working group. The first sentence of the [working group's charter](https://datatracker.ietf.org/wg/quic/about/) says: "The QUIC working group will provide standards-track specifications for a UDP-based, stream-multiplexing, encrypted transport protocol, based on pre-standardization implementation and deployment experience."

This suggests to me that building a portable version of QUIC is outside the scope of the working group.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4061#issuecomment-683980219