What can change in a different version

[martinthomson]

We need to know what can change between versions.

The critical thing for forward compatibility is the ability to signal that a new version is being used. In order to do so, the recipient (the server here) needs to be able to find the version field. Given the current packet layout, that means that we need to guarantee that the connection ID and version bits behave consistently across versions and that no extra fields are added in between the start of the packet and the version.

[ianswett]

I think only the version bit, where the version is located and it's size need to not change. And in theory, they only need to not change in some small set of packets(ie: the first handshake packets).

We should be very hesitant to move the connection id, and maybe in practice we'll never be willing to because it'll break too many things, but we could in theory.

[martinduke]

At a minimum, the VERSION bit must not change. I argue that there also has to be a MORE_FLAGS bit, and that this must also not change if the receiver can parse where the flags end.

If it is at all possible that a later version might change the length of the connection ID field (as earlier QUIC versions did), we must move the version field in front of conn ID to correctly parse the header.

[martinduke]

After thinking about it a bit, I may be willing to fold on putting the version number first.

It's not too onerous to make host use the full 64 bits of the conn-id until the version is negotiated.

Also, we're looking at quadrillions of connections on a single server before there's much chance of a connection ID collision, and in that case the only consequence is a dropped CHLO. So allowing for > 64 bits in the far future may be a bit too paranoid.

But that means that the "must not change between versions" section I'm proposing should also lock the connection ID length for version negotiation packets.

[ianswett]

Yes, clearly the version bit must not change. And I think it's fine to always have the client use a 64 bit connection id until negotiated, but I think there were a few folks interested in suggesting 128 bit connection ids for future connections. If that becomes a requirement, then putting the version before the connection id may be the way to go?

The benefit of the current approach where the connection ID directly follows the flags is it's easy for load balancers to deal with. That being said, if they're going to have to deal with an extended flags bit, the extra complexity of dealing with a connection id that comes after the version may not matter.

And I do think the MORE_FLAGS bit should be defined. The alternative would be to not use more than one flag byte until after version negotiation is complete, but that may be sub-optimal.

[martinthomson]

We need to remind ourselves of the goal here. The goal is to ensure that a new version of this protocol - really any other protocol, because nothing says that you have to do QUIC or HTTP in the future - can be deployed alongside the version of the protocol that we define, probably on the same server address and port.

QUIC relies on out-of-band configuration. For the HTTP usage, we assume that clients are going to try h2 first. It could be that we decide that compatibility is a mugs game and that the Alt-Svc announcement will need to pick a new port number in order to use a new version.

To be clear, I think that's unlikely. For one, I imagine that Google want to continue to use port 443 when they deploy the standardized protocol. Having a migration path that retains the same port number is a smoother upgrade path. The same arguments for moving to standard-QUIC from Google-QUIC likely apply to leaving standard-QUIC for the next thing.

From what I understand, the initial packets on a flow need to include connection ID always. The initial packets on a connection require the version. That fixes the initial header pretty well. I would suggest that after confirming that the protocol is understood by the other side, almost anything is possible.

[britram]

One suggestion here: the version number space could be defined such that the version number field appears as the first 32 bits of the packet if present; i.e. a valid version number & 0x01000000 == 0x01000000, such that the first N bits of the packet either look like:

+-------------+-+------------------------------------------------+
|             |1|      version                                   |
+-------------+-+------------------------------------------------+
| flags       |1|
+-------------+-+ ...

or

+-------------+-+
|   flags     |0|
+-------------+-+ ...
               ^-- version flag

(The current multi-varlen layout of the wire image still seems to me to be unnecessarily fiddly, but that's a larger issue that will receive a separate post to quic@)

[quic-issues]

Just one additional thought: If you use the connection id for load balancing I assume you use the port number as an indication that you actually look at a quic packet that is encapsulated in UDP. I guess if you see the version number also as some kind of magic number (and apply some care in selecting your version number to not use a bit pattern that is already used by a different protocol over udp), you would get some additional confidence that you actually look at a quic packet. Not sure if that is worth is or if this is a good idea at all but might at least be worth thinking about it.

…

Am 14.12.2016 um 15:56 schrieb ianswett ***@***.***>: Yes, clearly the version bit must not change. And I think it's fine to always have the client use a 64 bit connection id until negotiated, but I think there were a few folks interested in suggesting 128 bit connection ids for future connections. If that becomes a requirement, then putting the version before the connection id may be the way to go? The benefit of the current approach where the connection ID directly follows the flags is it's easy for load balancers to deal with. That being said, if they're going to have to deal with an extended flags bit, the extra complexity of dealing with a connection id that comes after the version may not matter. And I do think the MORE_FLAGS bit should be defined. The alternative would be to not use more than one flag byte until after version negotiation is complete, but that may be sub-optimal. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[martinthomson]

I don't know who @quic-issues is, but they make the same point that I did earlier, namely that we do have some information about the packets - for the client this is out of band, and for the server, it's because they probably don't run RTP or something like that on the same port.

[quic-issues]

(I just saw that when I simply reply directly to an email it doesn’t show my email-address as sender. The mail below was from me. Mirja (Kühlewind))

…

Am 16.12.2016 um 22:32 schrieb QUIC WG Issues Account ***@***.***>: Just one additional thought: If you use the connection id for load balancing I assume you use the port number as an indication that you actually look at a quic packet that is encapsulated in UDP. I guess if you see the version number also as some kind of magic number (and apply some care in selecting your version number to not use a bit pattern that is already used by a different protocol over udp), you would get some additional confidence that you actually look at a quic packet. Not sure if that is worth is or if this is a good idea at all but might at least be worth thinking about it. > Am 14.12.2016 um 15:56 schrieb ianswett ***@***.***>: > > Yes, clearly the version bit must not change. And I think it's fine to always have the client use a 64 bit connection id until negotiated, but I think there were a few folks interested in suggesting 128 bit connection ids for future connections. If that becomes a requirement, then putting the version before the connection id may be the way to go? > > The benefit of the current approach where the connection ID directly follows the flags is it's easy for load balancers to deal with. That being said, if they're going to have to deal with an extended flags bit, the extra complexity of dealing with a connection id that comes after the version may not matter. > > And I do think the MORE_FLAGS bit should be defined. The alternative would be to not use more than one flag byte until after version negotiation is complete, but that may be sub-optimal. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or mute the thread. > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[larseggert]

Do you guys have that email reply stuff working for httpwg?

[martinduke]

So as I see it there are two extremes in the approach to this problem: 1) Minimum field consistency across versions. There must be exactly one flags byte, in which the VERSION bit's meaning and location cannot change. All other bits could, in theory, change. This byte must be followed by a 64-bit connection ID and the 32-bit version. If there are additional flag bytes, or additional bytes for the connection ID, they must appear after the version bytes. 2) More intuitively organized header fields. The VERSION and MORE_FLAGS bits must have their meaning and position unchanged, and all flags bytes are consecutive. If we want to preserve the ability to one day have conn ids > 64 bits, I believe it is necessary (in this approach) to move the version field ahead of the connection ID. **** Both of these approaches have their advantages, and it's possible to mix and match. But I believe these are the limits.

…

On Sat, Dec 17, 2016 at 9:32 AM, Lars Eggert ***@***.***> wrote: Do you guys have that email reply stuff working for httpwg? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#55 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AXRMEYirpi9EXb7npboTXWtErJjdF0KZks5rJByUgaJpZM4LCAfq> .

[britram]

Agreed. I'm in camp (2), though I'd go further: a given version number should be associated with a relatively small number of possible permutations of header field offsets and lengths.

[martinduke]

I am in camp 2 as well, but I understand the counterarguments: some migration pain for existing deployed QUIC versions (which illustrates the point, I think) and more complicated parsing by dumb middleboxes to find connection IDs.

…

