Subject: Consensus Call: More Connection ID Space #2736

From: Mark Nottingham <[email-masked]>
Date: Wed, 12 Jun 2019 16:01:48 +1000

Regarding:
<https://github.com/quicwg/base-drafts/issues/2736>

The editors believe that this PR resolved the issue:
<https://github.com/quicwg/base-drafts/pull/2749>

....and discussion so far seems to support consensus to do so. If you object, please do so on the issue or in response to this message; absent any pushback, we'll declare consensus at the end of the week.

Regards,

--
Mark Nottingham   https://www.mnot.net/

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 12 Jun 2019 16:28:41 +1000

Unlike other consensus calls, which seem to have passed without comment, I'd like to encourage people who support this to say something.  This is a change to a document that we previously agreed would not change.

On Wed, Jun 12, 2019, at 16:02, Mark Nottingham wrote:
> .....and discussion so far seems to support consensus to do so. If you 
> object, please do so on the issue or in response to this message; 
> absent any pushback, we'll declare consensus at the end of the week.
> 
> Regards,
> 
> --

---

From: Ted Hardie <[email-masked]>
Date: Wed, 12 Jun 2019 09:16:06 -0700

Hi Mark,

https://github.com/quicwg/base-drafts/issues/2770 was raised in part
because of this change, and it is not resolved.  While I do not expect that
it will cause a reversion of this design theory, it might be useful to wait
on declaring consensus for this until it resolves, in case the resolution
suggests a limit change.

Could we encourage folks to test with the higher limits and new encoding
for now, but not close the issue?

regards,

Ted

On Tue, Jun 11, 2019 at 11:02 PM Mark Nottingham <[email-masked]> wrote:

> object, please do so on the issue or in response to this message; absent
> any pushback, we'll declare consensus at the end of the week.
>
> Regards,
>
> --

---

From: Roberto Peon <[email-masked]>
Date: Wed, 12 Jun 2019 16:37:58 +0000

I believe the benefits outweigh the downsides at the moment.

On 6/11/19, 11:29 PM, "QUIC on behalf of Martin Thomson" <[email-masked] on behalf of [email-masked]> wrote:

    On Wed, Jun 12, 2019, at 16:02, Mark Nottingham wrote:
    > Mark Nottingham   https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mnot.net_&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=3jttYWcGH_H9GaCCGTDkx71h_ItBIu_koLoaozILbq4&s=K3Jn5MSKtAUv9Q8JUyOLsH4OcXAsjLI5bV4g8ihHBZY&e= 
    > 
    >

---

From: David Schinazi <[email-masked]>
Date: Wed, 12 Jun 2019 10:44:39 -0700

I support the proposed change to the invariants and I think PR 2749
<https://github.com/quicwg/base-drafts/pull/2749> is ready.

I do not think we should wait for the stateless reset length issue
<https://github.com/quicwg/base-drafts/issues/2770> because I am confident
that it will be resolved soon. Additionally, if that issue results in a
limit change, that will be easier to deploy than the change to the encoding
of lengths on the wire (which are in the invariants).

Having the invariant changes land ASAP will make it easier to deploy in
Google's production environment.

David

On Wed, Jun 12, 2019 at 9:38 AM Roberto Peon <[email-masked]> wrote:

> On 6/11/19, 11:29 PM, "QUIC on behalf of Martin Thomson" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     Unlike other consensus calls, which seem to have passed without
> comment, I'd like to encourage people who support this to say something.
> This is a change to a document that we previously agreed would not change.
>
>     > Mark Nottingham
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mnot.net_&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=3jttYWcGH_H9GaCCGTDkx71h_ItBIu_koLoaozILbq4&s=K3Jn5MSKtAUv9Q8JUyOLsH4OcXAsjLI5bV4g8ihHBZY&e=
>     >
>     >
>
>
>
>

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 13 Jun 2019 09:56:07 +0900

2019年6月13日(木) 2:45 David Schinazi <[email-masked]>:
>
> I support the proposed change to the invariants and I think PR 2749 is ready.

+1.

I am fine with delaying the consensus call until #2770 gets resolved,
but I think it would be preferable to merge #2749 to encourage people
starting to use the new wire format.

> I do not think we should wait for the stateless reset length issue because I am confident that it will be resolved soon. Additionally, if that issue results in a limit change, that will be easier to deploy than the change to the encoding of lengths on the wire (which are in the invariants).
>
> Having the invariant changes land ASAP will make it easier to deploy in Google's production environment..
>
> David
>

-- 
Kazuho Oku

---

From: Eric Kinnear <[email-masked]>
Date: Wed, 12 Jun 2019 18:59:25 -0700

I also support this change for many of the same reasons already discussed. 

If we’re already bumping up against the invariants, this is the kind of experience that we’re asking folks to provide so we can make the necessary adjustments.
And if we’re going to change the invariants, let’s get it merged as soon as we can so we can get everything changed over to the new format. 

Thanks,
Eric

> On Jun 12, 2019, at 5:56 PM, Kazuho Oku <[email-masked]> wrote:
>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 13 Jun 2019 08:40:29 +0300

> Unlike other consensus calls, which seem to have passed without comment, I'd like to encourage people who support this to say something.  This is a change to a document that we previously agreed wo…

(Chair hat off)

Personally, I'm somewhat disappointed about how much we feel we need to cater to the needs/desires of the current state-of-the-art in large-scale load balancers. 18 bytes was IMO already quite a lot, and 256 bytes seems completely over the top. I really wonder if this will all be pointless with next-gen LB designs.

Lars

---

From: Christian Huitema <[email-masked]>
Date: Wed, 12 Jun 2019 23:34:21 -0700

> On Jun 12, 2019, at 10:40 PM, Lars Eggert <[email-masked]> wrote:
> 

+1

My gut feeling is that if we adopted a 16 bytes limit, load balancers would just deal with it. Maybe pick symmetric encryption algorithms with shorter blocks, or some kind a hierarchical scheme.

But I have a hard time reconciling the emotion around shorter encoding of ack delays and the willingness to add 32 bytes of overhead in the packet headers.

-- Christian Huitema

---

From: Marten Seemann <[email-masked]>
Date: Thu, 13 Jun 2019 14:57:05 +0800

I'm not really happy with the new proposal. 18 bytes is a lot of overhead
already, and having a connection ID of 48 bytes will be an even larger
overhead for QUIC packets (around 4% assuming a packet size of 1250 bytes).

Besides the obvious inefficiency, which is only born by the implementations
that actually decide to make use of these long connection IDs (or rather,
by their peers), there are two other downsides to this proposal, which
affect all QUIC implementations:
1. Since only 48 out of the 256 length values are permitted in QUIC v1, and
we don't have any greasing scheme, these bits are likely to ossify pretty
quickly.
2. As pointed out in #2770, this change makes stateless resets a lot less
useful than they used to be, and the best mitigation seems to be to require
large amounts of padding for small QUIC packets.

On Thu, Jun 13, 2019 at 2:35 PM Christian Huitema <[email-masked]>
wrote:

> > Personally, I'm somewhat disappointed about how much we feel we need to
> cater to the needs/desires of the current state-of-the-art in large-scale
> load balancers. 18 bytes was IMO already quite a lot, and 256 bytes seems
> completely over the top. I really wonder if this will all be pointless with
> next-gen LB designs.
>
> +1
>
> My gut feeling is that if we adopted a 16 bytes limit, load balancers
> would just deal with it. Maybe pick symmetric encryption algorithms with
> shorter blocks, or some kind a hierarchical scheme.
>
> But I have a hard time reconciling the emotion around shorter encoding of
> ack delays and the willingness to add 32 bytes of overhead in the packet
> headers.
>
> -- Christian Huitema
>

---

From: David Schinazi <[email-masked]>
Date: Thu, 13 Jun 2019 10:01:08 -0700

I'm realizing the PR makes two changes and one might get better consensus
than the other.
(1) Change the encoding of connection ID lengths in long headers (and
invariants)
(2) Change the maximum allowed connection ID length in QUICv1 from 18 to 48

I personally believe (1) is important and time-sensitive. The QUIC
invariants will be with us for a long time, and it would be unfortunate to
be stuck with {0, [3-18]} forever. The only downside is spending one extra
byte on long headers and I think that's acceptable.

