Subject: [quicwg/base-drafts] Invariants extensbility (#1260)

From: Praveen Balasubramanian <[email-masked]>
Date: Mon, 02 Apr 2018 18:34:20 +0000 (UTC)

If future versions of QUIC require us to add more fields to the invariants, how would we go about it? Would we add the fields after the PN or before it? We lack a field that specifies the offset to encrypted payload start and there will be no more reserved bits left if the spin bit experiment is successful.  

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

---

From: ianswett <[email-masked]>
Date: Mon, 02 Apr 2018 18:37:20 +0000 (UTC)

In the long header, it would need to come after the connection IDs.
In the short header, it could go anywhere after the first byte, since there are no constraints in the current invariants draft.

Can you clarify the issue?  Is this an editorial request for clarity on how future versions of the invariants might change from the current one, or something else?

-- 
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/1260#issuecomment-378005245

---

From: Mike Bishop <[email-masked]>
Date: Mon, 02 Apr 2018 11:46:00 -0700

It seems a contradiction in terms to says that we would add something in a future version of the invariants.  These are supposed to be things which are true of *all* QUIC versions, and something we add in the future would, by definition, not be true of QUIC versions which precede it.  That makes it difficult for version-agnostic network components to observe it.

I think the first line of defense is to simply define them as version-specific, with the intention of including them in all future QUIC versions.  This does require version awareness on the part of the observer.  A more extended version might be a new document defining additional invariants which are true for all versions conforming to a particular version pattern (first byte of 0x01, for example).  This requires some version-awareness, but wouldn't require the observer to understand *particular* versions.

But most fundamentally is the answer I suggested and no one argued with during the call for adoption:  If the invariants differ, you're defining a new protocol which is not QUIC.  Describe *that* protocol's invariants (and hopefully how to demux it with QUIC) in a new RFC.

-- 
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/1260#issuecomment-378007647

---

From: Praveen Balasubramanian <[email-masked]>
Date: Mon, 02 Apr 2018 11:48:21 -0700

Both my education and a editorial request. I think it is important to state how extensibility will work in future. I think it is also important that we mark the invariant portions of the header some way in the transport draft diagrams of the headers, as otherwise a casual reader may assume other fields as invariant.

>>In the short header, it could go anywhere after the first byte, since there are no constraints in the current invariants draft.
The load balancers will need to know the location of the destination connection ID field for routing? Or are we expecting that the load balancers will need to become stateful and do version specific processing per connection? 

-- 
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/1260#issuecomment-378008309

---

From: Praveen Balasubramanian <[email-masked]>
Date: Mon, 02 Apr 2018 12:38:23 -0700

Thanks Mike, it would be good to state this position in the draft. 

I suspect that we will see hardware terminating QUIC at some point (not that we have any plans around this). And at that point I see deployment issues if adding a few bits to cleartext requires defining a new protocol but this is speculation so I don't have any opposition to the approach.

-- 
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/1260#issuecomment-378021339

---

From: Praveen Balasubramanian <[email-masked]>
Date: Mon, 02 Apr 2018 12:39:31 -0700

Ian please confirm that location of connection ID in short header is invariant as stated by the draft and that any changes to headers in future will be after this field.

-- 
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/1260#issuecomment-378021618