Skip to content
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

Closed
martinthomson opened this issue Mar 27, 2018 · 9 comments
Closed

UDP-like, not exclusively UDP #1250

martinthomson opened this issue Mar 27, 2018 · 9 comments
Labels
-invariants design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.

Comments

@martinthomson
Copy link
Member

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

@larseggert
Copy link
Member

Let's get an IP protocol number :-)

@ianswett
Copy link
Contributor

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.

@martinthomson
Copy link
Member Author

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.

@ianswett
Copy link
Contributor

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.

@mnot mnot added the design An issue that affects the design of the protocol; resolution requires consensus. label Mar 28, 2018
@huitema
Copy link
Contributor

huitema commented Mar 29, 2018

V2, please!

@pravb
Copy link

pravb commented Apr 1, 2018

agreed, v2 or later.

@MikeBishop
Copy link
Contributor

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.

@mikkelfj
Copy link
Contributor

mikkelfj commented Apr 2, 2018

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.

@martinthomson
Copy link
Member Author

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.

For all those who said v2:

@mnot mnot added the has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list. label Mar 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-invariants design An issue that affects the design of the protocol; resolution requires consensus. has-consensus An issue that the Chairs have determined has consensus, by canvassing the mailing list.
Projects
None yet
Development

No branches or pull requests

8 participants