Perhaps we could:
- make this PR only change (1)
- have the consensus call only discuss (1)
- merge (1) if there is consensus
- wait for progress on the stateless reset length issue (#2770)
<https://github.com/quicwg/base-drafts/issues/2770>
- decide together if we want to change the maximum connection ID length in
QUICv1 to something higher than 18

How do people feel about this?

David

On Wed, Jun 12, 2019 at 11:57 PM Marten Seemann <[email-masked]>
wrote:

> Besides the obvious inefficiency, which is only born by the
> implementations that actually decide to make use of these long connection
> IDs (or rather, by their peers), there are two other downsides to this
> proposal, which affect all QUIC implementations:
> 1. Since only 48 out of the 256 length values are permitted in QUIC v1,
> and we don't have any greasing scheme, these bits are likely to ossify
> pretty quickly.

---

From: Mike Bishop <[email-masked]>
Date: Thu, 13 Jun 2019 17:11:23 +0000

I agree with you that there’s probably firmer consensus about permitting large numbers than there is about the specific number to choose in v1.  However, the point of the change is to make it larger than 18, so leaving it at 18 seems somewhat counter-intuitive.  Also, I don’t think #2770 is going to realistically change the max CID length we select – it’s going to change our guidance about what to do if you’re using a long CID.

If there’s disagreement about the number 48, splitting this into two PRs and calls might be a way to make forward progress.  If we have consensus on 48, then let’s do it all now.

From: QUIC <[email-masked]> On Behalf Of David Schinazi
Sent: Thursday, June 13, 2019 10:01 AM
To: Marten Seemann <[email-masked]>
Cc: Lars Eggert <[email-masked]>; QUIC WG <[email-masked]>; Christian Huitema <[email-masked]>; Martin Thomson <[email-masked]>
Subject: Re: Consensus Call: More Connection ID Space #2736

I'm realizing the PR makes two changes and one might get better consensus than the other.
(1) Change the encoding of connection ID lengths in long headers (and invariants)
(2) Change the maximum allowed connection ID length in QUICv1 from 18 to 48

I personally believe (1) is important and time-sensitive. The QUIC invariants will be with us for a long time, and it would be unfortunate to be stuck with {0, [3-18]} forever. The only downside is spending one extra byte on long headers and I think that's acceptable.

Perhaps we could:
- make this PR only change (1)
- have the consensus call only discuss (1)
- merge (1) if there is consensus
- wait for progress on the stateless reset length issue (#2770)<https://github.com/quicwg/base-drafts/issues/2770>
- decide together if we want to change the maximum connection ID length in QUICv1 to something higher than 18

David

On Wed, Jun 12, 2019 at 11:57 PM Marten Seemann <[email-masked]<mailto:[email-masked]>> wrote:
I'm not really happy with the new proposal. 18 bytes is a lot of overhead already, and having a connection ID of 48 bytes will be an even larger overhead for QUIC packets (around 4% assuming a packet size of 1250 bytes).

Besides the obvious inefficiency, which is only born by the implementations that actually decide to make use of these long connection IDs (or rather, by their peers), there are two other downsides to this proposal, which affect all QUIC implementations:
1. Since only 48 out of the 256 length values are permitted in QUIC v1, and we don't have any greasing scheme, these bits are likely to ossify pretty quickly.
2. As pointed out in #2770, this change makes stateless resets a lot less useful than they used to be, and the best mitigation seems to be to require large amounts of padding for small QUIC packets.

On Thu, Jun 13, 2019 at 2:35 PM Christian Huitema <[email-masked]<mailto:[email-masked]>> wrote:

> On Jun 12, 2019, at 10:40 PM, Lars Eggert <[email-masked]<mailto:[email-masked]>> wrote:
>

+1

-- Christian Huitema

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 13 Jun 2019 13:54:44 -0400

On Thu, Jun 13, 2019 at 02:57:05PM +0800, Marten Seemann wrote:
> implementations that actually decide to make use of these long
> connection IDs (or rather, by their peers),

The peer can provide CIDs of any size via NEW_CONNECTION_ID, so
unless an implementation throws longs CIDs out, it has to support
long CIDs.  In addition, a server has no choice but to support
maximum-size ODCID.

There are trade-offs:

    1. Make its cid_t a fixed-size object that can fit the
       largest CID and eat the overhead for all CIDs.  This
       has large memory overhead but it is simple and has
       good locality of refence.

    2. Make cid_t a variable-size object.  This saves memory
       overall, but is more complicated and likely slower
       (two memory accesses to get CID).

    3. Have two types: peer_cid_t that can be any size and
       my_cid_t that supports CIDs of fixed length picked by
       the implementation.  This is even more complicated.

To summarize, the maximum CID length affects all implementations.

  - Dmitri.

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Fri, 14 Jun 2019 10:34:12 +0200

> On 13. Jun 2019, at 19:54, Dmitri Tikhonov <[email-masked]> wrote:
> 

We could make the maximum SCID LEN a transport parameter and 
make it an error to extend the connection ID beyond this value.
Together with a sane minimal CID a server has to support, this 
mitigates evil clients that try to exhaust resources at the
server without limiting the client.

If we have such a mechanism, we can allow the full 255 byte
connection IDs for special purpose use cases that presume they need such long CIDs

> To summarize, the maximum CID length affects all implementations.

AVE!
   Philipp S. Tiesel

-- 
Philipp S. Tiesel 
https://philipp.tiesel.net/

---

From: Mike Bishop <[email-masked]>
Date: Fri, 14 Jun 2019 15:21:21 +0000

That's problematic, because it's the issuer's infrastructure that dictates the CID size it needs to receive.  A real implementation isn't just making these up for fun.  If a peer says they can't tolerate CIDs of the size the infrastructure uses, the answer will likely be something along the lines of "too (expletive) bad," and we'll be introducing fragmentation into interoperability.  I don't think that's a good solution.

If we feel like we need to constrain this, perhaps a better mitigation would be to advertise the number of bytes you're willing to allocate to tracking the CIDs rather than the static count we do now.  Then a server with large CIDs will issue fewer to you at a time, while a server with small CIDs could issue many more.  However, that only constrains resource exhaustion; it doesn't address Dmitri's point about code efficiency.

From: QUIC <[email-masked]> On Behalf Of Philipp S. Tiesel
Sent: Friday, June 14, 2019 1:34 AM
To: Dmitri Tikhonov <[email-masked]>
Cc: Marten Seemann <[email-masked]>; Lars Eggert <[email-masked]>; QUIC WG <[email-masked]>; Christian Huitema <[email-masked]>; Martin Thomson <[email-masked]>
Subject: Re: Consensus Call: More Connection ID Space #2736

On 13. Jun 2019, at 19:54, Dmitri Tikhonov <[email-masked]<mailto:[email-masked]>> wrote:

There are trade-offs:

 - Dmitri.

AVE!
   Philipp S. Tiesel

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 15 Jun 2019 06:04:10 -0700

> (2) Change the maximum allowed connection ID length in QUICv1 from 18 to 48

For the record, I am in favor of both changes.

> How do people feel about this?

I can live with this, but it would not be my preference.

-Ekr

>>> > Personally, I'm somewhat disappointed about how much we feel we need
>>> to cater to the needs/desires of the current state-of-the-art in
>>> large-scale load balancers. 18 bytes was IMO already quite a lot, and 256
>>> bytes seems completely over the top. I really wonder if this will all be
>>> pointless with next-gen LB designs.
>>>
>>> +1
>>>
>>> But I have a hard time reconciling the emotion around shorter encoding
>>> of ack delays and the willingness to add 32 bytes of overhead in the packet
>>> headers.
>>>
>>> -- Christian Huitema
>>>
>>

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Sat, 15 Jun 2019 16:14:05 +0200

HI

> On 14. Jun 2019, at 17:21, Mike Bishop <[email-masked]> wrote:
> 
> That’s problematic, because it’s the issuer’s infrastructure that dictates the CID size it needs to receive.  A real implementation isn’t just making these up for fun.  If a peer says they can’t tolerate CIDs of the size the infrastructure uses, the answer will likely be something along the lines of “too (expletive) bad,” and we’ll be introducing fragmentation into interoperability.  I don’t think that’s a good solution.

I think it depends weather you see this as a symmetric or a asymmetric problem:
 - If it is just about server resource exhaustion and code efficiency on the server side, such a parameter could help.
 - For the symmetric case, where also the client could constrain the CID length used by the server, I share your concerns unless we recommend some very large default CID as minimum.

>  
> If we feel like we need to constrain this, perhaps a better mitigation would be to advertise the number of bytes you’re willing to allocate to tracking the CIDs rather than the static count we do now.  Then a server with large CIDs will issue fewer to you at a time, while a server with small CIDs could issue many more.  However, that only constrains resource exhaustion; it doesn’t address Dmitri’s point about code efficiency.
>  
> On 13. Jun 2019, at 19:54, Dmitri Tikhonov <[email-masked] <mailto:[email-masked]>> wrote:
>  
> https://philipp.tiesel.net/ <https://philipp.tiesel.net/>
AVE!
  Philipp S. Tiesel / phils…
-- 
   {phils}--->---([email-masked])--->---(http://phils.in-panik.de)----,
      wenn w eine   aube ist dn      man au dran dre en                   |
           o     Schr        an muss     hc         h   (Kurt Schwitters) |
:wq!  <----(phone: +49-179-6737439)---<---(jabber: [email-masked])----'

---

From: Martin Duke <[email-masked]>
Date: Sat, 15 Jun 2019 14:14:13 -0700

1. I'll chime in to say that a v1 limit of 48 bytes is fairly arbitrary
choice, well in excess of any use case we're interested at any time. If
there is a number 18 < n < 48 that can gain consensus, I am comfortable
with moving to that number. Frankly, we can just barely make 18B work given
current use cases, so even sticking to 18 wouldn't derail everything in the
short term. I think it was Kazuho that suggested someone might want 2
levels of block encryption, which implies 32B + "a few" more bytes for
other stuff, and from there I rounded up to 48.

2. Would a post-quantum world require larger block sizes? If so, the
invariants should definitely leave the necessary space.

3. I agree that we are danger of ossifying to block CID lengths > whatever
the largest is used in practice, regardless of what the v1 theoretical
limit is. However, the answer is not to "pre-ossify" ourselves to ome
limit. Allow 255, and if firewalls end up blocking certain use cases, we'll
have to deal with that when we come ot it.

On Sat, Jun 15, 2019 at 7:14 AM Philipp S. Tiesel <[email-masked]>
wrote:

> That’s problematic, because it’s the issuer’s infrastructure that dictates
> the CID size it needs to receive.  A real implementation isn’t just making
> these up for fun.  If a peer says they can’t tolerate CIDs of the size the
> infrastructure uses, the answer will likely be something along the lines of
> “too (expletive) bad,” and we’ll be introducing fragmentation into
> interoperability.  I don’t think that’s a good solution.
>
>
>  - If it is just about server resource exhaustion and code efficiency on
> the server side, such a parameter could help.
>  - For the symmetric case, where also the client could constrain the CID
> length used by the server, I share your concerns unless we recommend some
> very large default CID as minimum.
>
>
> If we feel like we need to constrain this, perhaps a better mitigation
> would be to advertise the number of bytes you’re willing to allocate to
> tracking the CIDs rather than the static count we do now.  Then a server
> with large CIDs will issue fewer to you at a time, while a server with
> small CIDs could issue many more.  However, that only constrains resource
> exhaustion; it doesn’t address Dmitri’s point about code efficiency.
>
> *From:* QUIC <[email-masked]> *On Behalf Of *Philipp S. Tiesel
> *Sent:* Friday, June 14, 2019 1:34 AM
> *To:* Dmitri Tikhonov <[email-masked]>
> *Cc:* Marten Seemann <[email-masked]>; Lars Eggert <
> [email-masked]>; QUIC WG <[email-masked]>; Christian Huitema <
> [email-masked]>; Martin Thomson <[email-masked]>
> *Subject:* Re: Consensus Call: More Connection ID Space #2736
>
>
>
>

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 16 Jun 2019 14:55:48 +0900

2019年6月16日(日) 6:14 Martin Duke <[email-masked]>:
>
> 1. I'll chime in to say that a v1 limit of 48 bytes is fairly arbitrary choice, well in excess of any use case we're interested at any time. If there is a number 18 < n < 48 that can gain consensus, I am comfortable with moving to that number. Frankly, we can just barely make 18B work given current use cases, so even sticking to 18 wouldn't derail everything in the short term. I think it was Kazuho that suggested someone might want 2 levels of block encryption, which implies 32B + "a few" more bytes for other stuff, and from there I rounded up to 48.

Yes. My argument for expanding the maximum CID size is that it would
be preferable to support 2 + block_size + alpha, with block_size being
the block size of a standardized block cipher. FWIW, stated below is
how I think.

As we have agreed in the past, one way of a "server" implementing a
CID scheme is to use a block cipher. Then, the CID could contain the
ID of the thread (or the process) that handles the connection. It is
preferable also for a load balancer to rely on a block cipher to
encrypt the ID of the server instance that the connection is handled
by.

Note that in either case it is not a good idea to use a steam cipher
(or a block cipher in CTR mode), because the CID becomes malleable,
allowing an attacker to target a DoS attack against particular server
instance behind the load balancer (or a particular thread within a
server instance).

_If_ we are to allow loose coupling between a load balancer and a
server, each of the two should be given the freedom to choose it's own
CID encryption scheme. Because all the standardized block ciphers are
now 128-bits (= 16 bytes), that naturally means that the maximum CID
length of QUIC needs to be double amount of that, plus one or two
bytes for each of the two for identifying the CID encryption keys. For
key identification and other supplemental use, we currently allocate 2
bytes (18-16=2).

Based on these numbers, the conclusion goes to having (16 + 2) * 2 = 36 bytes.

>
> 2. Would a post-quantum world require larger block sizes? If so, the invariants should definitely leave the necessary space.
>
> 3. I agree that we are danger of ossifying to block CID lengths > whatever the largest is used in practice, regardless of what the v1 theoretical limit is. However, the answer is not to "pre-ossify" ourselves to ome limit. Allow 255, and if firewalls end up blocking certain use cases, we'll have to deal with that when we come ot it.
>
>
>
> On Sat, Jun 15, 2019 at 7:14 AM Philipp S. Tiesel <[email-masked]> wrote:
>>
>> HI
>>
>>    Philipp S.. Tiesel

-- 
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 16 Jun 2019 03:01:38 -0700

I’m wondering if overly long CID’s are just an attempt to implement
stateless NAT server side rather than taking advantage of IPv6?

You could use a shorter CID to add authentication to the IP header along
with other details for routing purposes.

I already find 18 bytes a lot, especially in addition to the IP header.

I can see a use case for content hashed addressing, but even here 18 bytes
ought to be enough.

On 15 June 2019 at 23.14.52, Martin Duke ([email-masked]) wrote:

---

From: Christian Huitema <[email-masked]>
Date: Sun, 16 Jun 2019 19:09:20 -0700

> key identification and other supplemental use, we currently allocate 2

That reasoning is based on the assumption that both the load balancer
and the server must use a block cipher with 128 bit block length in
order to encrypt the CID. If they were constrained to stay within a
short global limit, they could use different sets of algorithms.

Assume for example that we split the CID between 32 bits encoding the
number of the server in the server farm, and 64 bit encoding the
connection number for the server. The server can pick a random value for
the connection number, and use a hash table. The load balancer could use
a 32 bit variant of the FFX algorithm, using the lower 64 bit of the CID
as an initial vector. Voila, 96 CID, with demonstrably strong encryption.

Or assume that the server wants to use short CID. We now split the CID
between 32 bit for the server number in the farm, and 32 bit for the
connection number in the server. The server builds that connection
number by using a 32 bit variant of FFX. The load balancer also uses a
32 bit variant, using the lower 32 bit of the CID as initial vector for
this FFX encryption.

These are just two examples. And yes you may want to add 2 bytes for key
identification, etc. In both encryption algorithms, you can feed these
two bytes as additional IV for the FFX algorithm. And in both cases, we
are well below the 18 byte limit.

Yes, that requires some creative engineering. But it is not rocker
science. And it seems better than carrying tons of overhead in the
header, and becoming less efficient than HTTP2/TLS/TCP.

-- Christian Huitema

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 17 Jun 2019 13:44:28 +0900

> header, and becoming less efficient than HTTP2/TLS/TCP.

I agree that it would not be the end of the world for the load
balancers if we decide to stick on the 18-byte limit. However, as you
state, it requires some creativeness.

To me it seems that the question is if we have a strong reason to
require some people to be creative, for all the versions of QUIC in
the future. I personally think that there isn't a strong reason,
because people can use shorter CIDs regardless of the decision we
make. IIUC, the overhead that everyone needs to accept is:

* one byte increase in the long header packets
* the minimum size of short header packets becoming slightly greater
(otherwise, the peer might not be able to send a stateless reset)

I'd say that the first bullet point is negligible. The second point
could also be, because I'd assume that the only frequently-sent
packets that require additional padding is the ACK-only packets, but
there's no reason to pad ACK-only packets in hope that you'd see a
stateless reset.

Therefore, my (not-so-strong) preference has been to provide extra
room, so that some people with necessity can use longer CIDs.

--
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 17 Jun 2019 02:50:45 -0400

Since it is more likely that you pay for egress traffic than ingress
traffic, the motivation to keep CID’s small is limited.

I do think the invariants should allow for long CID’s as proposed, and that
the long header overhead is not important.

But for QUIC v1, if we allow for a long CID, a rush to market will set
precedence and long CID’s will ossify in all kinds of stacks.

I good reference on an algorithm like suggested by Christian would go a
long way.

If CID length 18 turns out to be not enough, we can add a QUIC v2. It’s not
like we are not looking for excuses to upgrade QUIC versions soon.

If CID length negotiation is needed, this could be done via QUIC versions.
For example two functionally equivalent versions, but one with longer
CID’s. This would also allow routers to deal with changes in CID lengths. A
negotiated TP would not (easily) allow for that and aside I do not think
CID length in TP is the way to go.

Mikkel

On 17 June 2019 at 06.45.04, Kazuho Oku ([email-masked]) wrote:

-- 
Kazuho Oku

---

From: Ian Swett <[email-masked]>
Date: Mon, 17 Jun 2019 11:36:47 -0400

My intuition says making the change to the invariants is the right thing to
do, but I don't feel that strongly.

However, I'd like the max size to be smaller than 48(but larger than 18).
If we think 20 or 24 is sufficient, I'd prefer that.  Kazuho suggested 32,
which is better, but I don't believe the server needs to use a separate
block cipher when giving out connection IDs, because I believe it's
impractical for the load balancer and server to be that decoupled.  The
server has to give out a CID that the load balancer will use to route back
to the server, so they have to share enough an encryption key/algorithm.  I
can imagine nesting load balancers, but that's well in the range of QUIC v2
from my perspective.

Whatever we do, I'd really prefer to resolve this sooner rather than later
and be truly done with it.

On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahnøe Jørgensen <[email-masked]>
wrote:

> I do think the invariants should allow for long CID’s as proposed, and
> that the long header overhead is not important.
>
> If CID length 18 turns out to be not enough, we can add a QUIC v2. It’s
> not like we are not looking for excuses to upgrade QUIC versions soon.
>

---

From: "Lubashev, Igor" <[email-masked]>
Date: Mon, 17 Jun 2019 15:54:16 +0000

My take is similar – 48 is probably excessive, while 32 is likely the upper limit of “reasonable” (it should probably be a factor of 8, so 32 or 24?).

We are firmly committed for using CID for in-cluster load balancing / anycast pop routing.  This discussion is taking us, however, to a new territory – a generalized “destination-controlled routing in an overlay network”.  This is a very interesting topic, but I would hesitate to attempt to solve it fully and “in general” in QUIC v1.

  *   Igor

From: Ian Swett <ianswett=[email-masked]>

My intuition says making the change to the invariants is the right thing to do, but I don't feel that strongly.

However, I'd like the max size to be smaller than 48(but larger than 18).  If we think 20 or 24 is sufficient, I'd prefer that.  Kazuho suggested 32, which is better, but I don't believe the server needs to use a separate block cipher when giving out connection IDs, because I believe it's impractical for the load balancer and server to be that decoupled.  The server has to give out a CID that the load balancer will use to route back to the server, so they have to share enough an encryption key/algorithm.  I can imagine nesting load balancers, but that's well in the range of QUIC v2 from my perspective.

Whatever we do, I'd really prefer to resolve this sooner rather than later and be truly done with it.

On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>> wrote:
Since it is more likely that you pay for egress traffic than ingress traffic, the motivation to keep CID’s small is limited.

I do think the invariants should allow for long CID’s as proposed, and that the long header overhead is not important.

But for QUIC v1, if we allow for a long CID, a rush to market will set precedence and long CID’s will ossify in all kinds of stacks.

I good reference on an algorithm like suggested by Christian would go a long way.

If CID length 18 turns out to be not enough, we can add a QUIC v2. It’s not like we are not looking for excuses to upgrade QUIC versions soon.

If CID length negotiation is needed, this could be done via QUIC versions. For example two functionally equivalent versions, but one with longer CID’s. This would also allow routers to deal with changes in CID lengths. A negotiated TP would not (easily) allow for that and aside I do not think CID length in TP is the way to go.

Mikkel

On 17 June 2019 at 06.45.04, Kazuho Oku ([email-masked]<mailto:[email-masked]>) wrote:

--
Kazuho Oku

---

From: Roberto Peon <[email-masked]>
Date: Mon, 17 Jun 2019 16:16:35 +0000

What I think people are saying so far:
  1) QUIC v1 would limit CID length to something one of {32, 36, or 48}
   2) Representation of CID length as a byte is still OK, thus a QUIC v2 could use longer CIDs as needed by changing the spec while keeping the invariants… invariant.

That seems reasonable to me / I’d still support that.
-=R

From: QUIC <[email-masked]> on behalf of "Lubashev, Igor" <[email-masked]>
Date: Monday, June 17, 2019 at 8:55 AM
To: Ian Swett <ianswett=[email-masked]>, Mikkel Fahnøe Jørgensen <[email-masked]>
Cc: Dmitri Tikhonov <[email-masked]>, Christian Huitema <[email-masked]>, "Philipp S. Tiesel" <[email-masked]>, Mike Bishop <[email-masked]>, Martin Thomson <[email-masked]>, Marten Seemann <[email-masked]>, Lars Eggert <[email-masked]>, QUIC WG <[email-masked]>, Martin Duke <[email-masked]>, Kazuho Oku <[email-masked]>
Subject: RE: Consensus Call: More Connection ID Space #2736

  *   Igor

Mikkel

--
Kazuho Oku

---

From: Christian Huitema <[email-masked]>
Date: Mon, 17 Jun 2019 12:49:44 -0700

I too agree that using one byte in the invariant is preferable to the
current "compressed 4 bits" solution.

Regarding the "CID length limit", I thing there are two issues:
transmission overhead, and costs to the community.

I am not too concerned with the transmission overhead, as we have there
the right mix of costs and incentives. Servers who chose to use longer
CID will get more transmission overhead, and thus transmission less
efficiently than their competitors. They may chose to use longer CID as
a trade-off between transmission efficiency and ease of management.
Competition will sort that out. I note that YouTube is apparently doing
fine with smallish CID, so I trust that there will be competition.

I am much more concerned with the shared costs, which are a variation of
the "tragedy of the commons". Dmitry explained those costs well in a
previous message. The simpler implementation is to make the "cid_t a
fixed-size object that can fit the largest CID and eat the overhead for
all CIDs." But each connection object carries a large number of
instances of the CID type. Having a very large max CID would imply a
large overhead. The alternative is to "Make cid_t a variable-size
object", but too affects performance.

Hence the push-back. I would personally prefer a max size of 16, and I
think that 32 is the highest practical limit.

-- Christian Huitema

On 6/17/2019 9:16 AM, Roberto Peon wrote:
>    2) Representation of CID length as a byte is still OK, thus a QUIC
> v2 could use longer CIDs as needed by changing the spec while keeping
> the invariants… invariant.
>
>
> *From: *QUIC <[email-masked]> on behalf of "Lubashev, Igor"
> <[email-masked]>
> *Date: *Monday, June 17, 2019 at 8:55 AM
> *To: *Ian Swett <ianswett=[email-masked]>, Mikkel Fahnøe
> Jørgensen <[email-masked]>
> *Cc: *Dmitri Tikhonov <[email-masked]>, Christian Huitema
> <[email-masked]>, "Philipp S. Tiesel" <[email-masked]>, Mike
> Bishop <[email-masked]>, Martin Thomson <[email-masked]>,
> Marten Seemann <[email-masked]>, Lars Eggert
> <[email-masked]>, QUIC WG <[email-masked]>, Martin Duke
> <[email-masked]>, Kazuho Oku <[email-masked]>
> *Subject: *RE: Consensus Call: More Connection ID Space #2736
>
>  
>
> My take is similar – 48 is probably excessive, while 32 is likely the
> upper limit of “reasonable” (it should probably be a factor of 8, so
> 32 or 24?).
>
>  
>
> We are firmly committed for using CID for in-cluster load balancing /
> anycast pop routing.  This discussion is taking us, however, to a new
> territory – a generalized “destination-controlled routing in an
> overlay network”.  This is a very interesting topic, but I would
> hesitate to attempt to solve it fully and “in general” in QUIC v1.
>
>  
>
>   * Igor
>
>  
>
> *From:* Ian Swett <ianswett=[email-masked]>
>
> My intuition says making the change to the invariants is the right
> thing to do, but I don't feel that strongly.
>
>  
>
> However, I'd like the max size to be smaller than 48(but larger than
> 18).  If we think 20 or 24 is sufficient, I'd prefer that.  Kazuho
> suggested 32, which is better, but I don't believe the server needs to
> use a separate block cipher when giving out connection IDs, because I
> believe it's impractical for the load balancer and server to be that
> decoupled.  The server has to give out a CID that the load balancer
> will use to route back to the server, so they have to share enough an
> encryption key/algorithm.  I can imagine nesting load balancers, but
> that's well in the range of QUIC v2 from my perspective.
>
>  
>
> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahnøe Jørgensen
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Since it is more likely that you pay for egress traffic than
>     ingress traffic, the motivation to keep CID’s small is limited.
>
>      
>
>     I do think the invariants should allow for long CID’s as proposed,
>     and that the long header overhead is not important.
>
>      
>
>     But for QUIC v1, if we allow for a long CID, a rush to market will
>     set precedence and long CID’s will ossify in all kinds of stacks.
>
>      
>
>     If CID length 18 turns out to be not enough, we can add a QUIC v2.
>     It’s not like we are not looking for excuses to upgrade QUIC
>     versions soon.
>
>      
>
>     If CID length negotiation is needed, this could be done via QUIC
>     versions. For example two functionally equivalent versions, but
>     one with longer CID’s. This would also allow routers to deal with
>     changes in CID lengths. A negotiated TP would not (easily) allow
>     for that and aside I do not think CID length in TP is the way to go.
>
>      
>
>     Mikkel
>
>      
>

---

From: Marten Seemann <[email-masked]>
Date: Tue, 18 Jun 2019 11:33:19 +0800

I'd prefer keeping the "compressed 4 bits" solution, even if we decide to
increase the connection ID length to a larger value (which I'm still not
convinced that this is really necessary).

There are two main reasons to keep the compressed encoding:

   1. In the compressed encoding, we can reasonably expect that all / most
   values will be used in practice, so we won't expose any bits on the wire
   that identify a packet as "QUIC traffic" by having a predictable value.
   2. The 1-byte encoding has the disadvantage that an implementation still
   needs to be able to deal with connection ID lengths of 255 bytes, just to
   be able to send Version Negotiation packets. To me, it seems absurd to
   write a QUIC implementation that is able to handle packets with a combined
   connection ID overhead of 510 bytes. Since VNPs are supposed to be sent in
   response to any Long Header packet, you'd have to put some careful thought
   into the design of your data types to avoid this becoming a DoS vector.

On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema <[email-masked]>
wrote:

> the right mix of costs and incentives. Servers who chose to use longer CID
> will get more transmission overhead, and thus transmission less efficiently
> than their competitors. They may chose to use longer CID as a trade-off
> between transmission efficiency and ease of management. Competition will
> sort that out. I note that YouTube is apparently doing fine with smallish
> CID, so I trust that there will be competition.
>
> fixed-size object that can fit the largest CID and eat the overhead for all
> CIDs." But each connection object carries a large number of instances of
> the CID type. Having a very large max CID would imply a large overhead. The
> alternative is to "Make cid_t a variable-size object", but too affects
> performance.
>
>    2) Representation of CID length as a byte is still OK, thus a QUIC v2
> could use longer CIDs as needed by changing the spec while keeping the
> invariants… invariant.
>
>
> *From: *QUIC <[email-masked]> <[email-masked]> on behalf of
> "Lubashev, Igor" <[email-masked]> <[email-masked]>
> *To: *Ian Swett <ianswett=[email-masked]>
> <ianswett=[email-masked]>, Mikkel Fahnøe Jørgensen
> <[email-masked]> <[email-masked]>
> *Cc: *Dmitri Tikhonov <[email-masked]>
> <[email-masked]>, Christian Huitema <[email-masked]>
> <[email-masked]>, "Philipp S. Tiesel" <[email-masked]>
> <[email-masked]>, Mike Bishop <[email-masked]>
> <[email-masked]>, Martin Thomson <[email-masked]>
> <[email-masked]>, Marten Seemann <[email-masked]>
> <[email-masked]>, Lars Eggert <[email-masked]> <[email-masked]>,
> QUIC WG <[email-masked]> <[email-masked]>, Martin Duke
> <[email-masked]> <[email-masked]>, Kazuho Oku
> <[email-masked]> <[email-masked]>
> upper limit of “reasonable” (it should probably be a factor of 8, so 32 or
> 24?).
>
>
>
> territory – a generalized “destination-controlled routing in an overlay
> network”.  This is a very interesting topic, but I would hesitate to
> attempt to solve it fully and “in general” in QUIC v1.
>
>
>
>    - Igor
>
>
>
> <ianswett=[email-masked]>
>
> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahnøe Jørgensen <
> [email-masked]> wrote:
>

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 18 Jun 2019 14:00:26 +0900