On Thu, Dec 22, 2016 at 6:14 AM, Brian Trammell ***@***.***> wrote: Agreed. I'm in camp (2), though I'd go further: a given version number should be associated with a relatively small number of possible permutations of header field offsets and lengths. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#55 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AXRMEWNt_nBaz6WhyEjAPtyvQYSt8Mwnks5rKoXKgaJpZM4LCAfq> .

[britram]

On counterargument one: IMO the most important lesson to take from the transition from Cisco NetFlow version 9 to IPFIX (the latter was based on the former) is that the transition pain for existing deployments tends to be greater when the wire formats are more similar. "Break it once, then don't break it again" would have been much less painful than the "oh so that header diagram looks almost the same so I can safely ignore the rest of the text, there certainly aren't any subtle semantic differences to worry about there" transition that we got.

On counterargument two: not sure I follow... is the argument here that we want it to be hard for middleboxes to "find" the connection ID? I personally think this counterargument perilously underestimates the human ingenuity (or, if you'd like a negative expression, "sheer unmitigated gall") of middlebox designers, as well as the flexibility of VHDL as a programming environment for expressing hardware packet inspection. We can force there to be a predictable processing cost for this information through an encoding, or by making the connection ID the answer to a puzzle, but doing this through random offsets simply increases middlebox designer annoyance while increasing the potential of hard-to-debug processing errors in middlebox implementations (i.e. operator annoyance) more.

This is probably purely ideological: I just don't see the point of deciding to expose a thing, then making it pointlessly difficult to use. There may be a discussion to be had about encoding information exposed in the wire image as puzzle solutions, in order to make targeted diagnostic usage of these fields possible while making mass usage of them (e.g. for all QUIC flows crossing a network border) costly. However, if we select the set of things to expose properly, and design the semantics of connection ID properly, such mass usage would tend to be useless for nefarious purposes (tracking, surveillance) while still being useful for less nefarious purposes (proactive detection and/or localization of network performance issues).

[martinduke]

On counterargument two: not sure I follow... is the argument here that we *want* it to be hard for middleboxes to "find" the connection ID? I personally think this counterargument perilously underestimates the human ingenuity (or, if you'd like a negative expression, "sheer unmitigated gall") of middlebox designers, as well as the flexibility of VHDL as a programming environment for expressing hardware packet inspection. We can force there to be a predictable processing cost for this information through an encoding, or by making the connection ID the answer to a puzzle, but doing this through random offsets simply increases middlebox designer annoyance while increasing the potential of hard-to-debug processing errors in middlebox implementations (i.e. operator annoyance) more.

I must not have been clear. The point is that option (1) means that the connection ID (if 64 bits) is exactly one byte after the start of the UDP payload. This is very simple. Option (2) means that middleboxes would have to interpret the VERSION bit and the MORE_FLAGS bit to figure out how many bytes of offset for the connection ID. It's a bit more complicated, and a deviation for middleboxes that are already out there parsing QUIC in exactly that way out there. Again, I also favor (2), but for some reason I'm here making the counterargument.

…

This is probably purely ideological: I just don't see the point of deciding to expose a thing, then making it pointlessly difficult to use. There *may* be a discussion to be had about encoding information exposed in the wire image as puzzle solutions, in order to make targeted diagnostic usage of these fields possible while making mass usage of them (e.g. for all QUIC flows crossing a network border) costly. However, if we select the set of things to expose properly, and design the semantics of connection ID properly, such mass usage would tend to be useless for nefarious purposes (tracking, surveillance) while still being useful for less nefarious purposes (proactive detection and/or localization of network performance issues). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#55 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AXRMERvRmxE5jUfrsJiANE0DhmjExj_Jks5rNL18gaJpZM4LCAfq> .

[martinthomson]

Quoting @ekr:

I am fine with closing this for now, but it is tied directly to the
question of packet format and in particular how to handle packet
number and connection ID, so it will need revision if we decide
to adopt an encrypted packet number/conn-id proposal (which I
intend to make in Paris if not before).

I think that this is fair: as new information arises we should open new issues for those things. If we decide that a header format change is in order, then we will tackle that then.