Subject: [quicwg/base-drafts] Robert Wilton Invariants Discuss 1 (#4468)

From: Lucas Pardue <[email-masked]>
Date: Mon, 04 Jan 2021 05:29:18 -0800

Robert Wilton said:

> A trivial discuss that should hopefully be easy to resolve, and it is plausible
> that the resolution may end up being in the QUIC transport document:
> 
> In this document, the unused bits are defined as:
> 
>                    Figure 4: Version Negotiation Packet
> 
>    Only the most significant bit of the first byte of a Version
>    Negotiation packet has any defined value.  The remaining 7 bits,
>    labeled Unused, can be set to any value when sending and MUST be
>    ignored on receipt.
> 
> In the QUIC transport document, they are defined as this:
> 
>                    Figure 14: Version Negotiation Packet
> 
>    The value in the Unused field is selected randomly by the server.
>    Clients MUST ignore the value of this field.  Servers SHOULD set the
>    most significant bit of this field (0x40) to 1 so that Version
>    Negotiation packets appear to have the Fixed Bit field.
> 
> I would have expected that these two should be consistent as to whether the
> Fixed Bit SHOULD be set to 1 or not.  Given draft-thomson-quic-bit-grease-00,
> it might be better if the SHOULD is removed from QUIC transport, but I will
> defer to the experts here.

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 04 Jan 2021 15:32:27 -0800

I think that Rob's suggestion to remove the "SHOULD" is ideal.

-- 
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/4468#issuecomment-754284839

---

From: David Schinazi <[email-masked]>
Date: Tue, 05 Jan 2021 04:46:47 -0800

Does someone remember why this SHOULD was added? The fixed bit is useful in the client-to-server direction because it allows servers to demultiplex QUIC with other protocols, but I don't remember what benefit it provided in the server-to-client direction.

-- 
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/4468#issuecomment-754614050

---

From: ianswett <[email-masked]>
Date: Tue, 05 Jan 2021 08:20:57 -0800

I believe there 'could' be applications(ie: WebRTC) which share a port with QUIC and might want to use this bit to demux even on the client side, but that's seems like a pretty theoretical problem, so I'd be inclined to drop the SHOULD.

-- 
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/4468#issuecomment-754740055

---

From: Marten Seemann <[email-masked]>
Date: Tue, 05 Jan 2021 19:03:09 -0800

> The fixed bit is useful in the client-to-server direction because it allows servers to demultiplex QUIC with other protocols, but I don't remember what benefit it provided in the server-to-client direction.

In a p2p setup, you might run QUIC clients and servers on the same port (in fact, that's what we're doing in libp2p), so demultiplexing might be important for both sides in that case.

-- 
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/4468#issuecomment-755045669

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 05 Jan 2021 21:25:36 -0800

Yes, this was to avoid collision with p2p protocols. As I recall, we had decided that this would be something we would recommend for v1, but not require this for future versions... and that if both endpoints agreed, then they could set the bit to something other than 1. I don't see why we should change this.

-- 
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/4468#issuecomment-755086993

---

From: David Schinazi <[email-masked]>
Date: Wed, 06 Jan 2021 03:27:25 -0800

In a P2P setup where we're demultiplexing with another bootstrapping protocol over UDP, is there a need for version negotiation packets at all? I'd expect the bootstrapping protocol to convey the supported QUIC versions, and at that point you don't need version negotiation. I'm in favor of removing the SHOULD on VN 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/4468#issuecomment-755245590

---

From: ianswett <[email-masked]>
Date: Wed, 06 Jan 2021 07:58:02 -0800

My thinking is along the lines of @DavidSchinazi but I also don't care much about whether we remove this or not.

-- 
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/4468#issuecomment-755384871

---

From: Mike Bishop <[email-masked]>
Date: Wed, 06 Jan 2021 08:07:52 -0800

The VN packet is version-independent.  v1 shouldn't be constraining its contents.  However, implementations are free to select the value they put there any way they wish, so if they find it useful to always set that bit, they may.

-- 
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/4468#issuecomment-755391438

---

From: Jana Iyengar <[email-masked]>
Date: Sun, 10 Jan 2021 21:59:33 -0800

This isn't constraining the contents of a VN packet broadly, it is constraining what a v1 sender sends in a VN packet. And, I don't think it's reasonable to require that P2P protocols shouldn't need to use VN.

My high-level point is this: IIRC, we had this SHOULD for co-existence with P2P protocols, and we went through a lot of discussion, especially with ART folks on this. Do we really want to re-litigate this point at this stage in the process?

Maybe I'm mis-remembering. If I am, and this SHOULD was there for a different reason that is no longer valid (or never was important), I'm happy to remove this.

-- 
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/4468#issuecomment-757641228

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Jan 2021 19:42:11 -0800

That's right.  Maybe we should have been more studious in capturing reasons.

I think that for those P2P applications that care about multiplexing, this is a non-issue.  Those applications can use their signaling channel to ensure that version negotiation does not happen.  If things get badly out of hand, endpoints can ensure that Version Negotiation packets are sent with the bit set to conform to other constraints.

-- 
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/4468#issuecomment-758375121

---

From: Marten Seemann <[email-masked]>
Date: Mon, 11 Jan 2021 20:08:56 -0800

> I think that for those P2P applications that care about multiplexing, this is a non-issue. Those applications can use their signaling channel to ensure that version negotiation does not happen.

That applies to peers discovered during the execution of the p2p protocol. Every p2p network has some hard-coded bootstrap nodes though, for which the QUIC version might not be known in advance.

-- 
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/4468#issuecomment-758383954

---

From: David Schinazi <[email-masked]>
Date: Tue, 12 Jan 2021 07:49:43 -0800

@marten-seemann are those hard-coded bootstrap nodes QUIC clients or servers? We're only talking about receipt of VN packets here.

-- 
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/4468#issuecomment-758748722

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Jan 2021 17:07:53 -0800

I think that we can keep the inconsistency, but we need someone (@janaiyengar) to follow up with Rob.

-- 
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/4468#issuecomment-759136159

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 12 Jan 2021 17:14:17 -0800

@rgwilton: At this point, I'd rather not change what was a design decision made by the wg, so I propose close with no action to this issue (not merge #4471). Can you see if the [explanation above](https://github.com/quicwg/base-drafts/issues/4468#issuecomment-757641228) is satisfactory to you?

-- 
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/4468#issuecomment-759138242

---

From: Robert Wilton <[email-masked]>
Date: Wed, 13 Jan 2021 01:58:23 -0800

To check that my understanding is correct:
 - VN packets (as per the Invariants doc) MAY set the fixed bit.
 - VN packets for QUIC version 1 (as per the transport doc) SHOULD set the fixed bit.
 
This behaviour is consistent, but the documents need to explain this more clearly.  Particularly, because the the first sentence of section 17.2.1 states: " A Version Negotiation packet is inherently not version-specific," and yet the value set in this field might be version specific.

Hence, I would suggest that you expand the description in the transport draft to explain that it SHOULD be set for QUIC version 1, but that other versions of QUIC may relax this requirement.  Noting that the transport draft already talks about future versions having different requirements on the length of connection ids.

-- 
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/4468#issuecomment-759339493

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Jan 2021 19:07:11 -0800

Closed #4468 via #4744.

-- 
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/4468#event-4209128316

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Jan 2021 19:09:13 -0800

Just to close the loop here.  I've added an explanation of two things to the draft that is about to go out: that this recommendation is to allow for multiplexing, and that this recommendation is not guaranteed to apply when other QUIC versions are in use.  I think that is in line with what @rgwilton suggests.  If you disagree, we might be able to tweak this more later, but I need to publish -34 so that the wheels of the process can continue to turn.

-- 
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/4468#issuecomment-760615750

---

From: Robert Wilton <[email-masked]>
Date: Fri, 15 Jan 2021 03:33:48 -0800

Just to confirm that I am happy with the committed text change.  Thanks for accommodating. 

-- 
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/4468#issuecomment-760889497