> My intuition says making the change to the invariants is the right thing to do, but I don't feel that strongly.

Though I am a bit concerned about the CID length getting ossified,
eventually forcing us going down to a maximum to probably 32 bytes,
unless we permit and see actual use of something longer than that in
v1.

> However, I'd like the max size to be smaller than 48(but larger than 18).  If we think 20 or 24 is sufficient, I'd prefer that.  Kazuho suggested 32, which is better, but I don't believe the server needs to use a separate block cipher when giving out connection IDs, because I believe it's impractical for the load balancer and server to be that decoupled.  The server has to give out a CID that the load balancer will use to route back to the server, so they have to share enough an encryption key/algorithm.

It's great to see discussions pointing to the design variations we
need to support in load balancers. Clarifying the trade-offs is
critical to reaching the right answer.

IIUC, there are three design variations.

Design 1) Load balancer and servers sharing the crypto algorithm and key

Maximum length will be one cipher block size + key identifier, meaning
that the status-quo of 18 bytes is sufficient.
There is no point in selecting a number like 24, because a block
cipher cannot compress only half of a block [1].

Design 2) Server uses it's own CID encryption key, server ID in plaintext

We *might* want to support deployments that do not share cipher keys
between load balancer and the servers.

The simplest design of such a deployment is a load balancer prepending
(or appending) the server ID in plaintext to the server-generated CID
(the server still needs to know it's server ID). This might sound
insecure, but we could argue that exposure of the server ID is
indifferent from the server IP address being exposed in a deployment
that does not use a load balancer.

Under such a design, the maximum length of the CID would be 18 bytes
(governed by each server) + couple of bytes to identify the server.

Design 3)  Server uses it's own CID encryption key, server ID also encrypted

In this design, the maximum length of a CID needs to be 36 bytes (i.e.
2 cipher blocks + key identifier for the server + key identifier for
the load balancer).
Even though the server can use a it's own cipher for encrypting it's
internals in the CID, it still need to aware of the cipher and the key
that the load balancer uses for routing the packets. We could use a
stream cipher to reduce the size for couple of bytes, but the
reduction can never be greater than 7 bytes, and will be much less in
practice [2].

Admittedly, design 3 is no-less simpler than design 1, in sense that
the load balancer and the server need to still share the cipher and
the key. CID of design 1 can have per-server opaque field 64-bit or
more (which on the wire is encrypted using the shared key). Per-server
opaque field of 64-bits would be to store a sequence number for
identifying the connection, and also the server process ID or thread
ID that handles the connection.

Therefore, I think the question regarding the maximum CID length that
we need to support in v1 (and possibly also in invariants) depends on
which of the aforementioned designs we are going to support.

My preference goes to either supporting design 1 only (in case 4-bit
CIDL will be sufficient, and we have the option to bake it into
invariants, the benefit being that there would be no ossification), or
all the three designs. I do not think if there is practical difference
in the maximum being like 24 or like 36.

[1] As Christian has pointed out there are solutions like FFX, but I
am not sure if we would see wide adoption of such mode in load
balancers because it's much slower than block ciphers in ECB mode, and
also because IIUC there is a patent.
[2] See the discussion on Stream CID Cipher Algorithm in
https://github.com/martinduke/draft-duke-quic-load-balancers/blob/master/draft-duke-quic-load-balancers.md

> I can imagine nesting load balancers, but that's well in the range of QUIC v2 from my perspective.
>
> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahnøe Jørgensen <[email-masked]> wrote:
>>

--
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 17 Jun 2019 22:48:29 -0700

While advocating for a short CID (18-24) in v1, I’ll note that privacy of
server ID is not exactly correlated to IP because

1) you could NAT the IP at the router and/or do IPv6 mutations on a block
that you own.
2) you might have a transport other than IP in some network topology,
notably one that uses CID in place of IP (but that would not be v1).

The argument that 24 is not useful because block size, I’m not buying
because you do not have to follow a design where that is important but it
might be worth more than 18 to some.

To Seeman: I think you can separate the concerns on CID size into three
parts: vneg, handshake, and post handshake. So you don’t have to make
special handling of CIDs in general you just need to treat the vneg CID as
something other than a regular CID. I agree that 254 combined CID sounds
excessive, but 640K wasn’t enough either.

Ossification / detection based on 8-bit CID length? I think that is a
concern, but I also think that 18 x 18 in 4-bit pairs will signal: “Hi
cooporate firewall, I am a chrome browser, or something close to that”.

Mikkel

On 18 June 2019 at 07.00.38, Kazuho Oku ([email-masked]) wrote:

to the server, so they have to share enough an encryption key/algorithm.

long way.
>> If CID length negotiation is needed, this could be done via QUIC
versions. For example two functionally equivalent versions, but one with
longer CID’s. This would also allow routers to deal with changes in CID
lengths. A negotiated TP would not (easily) allow for that and aside I do
not think CID length in TP is the way to go.

-- 
Kazuho Oku

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Tue, 18 Jun 2019 10:23:51 +0200

> On 18. Jun 2019, at 05:33, Marten Seemann <[email-masked]> wrote:
> 
> I'd prefer keeping the "compressed 4 bits" solution, even if we decide to increase the connection ID length to a larger value (which I'm still not convinced that this is really necessary).

This would be easy if we change the encoding of the connection ID length, e.g., to be DCIL*4 allowing up to 60 byte connection IDs. While we can not encode one or two byte connection IDs in long header packets, we can still use them in short header packets.

This split between long and short header also allows to use much longer connection IDs after the handshake.
I don’t see much use in it, but it may take off some fear that 24/32/36/48/60 byte connection IDs might not be long enough in the future.

> 	• In the compressed encoding, we can reasonably expect that all / most values will be used in practice, so we won't expose any bits on the wire that identify a packet as "QUIC traffic" by having a predictable value.
> 	• The 1-byte encoding has the disadvantage that an implementation still needs to be able to deal with connection ID lengths of 255 bytes, just to be able to send Version Negotiation packets. To me, it seems absurd to write a QUIC implementation that is able to handle packets with a combined connection ID overhead of 510 bytes. Since VNPs are supposed to be sent in response to any Long Header packet, you'd have to put some careful thought into the design of your data types to avoid this becoming a DoS vector.
> 
> On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema <[email-masked]> wrote:
> I too agree that using one byte in the invariant is preferable to the current "compressed 4 bits" solution.
> 
> Regarding the "CID length limit", I thing there are two issues: transmission overhead, and costs to the community.
> 
> I am not too concerned with the transmission overhead, as we have there the right mix of costs and incentives. Servers who chose to use longer CID will get more transmission overhead, and thus transmission less efficiently than their competitors. They may chose to use longer CID as a trade-off between transmission efficiency and ease of management. Competition will sort that out. I note that YouTube is apparently doing fine with smallish CID, so I trust that there will be competition.
> 
> I am much more concerned with the shared costs, which are a variation of the "tragedy of the commons". Dmitry explained those costs well in a previous message. The simpler implementation is to make the "cid_t a fixed-size object that can fit the largest CID and eat the overhead for all CIDs." But each connection object carries a large number of instances of the CID type. Having a very large max CID would imply a large overhead. The alternative is to "Make cid_t a variable-size object", but too affects performance.
> 
> Hence the push-back. I would personally prefer a max size of 16, and I think that 32 is the highest practical limit.
> 
> -- Christian Huitema
> 
>> 	• Igor

AVE!
   Philipp S. Tiesel

---

From: Martin Duke <[email-masked]>
Date: Wed, 19 Jun 2019 21:43:10 -0700

so do I hear consensus emerging around 32B in v1, or should I leave the 18B
limit in v1 for now and punt out that discussion?

On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel <[email-masked]>
wrote:

