-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UDP-like, not exclusively UDP #1250
Comments
Let's get an IP protocol number :-) |
From the first sentence of the charter: "The QUIC working group will provide a standards-track specification for a UDP-based, stream-multiplexing..." So I'm biased towards saying this is QUICv2. |
I think that it is reasonable to say that we are developing invariants that are based on UDP. In doing so we make no claims about the use of QUIC over other substrates (such as IP directly). That seems perfectly OK. This is invariants, so it can't be v2. |
The invariants don't say anything about non-UDP substrates, as you note, so I think it can be v2, because non-UDP substrates are out of scope. |
V2, please! |
agreed, v2 or later. |
I think the/another problem with this is that, unlike TCP, QUIC doesn't have port numbers -- it leaves that concern to UDP. If we want to work atop something other than UDP, then we need to replace that multi-recipient functionality (or build atop something with equivalent recipient-demuxing capability). Or say that QUIC is a per-device service in a non-UDP environment and use connection IDs to demux. ;-) Regardless, this is outside our charter as noted on the list. We're explicitly chartered to define QUIC over UDP. I'm inclined to close this with no action on that basis. |
Charter or not, it would be considerate to at least contemplate non-UDP designs, especially if this can be done with minimal impact. With dual connection ID's I don't see a strong need for port numbers - there might be some corner cases in handshake, and there might be some text that isn't sufficiently clear in this regard, but fundamentally this ought to be workable. For example sensor networks using a minimal size connection ID dropping all data at IP/DUP layer and leaving any external routing to a gateway that understands 8-bit CID's through an out of band configuration. |
Based on the feedback thus far and Section 3, I'm going to close with no action. That doesn't mean that we're not going to ignore other substrates, only that our invariants are UDP-specific. |
@enygren suggests:
Would it make sense to say that "endpoints exchange QUIC packets via a datagram protocol such as UDP"? While we are currently only defining on UDP, there is nothing in invariants that would force this perpetually.
The text was updated successfully, but these errors were encountered: