Subject: [quicwg/base-drafts] Remove connection ID length from NEW_CONNECTION_ID (#1181)

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Mar 2018 14:52:55 +0000 (UTC)

So I'm in two minds about this one.

Pros:

- it's less complicated having to worry about varying lengths
- we don't have to worry about the length encodings being not weird for the frame, and different than the long header

Cons:

- it makes it harder to parse the frame, because you need external information
- it might be overkill; if the problem is that changing the length of connection ID is error prone... don't do that then

Maybe @nibanks can add some arguments.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1181

-- Commit Summary --

  * Remove connection ID length from NEW_CONNECTION_ID

-- File Changes --

    M draft-ietf-quic-transport.md (22)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1181.patch
https://github.com/quicwg/base-drafts/pull/1181.diff

-- 
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/pull/1181

---

From: ianswett <[email-masked]>
Date: Mon, 12 Mar 2018 07:55:17 -0700

I'm not excited about this, because I'm not convinced we would never want to change the length of a connection ID during a connection.

To channel Jana, can you open an issue :)

-- 
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/pull/1181#issuecomment-372338209

---

From: Nick Banks <[email-masked]>
Date: Mon, 12 Mar 2018 15:08:53 +0000 (UTC)

I agree with your Pros. We shouldn't need to worry about supporting multiple Connection ID lengths.

As far as making the decoding harder, I agree it makes the decoding of the frames stateful, but decoding the packet as a whole already requires stateful processing. Something like Wireshark already had to remember the Connection ID length in both directions to accurately decode short headers. This change doesn't add any extra state requirement to that. So, I personally don't think it makes it harder.

-- 
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/pull/1181#issuecomment-372343190

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Mar 2018 15:14:40 +0000 (UTC)

I can open issues.  I chose not to in this case.

@nibanks, there is a material difference between stateful processing of the packet header - which has certain efficiency constraints that make stateful processing somewhat necessary - and processing frames.  While the current frame syntax requires that frame syntax be completely known, frames can be parsed without external information.  That's a nice property to preserve.

-- 
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/pull/1181#issuecomment-372345250

---

From: Marten Seemann <[email-masked]>
Date: Mon, 12 Mar 2018 15:16:00 +0000 (UTC)

Some time ago, we agreed that a self-describing frame is something desirable. There's one frame in gQUIC that doesn't fulfill this property (the STOP_WAITING frame), which leads to a bunch of special cases for parsing and writing these frames. I was very happy to get rid of those.

-- 
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/pull/1181#issuecomment-372345735

---

From: Nick Banks <[email-masked]>
Date: Mon, 12 Mar 2018 15:16:29 +0000 (UTC)

@martinthomson I agree it's a nice property to preserve. While, I still prefer making this change, I'd settle for disallowing a change in the length of Connection ID. Would that be an acceptable alternative?

-- 
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/pull/1181#issuecomment-372345914

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Mar 2018 08:19:22 -0700

What do you gain by prohibiting changes in length?  Not knowing what might be needed in future, I'd be inclined to retain the flexibility, even if it is hard to see how it might concretely be valuable.

-- 
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/pull/1181#issuecomment-372346996

---

From: ianswett <[email-masked]>
Date: Mon, 12 Mar 2018 08:31:58 -0700

One use case for changing the length: If you can migrate a user from an anycast IP to a unicast IP, you may be able to use a much shorter connection ID(ie: ~8 bytes instead of ~16)

-- 
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/pull/1181#issuecomment-372351796

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Mar 2018 15:36:20 +0000 (UTC)

That seems less than purely theoretical.  I was thinking about long-lived connections and cluster upgrades, but that's far easier to reason about.

-- 
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/pull/1181#issuecomment-372353431

---

From: Nick Banks <[email-masked]>
Date: Mon, 12 Mar 2018 15:36:41 +0000 (UTC)

Just because a new Connection ID is provided, doesn't mean it will be used. If the goal is to support a change in Connection ID length because a new length is required or recommended for efficiency, that sounds like a new feature really.

To support variable length Connection IDs will require the HW offload to also support variable length, and that's just one more thing to add to the complexity there. It will also require packet parsers, like Wireshark to do trial decoding for short headers in those situations where the Connection ID length was changed.

-- 
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/pull/1181#issuecomment-372353574

---

From: ekr <[email-masked]>
Date: Mon, 12 Mar 2018 10:52:03 -0700

I do not think we should make this change. It's much harder to parse the frame if it's not self-contained.

-- 
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/pull/1181#issuecomment-372403329

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Mar 2018 08:31:51 +0000 (UTC)

Closed #1181.

-- 
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/pull/1181#event-1518008135

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Mar 2018 08:35:12 +0000 (UTC)

I just can't see those as problems Nick.  HW offload will need to produce connection IDs of arbitrary length.  And consumption is entirely under your control, so it's a feature you don't have to use.  Wireshark will have all the keys and connection IDs, so I don't see a big problem (unless one connection ID is a prefix of another, and that's pathological enough that I'm sure people will forgive failure to parse over trial decryption).

See far more against than for, I think we're good as planned.

-- 
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/pull/1181#issuecomment-372586460