> > I'd prefer keeping the "compressed 4 bits" solution, even if we decide
> to increase the connection ID length to a larger value (which I'm still not
> This would be easy if we change the encoding of the connection ID length,
> e.g., to be DCIL*4 allowing up to 60 byte connection IDs. While we can not
> encode one or two byte connection IDs in long header packets, we can still
> use them in short header packets.
>
> I don’t see much use in it, but it may take off some fear that
> 24/32/36/48/60 byte connection IDs might not be long enough in the future.
>
> >
> >       • In the compressed encoding, we can reasonably expect that all /
> most values will be used in practice, so we won't expose any bits on the
> wire that identify a packet as "QUIC traffic" by having a predictable value.
> >       • The 1-byte encoding has the disadvantage that an implementation
> still needs to be able to deal with connection ID lengths of 255 bytes,
> just to be able to send Version Negotiation packets. To me, it seems absurd
> to write a QUIC implementation that is able to handle packets with a
> combined connection ID overhead of 510 bytes. Since VNPs are supposed to be
> sent in response to any Long Header packet, you'd have to put some careful
> thought into the design of your data types to avoid this becoming a DoS
> vector.
> >
> v2 could use longer CIDs as needed by changing the spec while keeping the
> invariants… invariant.
> >>
> >>
> >> Cc: Dmitri Tikhonov <[email-masked]>, Christian Huitema <
> [email-masked]>, "Philipp S. Tiesel" <[email-masked]>, Mike
> Bishop <[email-masked]>, Martin Thomson <[email-masked]>, Marten
> Seemann <[email-masked]>, Lars Eggert <[email-masked]>, QUIC WG
> <[email-masked]>, Martin Duke <[email-masked]>, Kazuho Oku <
> [email-masked]>
> suggested 32, which is better, but I don't believe the server needs to use
> a separate block cipher when giving out connection IDs, because I believe
> it's impractical for the load balancer and server to be that decoupled.
> The server has to give out a CID that the load balancer will use to route
> back to the server, so they have to share enough an encryption
> key/algorithm.  I can imagine nesting load balancers, but that's well in
> the range of QUIC v2 from my perspective.
> >>
> >>
> >>
>                    longer CID’s. This would also allow routers to deal with
> changes in CID lengths. A negotiated TP would not (easily) allow for that
> and aside I do not think CID length in TP is the way to go.
> >>
> >>
> >>
> >> Mikkel
> >>
> >>
> >>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 20 Jun 2019 11:57:07 -0700

That seems a little high.  I think that Ian's principle here is what should guide us: what is the minimum you can handle?  What I've heard is that 18 might have been workable, but it was REALLY close to the edge to the point that you weren't confident it was enough, even in the near term.  But that suggests that 20 is workable.

On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote:
> so do I hear consensus emerging around 32B in v1, or should I leave the 
> 18B limit in v1 for now and punt out that discussion?
> 
> On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel <[email-masked]> wrote:
> > 
> > 
> >  This would be easy if we change the encoding of the connection ID length, e..g., to be DCIL*4 allowing up to 60 byte connection IDs. While we can not encode one or two byte connection IDs in long header packets, we can still use them in short header packets.
> > 
> >  >> Cc: Dmitri Tikhonov <[email-masked]>, Christian Huitema <[email-masked]>, "Philipp S. Tiesel" <[email-masked]>, Mike Bishop <[email-masked]>, Martin Thomson <[email-masked]>, Marten Seemann <[email-masked]>, Lars Eggert <[email-masked]>, QUIC WG <[email-masked]>, Martin Duke <[email-masked] <mailto:[email-masked]>>, Kazuho Oku <[email-masked]>

---

From: Ian Swett <[email-masked]>
Date: Fri, 21 Jun 2019 16:00:12 -0400

I think the 3 options I see as well reasoned are:
1) Keep the status quo because we think we can put what we really need into
18 bytes if we try.
2) Change to a 1 byte length per CID and a max of 20, which gives us a few
extra bytes for cleartext server id and/or key rotation/etc.
3) Change to a 1 byte length per CID and a max of 36, because we want be
able to put 2 encrypted routing IDs in a single CID.

2 is my preferred option, though I can live with either of 1 or 3.

Deciding sooner would be strictly better than later, since this is blocking
us(Chrome/Google) actually supporting varlen CIDs.

On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson <[email-masked]> wrote:

> That seems a little high.  I think that Ian's principle here is what
> should guide us: what is the minimum you can handle?  What I've heard is
> that 18 might have been workable, but it was REALLY close to the edge to
> the point that you weren't confident it was enough, even in the near
> term..  But that suggests that 20 is workable.
>
> > >  > I'd prefer keeping the "compressed 4 bits" solution, even if we
> decide to increase the connection ID length to a larger value (which I'm
> still not convinced that this is really necessary).
> > >
> > >  This would be easy if we change the encoding of the connection ID
> length, e..g., to be DCIL*4 allowing up to 60 byte connection IDs. While we
> can not encode one or two byte connection IDs in long header packets, we
> can still use them in short header packets.
> > >
> > >  This split between long and short header also allows to use much
> longer connection IDs after the handshake.
> > >  > I too agree that using one byte in the invariant is preferable to
> the current "compressed 4 bits" solution.
> > >  >
> > >  > I am not too concerned with the transmission overhead, as we have
> there the right mix of costs and incentives. Servers who chose to use
> longer CID will get more transmission overhead, and thus transmission less
> efficiently than their competitors. They may chose to use longer CID as a
> trade-off between transmission efficiency and ease of management.
> > >  > I am much more concerned with the shared costs, which are a
> variation of the "tragedy of the commons". Dmitry explained those costs
> well in a previous message. The simpler implementation is to make the
> "cid_t a fixed-size object that can fit the largest CID and eat the
> overhead for all CIDs." But each connection object carries a large number
> of instances of the CID type. Having a very large max CID would imply a
> large overhead. The alternative is to "Make cid_t a variable-size object",
> but too affects performance.
> > >  >
> > >  > Hence the push-back. I would personally prefer a max size of 16,
> and I think that 32 is the highest practical limit.
> > >  >
> > >  > -- Christian Huitema
> > >  >
> > >  >> Cc: Dmitri Tikhonov <[email-masked]>, Christian
> Huitema <[email-masked]>, "Philipp S. Tiesel" <[email-masked]>,
> Mike Bishop <[email-masked]>, Martin Thomson <[email-masked]>,
> Marten Seemann <[email-masked]>, Lars Eggert <[email-masked]>,
> QUIC WG <[email-masked]>, Martin Duke <[email-masked] <mailto:
> [email-masked]>>, Kazuho Oku <[email-masked]>
> > >  >> My take is similar – 48 is probably excessive, while 32 is likely
> the upper limit of “reasonable” (it should probably be a factor of 8, so 32
> or 24?).
> > >  >>
> > >  >>
> > >  >>
> > >  >> We are firmly committed for using CID for in-cluster load
> balancing / anycast pop routing. This discussion is taking us, however, to
> a new territory – a generalized “destination-controlled routing in an
> overlay network”. This is a very interesting topic, but I would hesitate to
> > >  >> However, I'd like the max size to be smaller than 48(but larger
> than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho
> it's impractical for the load balancer and server to be that decoupled. The
> It’s not like we are not looking for excuses to upgrade QUIC versions soon.
> > >  >>
> > >  >>
> > >  >>

---

From: David Schinazi <[email-masked]>
Date: Fri, 21 Jun 2019 13:02:14 -0700

+1 to what Ian said. (2) seems like a good path forward

On Fri, Jun 21, 2019 at 1:00 PM Ian Swett <ianswett=
[email-masked]> wrote:

> 1) Keep the status quo because we think we can put what we really need
> into 18 bytes if we try.
> Deciding sooner would be strictly better than later, since this is
> blocking us(Chrome/Google) actually supporting varlen CIDs.
>
>> > >  >> 2) Representation of CID length as a byte is still OK, thus a
>> QUIC v2 could use longer CIDs as needed by changing the spec while keeping
>> > >  >> From: QUIC <[email-masked] <quic-bounces@ietf..org>> on
>> behalf of "Lubashev, Igor" <[email-masked]>
>> > >  >> My intuition says making the change to the invariants is the
>> right thing to do, but I don't feel that strongly.
>> > >  >>
>> > >  >>
>> > >  >>
>> > >  >> I do think the invariants should allow for long CID’s as
>> proposed, and that the long header overhead is not important..
>> > >  >>
>> > >  >>
>> > >  >>
>> > >  >> But for QUIC v1, if we allow for a long CID, a rush to market
>> will set precedence and long CID’s will ossify in all kinds of stacks.
>> > >  >>
>> > >  >>
>> > >  >>
>> > >  >> If CID length 18 turns out to be not enough, we can add a QUIC
>> v2. It’s not like we are not looking for excuses to upgrade QUIC versions
>> soon.
>> > >  >>
>> > >  >>
>> > >  >>

---

From: Roberto Peon <[email-masked]>
Date: Fri, 21 Jun 2019 20:21:24 +0000

Works for me.
-=R

From: QUIC <[email-masked]> on behalf of David Schinazi <[email-masked]>
Date: Friday, June 21, 2019 at 1:02 PM
To: Ian Swett <ianswett=[email-masked]>
Cc: IETF QUIC WG <[email-masked]>, Martin Thomson <[email-masked]>
Subject: Re: Consensus Call: More Connection ID Space #2736

On Fri, Jun 21, 2019 at 1:00 PM Ian Swett <ianswett=[email-masked]<mailto:[email-masked]>> wrote:
I think the 3 options I see as well reasoned are:
1) Keep the status quo because we think we can put what we really need into 18 bytes if we try.
2) Change to a 1 byte length per CID and a max of 20, which gives us a few extra bytes for cleartext server id and/or key rotation/etc.
3) Change to a 1 byte length per CID and a max of 36, because we want be able to put 2 encrypted routing IDs in a single CID.

Deciding sooner would be strictly better than later, since this is blocking us(Chrome/Google) actually supporting varlen CIDs.

On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
That seems a little high.  I think that Ian's principle here is what should guide us: what is the minimum you can handle?  What I've heard is that 18 might have been workable, but it was REALLY close to the edge to the point that you weren't confident it was enough, even in the near term..  But that suggests that 20 is workable.

On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote:
> On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel <[email-masked]<mailto:[email-masked]>> wrote:
> >
> >
> >  > On 18. Jun 2019, at 05:33, Marten Seemann <[email-masked]<mailto:[email-masked]>> wrote:
> >  >
> >  > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema <[email-masked]<mailto:[email-masked]>> wrote:
> >  >> From: QUIC <[email-masked]<mailto:quic-bounces@ietf...org>> on behalf of "Lubashev, Igor" <[email-masked]<mailto:[email-masked]>>
> >  >> To: Ian Swett <ianswett=[email-masked]<mailto:[email-masked]>>, Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>>
> >  >> Cc: Dmitri Tikhonov <[email-masked]<mailto:[email-masked]>>, Christian Huitema <[email-masked]<mailto:[email-masked]>>, "Philipp S. Tiesel" <[email-masked]<mailto:[email-masked]>>, Mike Bishop <[email-masked]<mailto:[email-masked]>>, Martin Thomson <[email-masked]<mailto:[email-masked]>>, Marten Seemann <[email-masked]<mailto:[email-masked]>>, Lars Eggert <[email-masked]<mailto:[email-masked]>>, QUIC WG <[email-masked]<mailto:[email-masked]>>, Martin Duke <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>, Kazuho Oku <[email-masked]<mailto:[email-masked]>>
> >  >> From: Ian Swett <ianswett=[email-masked]<mailto:[email-masked]>>
> >  >>
> >  >> I do think the invariants should allow for long CID’s as proposed, and that the long header overhead is not important...
> >  >>
> >  >>
> >  >>
> > https://philipp.tiesel.net/<https://urldefense.proofpoint.com/v2/url?u=https-3A__philipp.tiesel.net_&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=3--Vf83yuUSuLtI4x2enWT3utSWzurQvDZDTi_7tJzc&s=0Erh4D6mKkKkDC-EscmM2IZ-j5OzrQ8nj-buq3qKa4o&e=>
> >

---

From: Nick Banks <[email-masked]>
Date: Fri, 21 Jun 2019 20:23:09 +0000

Works for me as well.

- Nick

From: QUIC <[email-masked]> On Behalf Of Roberto Peon
Sent: Friday, June 21, 2019 1:21 PM
To: David Schinazi <[email-masked]>; Ian Swett <ianswett=[email-masked]>
Cc: IETF QUIC WG <[email-masked]>; Martin Thomson <[email-masked]>
Subject: Re: Consensus Call: More Connection ID Space #2736

Works for me.
-=R

From: QUIC <[email-masked]<mailto:[email-masked]>> on behalf of David Schinazi <[email-masked]<mailto:[email-masked]>>
Date: Friday, June 21, 2019 at 1:02 PM
To: Ian Swett <ianswett=[email-masked]<mailto:ianswett=[email-masked]>>
Cc: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>, Martin Thomson <[email-masked]<mailto:[email-masked]>>
Subject: Re: Consensus Call: More Connection ID Space #2736

On Wed, Jun 19, 2019, at 21:43, Martin Duke wrote:
> > https://philipp.tiesel.net/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__philipp.tiesel.net_%26d%3DDwMFaQ%26c%3D5VD0RTtNlTh3ycd41b3MUw%26r%3DC0sUo-LFNBaYfyoaCsf6TA%26m%3D3--Vf83yuUSuLtI4x2enWT3utSWzurQvDZDTi_7tJzc%26s%3D0Erh4D6mKkKkDC-EscmM2IZ-j5OzrQ8nj-buq3qKa4o%26e%3D&data=02%7C01%7Cnibanks%40microsoft.com%7C13fae929f43247961aaa08d6f6861588%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636967453105229825&sdata=Bl1ADptyoSBSyROMG6u0G9DQ80NiuIWuexp0quJtNtw%3D&reserved=0>
> >

