Subject: [quicwg/base-drafts] VN packets may be dropped more often when the QUIC bit is 0 (#2400)

From: ianswett <[email-masked]>
Date: Fri, 01 Feb 2019 18:25:43 -0800

I've had conversations with a number of people who are interested in identifying QUIC using the QUIC bit.  Only one packet does not have the QUIC bit always set to 1 currently, and that's version negotiation.
https://tools.ietf.org/html/draft-ietf-quic-transport-18#section-17.2.1

Given we have no use for the extra bits in VN, I'm inclined to specify implementations must set it to 1.

If we think we'll one day want to claw back use of the QUIC bit and allow it to be 0, then this is a poor plan, but I don't think that will end up being practical on the public internet.

A related question is whether we want to put the QUIC bit in the invariants.  It's clearly not technically necessary, but it would recognize the ossification I anticipate.

-- 
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/2400

---

From: Martin Thomson <[email-masked]>
Date: Sun, 03 Feb 2019 14:50:44 -0800

I have a different proposal: allow those that don't depend on this bit to toggle it.  That is, if you are certain that you don't need this bit set to 1, set it to 0 occasionally.

-- 
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/2400#issuecomment-460096593

---

From: ianswett <[email-masked]>
Date: Sun, 03 Feb 2019 22:02:14 -0800

That could work.  It comes down to whether the WG thinks the QUIC bit is a bug or feature, as well as whether enough people will toggle it that it won't be ossified anyway.

-- 
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/2400#issuecomment-460139816

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 03 Feb 2019 22:23:32 -0800

@ianswett I like how you frame the issue.

I think that the QUIC bit should either be defined in the invariants draft, or should be greased to avoid it getting ossified. And my weak preference goes to greasing the bit, so that we could have maximum flexibility in the future versions of QUIC.

-- 
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/2400#issuecomment-460142907

---

From: MikkelFJ <[email-masked]>
Date: Mon, 04 Feb 2019 09:20:00 +0000 (UTC)

I'm a bit concerned that relying on greasing is wishful thinking, here and elsewhere. Mostly this has been bypassed with header protection. All it takes is one dominant implementation to be lazy about it. Think older IE browsers vs. standards.

-- 
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/2400#issuecomment-460178120

---

From: David Schinazi <[email-masked]>
Date: Mon, 04 Feb 2019 17:01:06 -0800

The reason the second bit was fixed to 1 in QUICv1 was to allow multiplexing with other protocols. Greasing it would defeat that and would cause problems with some Google servers that use it for demultiplexing. Given that these demultiplexing concerns are unlikely to go away, it does make sense to add it to the invariants.

-- 
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/2400#issuecomment-460474767

---

From: martinduke <[email-masked]>
Date: Thu, 07 Feb 2019 09:17:18 -0800

I suspect VN packets will be pretty rare in the internet before we roll out v2, so we are in real danger of 50% of these packets failing because they have QUIC set to zero. The most straightforward solution is to just codify the ossification that will happen anyway.

@DavidSchinazi is this multiplexing mostly an issue for Initial Packets? Because the way to free up the QUIC bit could be to grease it in the Short Header. No one will implement something that drops 50% of 1RTT packets.

-- 
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/2400#issuecomment-461517373

---

From: David Schinazi <[email-masked]>
Date: Thu, 07 Feb 2019 17:50:14 -0800

@martinduke good point - most of the use-cases we have today are servers doing the demultiplexing, and VN is currently only server-to-client. I'm less worried about VN and more about the Internet ossifying "QUIC == the second bit is 1" without it being in the invariants. Greasing the second bit in client-to-server short headers would make it harder to demultiplex on the server without keeping track of all the issued connection IDs, and I don't think we want to make the server demultiplexer stateful.

-- 
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/2400#issuecomment-461662853

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 07 Feb 2019 20:03:03 -0800

I agree that the long header packets sent by the client needs to have the QUIC bit set.

I also agree that there's less need to have the bit set in the long header packets sent by the server, though I think it's possible to argue that we should not have different requirements based on the role, because QUIC does not have a distinguish a client address tuple and a server address tuple (i.e. an endpoint can use a one address tuple for accepting connections and also for initiating connections as a client).

For short header packets, I think we agree that the bit is not required. Then the question is, assuming that we decide to kill the bit, should we grease it, or rather, change it to a reserve bit? I suggest the latter because changing the definition to "reserved" and covering the bit using header protection is the strongest way of preserving the freedom to use the bit in future versions of QUIC. It can also be considered as a simplification, because there would be not need to "randomize" the bit for greasing; endpoints can rely on the header protection to flip the bits.

FWIW, current definition of the short header first byte is: `0 1 S R R K P P`. This would change to `0 S R R R K P P` if we are going to change the QUIC bit to a reserved bit.

-- 
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/2400#issuecomment-461683360

---

From: martinduke <[email-masked]>
Date: Thu, 07 Feb 2019 22:01:46 -0800

To me, it's clear that we should either (1) add it to the invariants or (2) bring it under header protection for server-generated packets only. (2) is somewhat inelegant, but we get to keep using the bits. Are there any privacy implications to there being a "client bit"?

-- 
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/2400#issuecomment-461700365

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 07 Feb 2019 22:14:48 -0800

> (2) bring it under header protection for server-generated packets only.

I would oppose to such a design, because that disables a reverse proxy from using a single port for accepting connections and also for initiating connections, assuming that either the proxy or a middlebox in front of the proxy relies on the QUIC bit to route the packets. Greasing would be fine, because it's not something to be required for every endpoint to implement.

> Are there any privacy implications to there being a "client bit"?

The bit would be a good indicator to police P2P traffic for ISPs...

-- 
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/2400#issuecomment-461702432

---

From: MikkelFJ <[email-masked]>
Date: Thu, 07 Feb 2019 23:22:44 -0800

I’m in favor of always setting the bit, and if not, symmetric header protection.

There are significant symmetric use cases, including NAT-punching p2p.

Making it 1 permanently lets QUIC co-exist, eg on a single client 443 port, and it avoids a lot of potential problems over a bit that is not needed.

________________________________
Fra: Kazuho Oku <[email-masked]>
Sendt: fredag, februar 8, 2019 7:14 AM
Til: quicwg/base-drafts
Cc: MikkelFJ; Comment
Emne: Re: [quicwg/base-drafts] VN packets may be dropped more often when the QUIC bit is 0 (#2400)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://github.com/quicwg/base-drafts/issues/2400#issuecomment-461702432>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AALzNxSA70R6OnQ0JdIwj0SmzAOEPCWYks5vLRXVgaJpZM4afXoe>.

-- 
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/2400#issuecomment-461713773

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 21 Feb 2019 18:30:42 -0800

IIRC, the bit was a result of us wanting to demux with various other protocols, and as such, the entire purpose of the bit is to allow identification of QUIC. This may not be a feature we like, but it is a feature.

I don't think we should be talking about the bit, but about co-existence with the other protocols. We discussed this, @martinthomson made a presentation about it (in Montreal, I think), and we agreed to co-exist.

While it can be seen as a natural consequence of setting the QUIC bit, I think the question we want to ask is whether we ought to make this co-existence an invariant. If so, what is the minimal set of packets that need to be demux-able with these other protocols. (We've been over this before, but I don't think we discussed whether it was adequate to demux only for the long header.)

-- 
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/2400#issuecomment-466249790

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 21 Feb 2019 18:40:08 -0800

> We discussed this, @martinthomson made a presentation about it (in Montreal, I think), and we agreed to co-exist.

FWIW most of the discussion happen in New York. See
https://github.com/quicwg/wg-materials/blob/master/interim-18-09/minutes.md#first-octet---martin-thomson.

-- 
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/2400#issuecomment-466251858

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 21 Feb 2019 21:01:33 -0800

@kazuho: thanks for jogging my memory. It seems that we didn't agree on something specific there.

-- 
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/2400#issuecomment-466274623