Subject: Destination connection Id in a short header

From: "Deval, Manasi" <[email-masked]>
Date: Thu, 21 Mar 2019 14:52:58 +0000

Hi All,

In the QUIC spec, it is not necessary for a client to send a destination connection Id in the short header. The understanding here is the header fields outside the QUIC header may uniquely identify the flow. While working through offloading QUIC crypto, we need a way to identify the classification schema to find the crypto key. This schema may commonly be based on the connection id. Extending the schema to include an outer 5 tuple when the connection id is not present is an extra step in the logic.

I'm curious about why this is not uniformly defined in the specification. I would like to find out how often do clients choose not to have a connection id in the short header? Is this is a common usage?

Thanks,
Manasi

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 21 Mar 2019 11:01:40 -0400

I believe it used to be that case that the connection ID was not needed in
short headers, but after the change to have asymmetric connection ID’s and
multiple connections per 5-tuple, it makes more sense to have the
connection ID in the short header. It is only if you exclusively use
5-tuple routing on a single path that you would want to skip the connection
ID in short headers.

Mikkel

On 21 March 2019 at 15.53.21, Deval, Manasi ([email-masked]) wrote:

Hi All,

In the QUIC spec, it is not necessary for a client to send a destination
connection Id in the short header. The understanding here is the header
fields outside the QUIC header may uniquely identify the flow. While
working through offloading QUIC crypto, we need a way to identify the
classification schema to find the crypto key. This schema may commonly be
based on the connection id. Extending the schema to include an outer 5
tuple when the connection id is not present is an extra step in the logic.

I’m curious about why this is not uniformly defined in the specification. I
would like to find out how often do clients choose not to have a connection
id in the short header? Is this is a common usage?

Thanks,

Manasi

---

From: Nick Banks <[email-masked]>
Date: Thu, 21 Mar 2019 15:08:46 +0000

I believe it will be very common for clients not to use a CID if they are not sharing the UDP port. For instance, in WinQuic the default client behavior is to NOT share the UDP port and NOT use a CID. Servers will practically always use a CID since they always share the UDP port.

- Nick

From: QUIC <[email-masked]> On Behalf Of Mikkel Fahnøe Jørgensen
Sent: Thursday, March 21, 2019 8:02 AM
To: Deval, Manasi <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Destination connection Id in a short header

I believe it used to be that case that the connection ID was not needed in short headers, but after the change to have asymmetric connection ID’s and multiple connections per 5-tuple, it makes more sense to have the connection ID in the short header. It is only if you exclusively use 5-tuple routing on a single path that you would want to skip the connection ID in short headers.

Mikkel

On 21 March 2019 at 15.53.21, Deval, Manasi ([email-masked]<mailto:[email-masked]>) wrote:
Hi All,

I’m curious about why this is not uniformly defined in the specification. I would like to find out how often do clients choose not to have a connection id in the short header? Is this is a common usage?

Thanks,
Manasi

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 21 Mar 2019 11:11:32 -0400

I'm not sure that's true Mikkel,

It has always been the case that one endpoint could decide not to require a connection ID in packets that its peer sends.

But Manasi, I don't understand the problem.  If you need a connection ID, you can request that your peer include one.  Unless you are talking about packets that you are sending, in which case you have no control over the connection ID and its contents.

On Fri, Mar 22, 2019, at 02:02, Mikkel Fahnøe Jørgensen wrote:
> I believe it used to be that case that the connection ID was not needed 
> in short headers, but after the change to have asymmetric connection 
> ID’s and multiple connections per 5-tuple, it makes more sense to have 
> the connection ID in the short header. It is only if you exclusively 
> use 5-tuple routing on a single path that you would want to skip the 
> connection ID in short headers.
> 
> Mikkel
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 21 Mar 2019 11:15:11 -0400

Kind Regards,
Mikkel Fahnøe Jørgensen

On 21 March 2019 at 16.11.54, Martin Thomson ([email-masked]) wrote:

It has always been the case that one endpoint could decide not to require a
connection ID in packets that its peer sends.

That was my point, if it wasn’t clear. But there is now more incentive to
not skipping it, depending on use case.