---

From: Eric Kinnear <[email-masked]>
Date: Fri, 21 Jun 2019 13:24:16 -0700

(2) would be fine for me!

Thanks,
Eric

> On Jun 21, 2019, at 1:23 PM, Nick Banks <nibanks=[email-masked]> wrote:
> 
> Works for me as well.
>  
> - Nick
>  
> From: QUIC <[email-masked] <mailto:[email-masked]>> on behalf of David Schinazi <[email-masked] <mailto:[email-masked]>>
> To: Ian Swett <ianswett=[email-masked] <mailto:ianswett=[email-masked]>>
> Cc: IETF QUIC WG <[email-masked] <mailto:[email-masked]>>, Martin Thomson <[email-masked] <mailto:[email-masked]>>
> On Fri, Jun 21, 2019 at 1:00 PM Ian Swett <ianswett=[email-masked] <mailto:[email-masked]>> wrote:
> On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> > On Tue, Jun 18, 2019 at 1:24 AM Philipp S. Tiesel <[email-masked] <mailto:[email-masked]>> wrote:
> > > 
> > > 
> > >  > On 18. Jun 2019, at 05:33, Marten Seemann <[email-masked] <mailto:[email-masked]>> wrote:
> > >  > 
> > >  > On Tue, Jun 18, 2019 at 3:50 AM Christian Huitema <[email-masked] <mailto:[email-masked]>> wrote:
> > >  >> From: QUIC <[email-masked] <mailto:quic-bounces@ietf...org>> on behalf of "Lubashev, Igor" <[email-masked] <mailto:[email-masked]>>
> > >  >> To: Ian Swett <ianswett=[email-masked] <mailto:[email-masked]>>, Mikkel Fahnøe Jørgensen <[email-masked] <mailto:[email-masked]>>
> > >  >> Cc: Dmitri Tikhonov <[email-masked] <mailto:[email-masked]>>, Christian Huitema <[email-masked] <mailto:[email-masked]>>, "Philipp S. Tiesel" <[email-masked] <mailto:[email-masked]>>, Mike Bishop <[email-masked] <mailto:[email-masked]>>, Martin Thomson <[email-masked] <mailto:[email-masked]>>, Marten Seemann <[email-masked] <mailto:[email-masked]>>, Lars Eggert <[email-masked] <mailto:[email-masked]>>, QUIC WG <[email-masked] <mailto:[email-masked]>>, Martin Duke <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, Kazuho Oku <[email-masked] <mailto:[email-masked]>>
> > >  >> From: Ian Swett <ianswett=[email-masked] <mailto:[email-masked]>>
> > >  >> 
> > >  >> On Mon, Jun 17, 2019 at 2:51 AM Mikkel Fahnøe Jørgensen <[email-masked] <mailto:[email-masked]>> wrote:
> > >  >> 
> > >  >> On 17 June 2019 at 06.45.04, Kazuho Oku ([email-masked] <mailto:[email-masked]>) wrote:
> > >  >> 
> > >  >> 2019年6月17日(月) 11:09 Christian Huitema <[email-masked] <mailto:[email-masked]>>: 
> > >  >> > 
> > > https://philipp.tiesel.net/ <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__philipp.tiesel.net_%26d%3DDwMFaQ%26c%3D5VD0RTtNlTh3ycd41b3MUw%26r%3DC0sUo-LFNBaYfyoaCsf6TA%26m%3D3--Vf83yuUSuLtI4x2enWT3utSWzurQvDZDTi_7tJzc%26s%3D0Erh4D6mKkKkDC-EscmM2IZ-j5OzrQ8nj-buq3qKa4o%26e%3D&data=02%7C01%7Cnibanks%40microsoft.com%7C13fae929f43247961aaa08d6f6861588%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636967453105229825&sdata=Bl1ADptyoSBSyROMG6u0G9DQ80NiuIWuexp0quJtNtw%3D&reserved=0>
> > >
>

---

From: Christian Huitema <[email-masked]>
Date: Fri, 21 Jun 2019 14:32:19 -0700

Me too. 2.

-- Christian Huitema 

> On Jun 21, 2019, at 1:24 PM, Eric Kinnear <ekinnear=[email-masked]> wrote:
> 
>> On Fri, Jun 21, 2019 at 1:00 PM Ian Swett <ianswett=[email-masked]> wrote:
>> > >  >> Cc: Dmitri Tikhonov <[email-masked]>, Christian Huitema <[email-masked]>, "Philipp S. Tiesel" <[email-masked]>, Mike Bishop <[email-masked]>, Martin Thomson <[email-masked]>, Marten Seemann <[email-masked]>, Lars Eggert <[email-masked]>, QUIC WG <[email-masked]>, Martin Duke <[email-masked]<mailto:[email-masked]>>, Kazuho Oku <[email-masked]>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 21 Jun 2019 16:17:05 -0700

Makes sense 2 me 2

On 21 June 2019 at 23.42.48, Christian Huitema ([email-masked]) wrote:

Me too. 2.

-- Christian Huitema

On Jun 21, 2019, at 1:24 PM, Eric Kinnear <
ekinnear=[email-masked]> wrote:

Thanks,
Eric

On Jun 21, 2019, at 1:23 PM, Nick Banks <
nibanks=[email-masked]> wrote:

Works for me as well.

- Nick

*From:* QUIC <[email-masked]> *On Behalf Of *Roberto Peon
*Sent:* Friday, June 21, 2019 1:21 PM
*To:* David Schinazi <[email-masked]>; Ian Swett <
ianswett=40google.com@dmarc..ietf.org <ianswett=[email-masked]>
*Cc:* IETF QUIC WG <[email-masked]>; Martin Thomson <[email-masked]>
*Subject:* Re: Consensus Call: More Connection ID Space #2736

Works for me.
-=R

*From: *QUIC <[email-masked]> on behalf of David Schinazi <
[email-masked]>
*Date: *Friday, June 21, 2019 at 1:02 PM
*To: *Ian Swett <ianswett=[email-masked]>
*Cc: *IETF QUIC WG <[email-masked]>, Martin Thomson <[email-masked]>
*Subject: *Re: Consensus Call: More Connection ID Space #2736

That seems a little high.  I think that Ian's principle here is what should
guide us: what is the minimum you can handle?  What I've heard is that 18
might have been workable, but it was REALLY close to the edge to the point
that you weren't confident it was enough, even in the near term..  But that
suggests that 20 is workable.

> >  This would be easy if we change the encoding of the connection ID
length, e..g.., to be DCIL*4 allowing up to 60 byte connection IDs. While
we can not encode one or two byte connection IDs in long header packets, we
can still use them in short header packets.
> >  >
> >  > Hence the push-back. I would personally prefer a max size of 16, and
I think that 32 is the highest practical limit.
> >  >> From: QUIC <[email-masked] <quic-bounces@ietf...org>> on
Huitema <[email-masked]>, "Philipp S. Tiesel" <[email-masked]>,
Mike Bishop <[email-masked]>, Martin Thomson <[email-masked]>,
Marten Seemann <[email-masked]>, Lars Eggert <[email-masked]>,
QUIC WG <[email-masked]>, Martin Duke <[email-masked]<mailto:
[email-masked]>>, Kazuho Oku <[email-masked]
<kazuhooku@gmail..com>>
> >  >>
> >  >>
> >  >>
> >  >> We are firmly committed for using CID for in-cluster load balancing
/ anycast pop routing. This discussion is taking us, however, to a new
territory – a generalized “destination-controlled routing in an overlay
network”. This is a very interesting topic, but I would hesitate to attempt
to solve it fully and “in general” in QUIC v1.
> >  >> My intuition says making the change to the invariants is the right
thing to do, but I don't feel that strongly..
> >  >> I do think the invariants should allow for long CID’s as proposed,
and that the long header overhead is not important...

> >  Philipp S. Tiesel
<https://nam06.safelinks.protection..outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__philipp.tiesel.net_%26d%3DDwMFaQ%26c%3D5VD0RTtNlTh3ycd41b3MUw%26r%3DC0sUo-LFNBaYfyoaCsf6TA%26m%3D3--Vf83yuUSuLtI4x2enWT3utSWzurQvDZDTi_7tJzc%26s%3D0Erh4D6mKkKkDC-EscmM2IZ-j5OzrQ8nj-buq3qKa4o%26e%3D&data=02%7C01%7Cnibanks%40microsoft.com%7C13fae929f43247961aaa08d6f6861588%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636967453105229825&sdata=Bl1ADptyoSBSyROMG6u0G9DQ80NiuIWuexp0quJtNtw%3D&reserved=0>

---

From: Marten Seemann <[email-masked]>
Date: Sat, 22 Jun 2019 07:50:59 +0800

There’s also a 4th option:
4) Keep the 4 bit compressed encoding and increase the maximum length to 20
bytes.

This could be done by eliminating code points for 15 and 17 byte connection
IDs (or any other 2 code points that seem less useful).
I’d prefer that option because of the ossification risks described earlier.

On Sat, Jun 22, 2019 at 07:17 Mikkel Fahnøe Jørgensen <[email-masked]>
wrote:

> ianswett=40google.com@dmarc..ietf.org
> <ianswett=[email-masked]>>
> > >  >> From: QUIC <[email-masked] <quic-bounces@ietf....org>> on
> <https://nam06.safelinks.protection..outlook.com/?url=https%3A%2F%2Furldefense..proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__philipp.tiesel.net_%26d%3DDwMFaQ%26c%3D5VD0RTtNlTh3ycd41b3MUw%26r%3DC0sUo-LFNBaYfyoaCsf6TA%26m%3D3--Vf83yuUSuLtI4x2enWT3utSWzurQvDZDTi_7tJzc%26s%3D0Erh4D6mKkKkDC-EscmM2IZ-j5OzrQ8nj-buq3qKa4o%26e%3D&data=02%7C01%7Cnibanks%40microsoft.com%7C13fae929f43247961aaa08d6f6861588%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636967453105229825&sdata=Bl1ADptyoSBSyROMG6u0G9DQ80NiuIWuexp0quJtNtw%3D&reserved=0>
> > >
>
>
>

---

From: David Schinazi <[email-masked]>
Date: Fri, 21 Jun 2019 16:52:58 -0700

I’m strongly opposed to option 4. It guarantees ossification by not
allowing other lengths from the get go so it’s strictly less future-proof
than option 2.

On Fri, Jun 21, 2019 at 16:51 Marten Seemann <[email-masked]>
wrote:

> 4) Keep the 4 bit compressed encoding and increase the maximum length to
> 20 bytes.
>
> This could be done by eliminating code points for 15 and 17 byte
> connection IDs (or any other 2 code points that seem less useful).
>> 2) Change to a 1 byte length per CID and a max of 20, which gives us a
>> few extra bytes for cleartext server id and/or key rotation/etc.
>> right thing to do, but I don't feel that strongly..
>> > >  >>
>> > >  >>
>> > >  >>
>> proposed, and that the long header overhead is not important...
>> > >  >>
>> > >  >>
>> > >  >>

---

From: Marten Seemann <[email-masked]>
Date: Sat, 22 Jun 2019 08:19:36 +0800

Ossification is prevented by actually using all available code points. With
the compressed 4 bit encoding, there's a good chance that actually all
connection ID lengths will be used by at least some QUIC implementations,
so there's minimal risk of ossification. However, with options 2, we use a
whole byte to encode just 20 values, resulting in the first 3 bits always
being 0 (in v1) - an easy target for ossification.

The biggest downside of the 1 byte connection ID length encoding is how you
handle unknown versions. Since an implementation must be able to send
Version Negotiation packets, and a future QUIC version could increase the
connection ID length limit to 255 bytes, option 2 and 3 will require you to
have data types that allow parsing of packets with connection IDs that are
a quarter of a kilobyte long. You wouldn't want to use fixed-sized buffers
for that, and maybe even end up with different connection ID types for
short and long header packets.

