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

From: Lars Eggert <[email-masked]>
Date: Wed, 02 Sep 2020 04:18:40 -0700

Thanks for the charter reminder, @janaiyengar. Given that, I am going to close this issue at this point, as we are certainly not going to be able to recharter before shipping v1.

-- 
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-685648414

---

From: Lars Eggert <[email-masked]>
Date: Wed, 02 Sep 2020 04:18:41 -0700

Closed #4061.

-- 
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#event-3719179776

---

From: John Ericson <[email-masked]>
Date: Thu, 03 Sep 2020 07:40:46 -0700

@DavidSchinazi 

> 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.

One thing I noticed is that while most of QUIC is agnostic to the addressing format, the packet advertising the new address is rather not extensible, being isomorphic to `(Optional<(Ipv4, Port)>, Optional<(Ipv6, Port)>)` (in pseudo-Rust), rather than some sort tagged enum that would be more extensible.

> Given that, I am going to close this issue at this point, as we are certainly not going to be able to recharter before shipping v1.

Makes sense. Hopefully, my fears are unfounded and the generalization can happen later such fine. Thank you all for your feedback.

-- 
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-686538966

---

From: Mike Bishop <[email-masked]>
Date: Thu, 03 Sep 2020 09:19:25 -0700

> One thing I noticed is that while most of QUIC is agnostic to the addressing format, the packet advertising the new address is rather not extensible, being isomorphic to `(Optional<(Ipv4, Port)>, O…

That's a fair point; it's bound to the assumption of IP and some kind of port underlying it.  That said, it's also not core to the protocol -- an implementation that was addressed differently could simply define a parallel transport parameter that carries a different address type.  You're right that this might be made more generic by supplying a count-prefixed list of addresses, each of which contained an enum address type followed by a length-prefixed address blob; I don't think there's appetite for such generality when the alternative of a new TP type is cheap.

-- 
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-686603154

---

From: John Ericson <[email-masked]>
Date: Thu, 03 Sep 2020 10:04:07 -0700

I agree with all that. My example absolutely isn't a show-stopper, just the first example of the sort of thing that can crops up more easily with a UDP-specific text.

-- 
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-686627818