Option 2 therefore gives us the worst of both worlds: We gain very little
in actually available connection ID space, but bear the full cost of
implementational complexity for handling packets with 255 byte connection
IDs.

On Sat, Jun 22, 2019 at 7:53 AM David Schinazi <[email-masked]>
wrote:

>>> > >  >> From: QUIC <[email-masked] <quic-bounces@ietf....org>>
>>> on behalf of "Lubashev, Igor" <[email-masked]>
>>> > >  >> My take is similar – 48 is probably excessive, while 32 is
>>> likely the upper limit of “reasonable” (it should probably be a factor of
>>> 8, so 32 or 24?).
>>> > >  >>
>>> > >  >>
>>> > >  >>

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 22 Jun 2019 10:37:31 +0900

2019年6月22日(土) 9:20 Marten Seemann <[email-masked]>:
>
> Ossification is prevented by actually using all available code points. With the compressed 4 bit encoding, there's a good chance that actually all connection ID lengths will be used by at least some QUIC implementations, so there's minimal risk of ossification. However, with options 2, we use a whole byte to encode just 20 values, resulting in the first 3 bits always being 0 (in v1) - an easy target for ossification.
>
> The biggest downside of the 1 byte connection ID length encoding is how you handle unknown versions. Since an implementation must be able to send Version Negotiation packets, and a future QUIC version could increase the connection ID length limit to 255 bytes, option 2 and 3 will require you to have data types that allow parsing of packets with connection IDs that are a quarter of a kilobyte long. You wouldn't want to use fixed-sized buffers for that, and maybe even end up with different connection ID types for short and long header packets.
>
> Option 2 therefore gives us the worst of both worlds: We gain very little in actually available connection ID space, but bear the full cost of implementational complexity for handling packets with 255 byte connection IDs.

While I am not generally opposed to option 2 (I do not think it is
*that* bad to argue against reaching consensus), I agree that is a
concern.

And actually, I think there is a beautiful way of encoding CID length
in 5 bits: combine the first octet and the CIDL octet that we have now
into a uint16_t, and use 5 * 2 bits of that 16-bit field to represent
the CID lengths. As a coincidence, we have two unused bits in the long
header fields of QUIC v1 (with the exception of Retry [1]). This
change would remove those unused bits (and the need for handling them
correctly). So it simplifies v1.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|T T|X X| DCIDL(5)| SCIDL(5)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Version (32)                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Destination Connection ID (0/32..272)         ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Source Connection ID (0/32..272)            ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[1] Retry uses the four bits of the first octet to carry ODCIDL. We
would need to use a dedicated octet for carrying ODCIDL if we decide
mo make CIDL longer than 4 bits.

>
> On Sat, Jun 22, 2019 at 7:53 AM David Schinazi <[email-masked]> wrote:
>>
>> I’m strongly opposed to option 4. It guarantees ossification by not allowing other lengths from the get go so it’s strictly less future-proof than option 2.
>>
>> On Fri, Jun 21, 2019 at 16:51 Marten Seemann <[email-masked]> wrote:
>>>
>>> 4) Keep the 4 bit compressed encoding and increase the maximum length to 20 bytes.
>>>
>>> This could be done by eliminating code points for 15 and 17 byte connection IDs (or any other 2 code points that seem less useful).
>>> On Sat, Jun 22, 2019 at 07:17 Mikkel Fahnøe Jørgensen <[email-masked]> wrote:
>>>>
>>>> Makes sense 2 me 2
>>>>
>>>>
>>>> To: David Schinazi <[email-masked]>; Ian Swett <ianswett=40google.com@dmarc..ietf.org>
>>>> To: Ian Swett <ianswett=40google.com@dmarc..ietf.org>
>>>> > >  This would be easy if we change the encoding of the connection ID length, e..g.., to be DCIL*4 allowing up to 60 byte connection IDs. While we can not encode one or two byte connection IDs in long header packets, we can still use them in short header packets.
>>>> > >
>>>> > >  >> Cc: Dmitri Tikhonov <[email-masked]>, Christian Huitema <[email-masked]>, "Philipp S. Tiesel" <[email-masked]>, Mike Bishop <[email-masked]>, Martin Thomson <[email-masked]>, Marten Seemann <[email-masked]>, Lars Eggert <lars@eggert..org>, QUIC WG <[email-masked]>, Martin Duke <[email-masked]<mailto:[email-masked]>>, Kazuho Oku <[email-masked]>
>>>> > >  >> My intuition says making the change to the invariants is the right thing to do, but I don't feel that strongly..
>>>> > >  >>
>>>> > >  >>
>>>> > >  >>

-- 
Kazuho Oku

---

From: "Lubashev, Igor" <[email-masked]>
Date: Sat, 22 Jun 2019 02:00:15 +0000

I am first to appreciate clever bit hacks, but in this case,  I disagree with the wisdom of doing so.

In fear of some middlebox vendor ossifying the protocol, we should not be working hard to ossify it ourselves by removing reserved bits and making it impossible to grow CID length in the future.

I am a bit surprised by the amount of concern about having to deal with CID of up to 255 bytes for version negotiation.  How hard is it to:

	memcpy(vn_pkt_ptr, ci_pkt->scid, ci_pkt->scid_len);
	vn_pkt_ptr += ci_pkt->scid_len;
	memcpy(vn_pkt_ptr, ci_pkt->dcid, ci_pkt->dcid_len);
	vn_pkt_ptr += ci_pkt->dcid_len;

My lot is with Option 2.  Do not require v1 to handle huge CIDs but also do not paint yourself into a corner in Invariants.

- Igor

> From: Kazuho Oku <[email-masked]>
> 
> > Ossification is prevented by actually using all available code points. With the
> compressed 4 bit encoding, there's a good chance that actually all connection
> ID lengths will be used by at least some QUIC implementations, so there's
> minimal risk of ossification. However, with options 2, we use a whole byte to
> encode just 20 values, resulting in the first 3 bits always being 0 (in v1) - an
> easy target for ossification.
> >
> > The biggest downside of the 1 byte connection ID length encoding is how
> you handle unknown versions. Since an implementation must be able to
> send Version Negotiation packets, and a future QUIC version could increase
> the connection ID length limit to 255 bytes, option 2 and 3 will require you to
> have data types that allow parsing of packets with connection IDs that are a
> quarter of a kilobyte long. You wouldn't want to use fixed-sized buffers for
> that, and maybe even end up with different connection ID types for short
> and long header packets.
> >
> > Option 2 therefore gives us the worst of both worlds: We gain very little in
> actually available connection ID space, but bear the full cost of
> *that* bad to argue against reaching consensus), I agree that is a concern.
> 
> And actually, I think there is a beautiful way of encoding CID length in 5 bits:
> combine the first octet and the CIDL octet that we have now into a uint16_t,
> and use 5 * 2 bits of that 16-bit field to represent the CID lengths. As a
> coincidence, we have two unused bits in the long header fields of QUIC v1
> (with the exception of Retry [1]). This change would remove those unused
> bits (and the need for handling them correctly). So it simplifies v1.
> 
>  0                   1                   2                   3
> [1] Retry uses the four bits of the first octet to carry ODCIDL. We would need
> to use a dedicated octet for carrying ODCIDL if we decide mo make CIDL
> longer than 4 bits.
> 
> >
> allowing other lengths from the get go so it’s strictly less future-proof than
> option 2.
> >>
> >>>> On Jun 21, 2019, at 1:24 PM, Eric Kinnear
> <ekinnear=[email-masked]> wrote:
> >>>>
> >>>> On Jun 21, 2019, at 1:23 PM, Nick Banks
> <nibanks=[email-masked]> wrote:
> >>>>
> >>>> Works for me as well.
> >>>>
> >>>> - Nick
> >>>>
> >>>> On Fri, Jun 21, 2019 at 1:00 PM Ian Swett
> <ianswett=[email-masked]> wrote:
> >>>>
> >>>> 3) Change to a 1 byte length per CID and a max of 36, because we want
> be able to put 2 encrypted routing IDs in a single CID.
> >>>>
> >>>> > so do I hear consensus emerging around 32B in v1, or should I
> >>>> > leave the 18B limit in v1 for now and punt out that discussion?
> >>>> >
> decide to increase the connection ID length to a larger value (which I'm still
> not convinced that this is really necessary).
> >>>> > >
> length, e..g.., to be DCIL*4 allowing up to 60 byte connection IDs. While we
> >>>> > >  > • In the compressed encoding, we can reasonably expect that all
> / most values will be used in practice, so we won't expose any bits on the
> >>>> > >  > • The 1-byte encoding has the disadvantage that an
> implementation still needs to be able to deal with connection ID lengths of
> 255 bytes, just to be able to send Version Negotiation packets. To me, it
> seems absurd to write a QUIC implementation that is able to handle packets
> with a combined connection ID overhead of 510 bytes. Since VNPs are
> supposed to be sent in response to any Long Header packet, you'd have to
> put some careful thought into the design of your data types to avoid this
> becoming a DoS vector.
> >>>> > >  >
> >>>> > >  > I am not too concerned with the transmission overhead, as we
> have there the right mix of costs and incentives. Servers who chose to use
> Competition will sort that out. I note that YouTube is apparently doing fine
> with smallish CID, so I trust that there will be competition.
> >>>> > >  >
> variation of the "tragedy of the commons". Dmitry explained those costs well
> in a previous message. The simpler implementation is to make the "cid_t a
> CIDs." But each connection object carries a large number of instances of the
> CID type. Having a very large max CID would imply a large overhead. The
> >>>> > >  >> 1) QUIC v1 would limit CID length to something one of {32,
> >>>> > > 36, or 48}  >>  >> 2) Representation of CID length as a byte is
> >>>> > > still OK, thus a QUIC v2 could use longer CIDs as needed by changing
> the spec while keeping the invariants… invariant.
> >>>> > >  >>
> >>>> > >  >>
> >>>> > >  >> From: QUIC <[email-masked]> on behalf of "Lubashev,
> >>>> > > Igor" <[email-masked]>  >> Date: Monday, June 17, 2019 at
> >>>> > > 8:55 AM  >> To: Ian Swett
> >>>> > > <[email-masked]>  >> Cc: Dmitri Tikhonov
> >>>> > > <[email-masked]>, Christian Huitema
> >>>> > > <[email-masked]>, "Philipp S. Tiesel"
> >>>> > > <[email-masked]>, Mike Bishop <[email-masked]>,
> >>>> > > Martin Thomson <[email-masked]>, Marten Seemann
> <[email-masked]>, Lars Eggert <lars@eggert..org>, QUIC WG
> <[email-masked]>, Martin Duke
> <[email-masked]<mailto:[email-masked]>>, Kazuho
> Oku <[email-masked]>  >> Subject: RE: Consensus Call: More
> Connection ID Space #2736  >>  >>  >>  >> My take is similar – 48 is probably
> excessive, while 32 is likely the upper limit of “reasonable” (it should
> probably be a factor of 8, so 32 or 24?).
> >>>> > >  >>
> >>>> > >  >>
> >>>> > >  >>
> balancing / anycast pop routing. This discussion is taking us, however, to a
> new territory – a generalized “destination-controlled routing in an overlay
> network”. This is a very interesting topic, but I would hesitate to attempt to
> solve it fully and “in general” in QUIC v1.
> >>>> > >  >>
> >>>> > >  >>
> >>>> > >  >>
> >>>> > >  >> • Igor
> >>>> > >  >>
> >>>> > >  >>
> than 18). If we think 20 or 24 is sufficient, I'd prefer that. Kazuho suggested
> 32, which is better, but I don't believe the server needs to use a separate
> block cipher when giving out connection IDs, because I believe it's impractical
> for the load balancer and server to be that decoupled. The server has to give
> out a CID that the load balancer will use to route back to the server, so they
> have to share enough an encryption key/algorithm. I can imagine nesting
> load balancers, but that's well in the range of QUIC v2 from my perspective.
> >>>> > >  >>
> >>>> > >  >>
> >>>> > >  >>
> <[email-masked]> wrote:
> >>>> > >  >>
> lengths. A negotiated TP would not (easily) allow for that and aside I do not
> think CID length in TP is the way to go.
> >>>> > >  >>
> >>>> > >  >>
> >>>> > >  >>
> >>>> > >  >> Mikkel
> >>>> > >  >>
> >>>> > >  >>
> >>>> > >  >>
> >>>> > >  >> > > _If_ we are to allow loose coupling between a load
> >>>> > > balancer and a  >> > > server, each of the two should be given
> >>>> > > the freedom to choose it's own  >> > > CID encryption scheme.
> >>>> > > Because all the standardized block ciphers are  >> > > now
> >>>> > > 128-bits (= 16 bytes), that naturally means that the maximum
> >>>> > > CID  >> > > length of QUIC needs to be double amount of that,
> >>>> > > plus one or two  >> > > bytes for each of the two for
> >>>> > > identifying the CID encryption keys. For  >> > > key identification
> and other supplemental use, we currently allocate 2  >> > > bytes (18-16=2).
> >>>> > >  >> >
> >>>> > >  >> > That reasoning is based on the assumption that both the
> >>>> > > load balancer  >> > and the server must use a block cipher with
> >>>> > > 128 bit block length in  >> > order to encrypt the CID. If they
> >>>> > > were constrained to stay within a  >> > short global limit, they could
> use different sets of algorithms.
> >>>> > >  >> >
> >>>> > >  >> > Assume for example that we split the CID between 32 bits
> >>>> > > encoding the  >> > number of the server in the server farm, and
> >>>> > > 64 bit encoding the  >> > connection number for the server. The
> >>>> > > server can pick a random value for  >> > the connection number,
> >>>> > > and use a hash table. The load balancer could use  >> > a 32
> >>>> > > bit variant of the FFX algorithm, using the lower 64 bit of the CID  >>
> >>>> > >  >> > Or assume that the server wants to use short CID. We now
> >>>> > > split the CID  >> > between 32 bit for the server number in the
> >>>> > > farm, and 32 bit for the  >> > connection number in the server.
> >>>> > > The server builds that connection  >> > number by using a 32
> >>>> > > bit variant of FFX. The load balancer also uses a  >> > 32 bit
> >>>> > > variant, using the lower 32 bit of the CID as initial vector for  >> >
> this FFX encryption.
> >>>> > >  >> >
> >>>> > >  >> > These are just two examples. And yes you may want to add
> >>>> > > 2 bytes for key  >> > identification, etc. In both encryption
> >>>> > > algorithms, you can feed these  >> > two bytes as additional IV
> >>>> > > for the FFX algorithm. And in both cases, we  >> > are well below
> the 18 byte limit.
> >>>> > >  >> >
> >>>> > >  >> > Yes, that requires some creative engineering. But it is
> >>>> > > not rocker  >> > science. And it seems better than carrying
> >>>> > > tons of overhead in the  >> > header, and becoming less efficient
> than HTTP2/TLS/TCP.
> >>>> > >  >>
> >>>> > >  >> I agree that it would not be the end of the world for the
> >>>> > > load  >> balancers if we decide to stick on the 18-byte limit.
> >>>> > > However, as you  >> state, it requires some creativeness.
> >>>> > >  >>
> >>>> > >  >> To me it seems that the question is if we have a strong
> >>>> > > reason to  >> require some people to be creative, for all the
> >>>> > > versions of QUIC in  >> the future. I personally think that
> >>>> > > there isn't a strong reason,  >> because people can use shorter
> >>>> > > CIDs regardless of the decision we  >> make. IIUC, the overhead
> that everyone needs to accept is:
> >>>> > >  >>
> >>>> > >  >> * one byte increase in the long header packets  >> * the
> >>>> > > minimum size of short header packets becoming slightly greater
> >>>> > > >> (otherwise, the peer might not be able to send a stateless
> >>>> > > reset)  >>  >> I'd say that the first bullet point is
> >>>> > > negligible. The second point  >> could also be, because I'd
> >>>> > > assume that the only frequently-sent  >> packets that require
> >>>> > > additional padding is the ACK-only packets, but  >> there's no
> >>>> > > reason to pad ACK-only packets in hope that you'd see a  >>
> >>>> > > stateless reset.
> >>>> > >  >>
> >>>> > >  >> Therefore, my (not-so-strong) preference has been to
> >>>> > > provide extra  >> room, so that some people with necessity can use
> longer CIDs.
> >>>> > >  >>
> >>>> > >  >> >
> >>>> > >  >> > -- Christian Huitema
> >>>> > >  >> >
> >>>> > >  >> >
> >>>> > >  >> >
> >>>> > >  >>
> >>>> > >  >>
> >>>> > >  >>
> >>>> > >  >> --
> >>>> > >  >> Kazuho Oku
> >>>> > >  >>
> >>>> > >
> >>>> > >  AVE!
> >>>> > >  Philipp S. Tiesel
> >>>> > >
> >>>> > >  --
> >>>> > >  Philipp S. Tiesel

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 21 Jun 2019 21:40:13 -0700

I prefer option 2. The wire format is obvious (unlike the current format)
and 20 bytes seems like a fine limit.

On Fri, Jun 21, 2019 at 7:01 PM Lubashev, Igor <[email-masked]> wrote:

> In fear of some middlebox vendor ossifying the protocol, we should not be
> working hard to ossify it ourselves by removing reserved bits and making it
> impossible to grow CID length in the future.
>
> I am a bit surprised by the amount of concern about having to deal with
> CID of up to 255 bytes for version negotiation.  How hard is it to:
>
> My lot is with Option 2.  Do not require v1 to handle huge CIDs but also
> do not paint yourself into a corner in Invariants.
>
> - Igor
>
> would need
> > >>>> On 21 June 2019 at 23.42.48, Christian Huitema ([email-masked]
> )
> > wrote:
> > >>>>
> > >>>> Me too. 2.
> > >>>>
> > >>>> -- Christian Huitema
> > >>>>
> blocking
> still
> fine
> well
> all
> the
> attempt to
> suggested
> impractical
> > >>>> > >  >> Whatever we do, I'd really prefer to resolve this sooner
> rather
> > than later and be truly done with it.
> > >>>> > >  >>
> > >>>> > >  >>
> > >>>> > >  >>
> proposed,

---

From: Christian Huitema <[email-masked]>
Date: Fri, 21 Jun 2019 22:17:28 -0700

On 6/21/2019 5:19 PM, Marten Seemann wrote:

> Ossification is prevented by actually using all available code points.
> With the compressed 4 bit encoding, there's a good chance that
> actually all connection ID lengths will be used by at least some QUIC
> implementations, so there's minimal risk of ossification. However,
> with options 2, we use a whole byte to encode just 20 values,
> resulting in the first 3 bits always being 0 (in v1) - an easy target
> for ossification.

In the proposed solution, the ossification risk is that next versions
will not be able to use other CID lengths than those allowed in V1. But
in this "4 bit" solution, we are making the CID lengths allowed in V1
part of the invariants. That means we would be trading a potential risk
of ossification against a certainty. Kind of like jumping in the water
to avoid the rain...

-- Christian Huitema

---

From: Lars Eggert <[email-masked]>
Date: Sat, 22 Jun 2019 08:56:38 +0300

I prefer (1), possibly even with the addition of reducing from 18 down to something shorter. 

LBs will evolve. I remain unconvinced that we need to keep bending the protocol design for them.

And if we ever need to go to longer CIDs in future versions of QUIC, there are unused flag bits.

-- 
Sent from a mobile device; please excuse typos.

> On Jun 21, 2019, at 23:00, Ian Swett <ianswett=[email-masked]> wrote:
> 
>> > >  >> I do think the invariants should allow for long CID’s as proposed, and that the long header overhead is not important..
>> > >  >> 
>> > >  >> 
>> > >  >>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sat, 22 Jun 2019 01:24:26 -0700

I think there as some private use cases for very long CID’s in mesh
networking where you replace the IP header entirely.
So I would like to see the invariants support long CIDs, but not v1 and I
generally share Lars’ concern about trying to please load balancers too
much as they will grab the entire arm.

If ossification to short lengths is a concern (I’m not convinced), we could
consider a longer length QUIC version just to scrub the system. Having two
versions where not all clients support the long version would prevent load
balancers from requiring long version while still keeping the possibility
open.

A future longer CID version could also be required to have entropy in the
leading bits such that a load balancer is not required to deal with the
full CID in all cases. They could just hash the first 32 bits like they
hash IP/port today using a fast multiplier hash.

I do not see as a problem that vneg needs to deal with long CID’s since it
is a completely isolated code path. The only possible concern here is the
amount of information you might need to cache against a given server, but
normally it would suffice to note the preferred version which would be
sufficiently short if you support it.

On 22 June 2019 at 07.57.14, Lars Eggert ([email-masked]) wrote:

I prefer (1), possibly even with the addition of reducing from 18 down to
something shorter.

LBs will evolve. I remain unconvinced that we need to keep bending the
protocol design for them.

And if we ever need to go to longer CIDs in future versions of QUIC, there
are unused flag bits.

On Jun 21, 2019, at 23:00, Ian Swett <ianswett=[email-masked]>
wrote:

On Thu, Jun 20, 2019 at 2:57 PM Martin Thomson <[email-masked]> wrote:

> and that the long header overhead is not important..
> > >  >>
> > >  >>
> > >  >>
> encoding the

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 23 Jun 2019 15:01:52 -0700

> able to put 2 encrypted routing IDs in a single CID.

I would vote for (2) or (3). (1) seems presently inadvisable.

-Ekr

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 24 Jun 2019 12:44:11 +1000

Hi Ted,

It looks like we're gravitating towards 20 bits (in QUICv1) -- if that's where we end up, is this still something you'd like to see resolved first?

Cheers,

> On 13 Jun 2019, at 2:16 am, Ted Hardie <[email-masked]> wrote:
> 
> Hi Mark,
> 
> https://github.com/quicwg/base-drafts/issues/2770 was raised in part because of this change, and it is not resolved.  While I do not expect that it will cause a reversion of this design theory, it might be useful to wait on declaring consensus for this until it resolves, in case the resolution suggests a limit change.
> 
> Could we encourage folks to test with the higher limits and new encoding for now, but not close the issue?
> 
> regards,
> 
> Ted
> 
> .....and discussion so far seems to support consensus to do so. If you object, please do so on the issue or in response to this message; absent any pushback, we'll declare consensus at the end of the week.
> 
> Regards,
> 
> --

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 24 Jun 2019 12:44:16 +1000

It seems like we have a fair number of people who prefer (2), and no one who strongly objects.

MartinD, can you go ahead and revise your PR? Then we can try another consensus call.

Cheers,

> On 24 Jun 2019, at 8:01 am, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Fri, Jun 21, 2019 at 1:00 PM Ian Swett <ianswett=[email-masked]> wrote:

---

From: Martin Duke <[email-masked]>
Date: Mon, 24 Jun 2019 17:19:22 -0700

OK, expect to see a revised PR Tuesday, Pacific time.

On Sun, Jun 23, 2019 at 7:44 PM Mark Nottingham <[email-masked]> wrote:

> Hi Ted,
>
> It looks like we're gravitating towards 20 bits (in QUICv1) -- if that's
> where we end up, is this still something you'd like to see resolved first?
>
> Cheers,
>
>

---

From: Martin Duke <[email-masked]>
Date: Tue, 25 Jun 2019 09:40:52 -0700

Option (2) is now represented in the PR.

On Mon, Jun 24, 2019 at 5:19 PM Martin Duke <[email-masked]> wrote:

>> > Could we encourage folks to test with the higher limits and new
>> encoding for now, but not close the issue?
>> >
>> > regards,
>> >
>> > Ted
>> >

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 26 Jun 2019 14:15:30 +1000

Thanks for all the work Martin!  Tracking discussion isn't pleasant.