Subject: [quicwg/base-drafts] Specify whether 0-RTT MAY use the same CID as Initial packets (#1721)

From: Christian Huitema <[email-masked]>
Date: Tue, 04 Sep 2018 19:08:06 -0700

In draft-13 and draft-14, there is text explaining that "On first receiving an Initial or Retry packet from the server, the client uses the Source Connection ID supplied by the server as the Destination Connection ID for subsequent packets." But there is no such specification for the 0-RTT packets, and that seems a bit strange. One reading of the spec is that 0-RTT packets should carry the same CID as Initial packets. Another is that 0-RTT packets should always carry the initial CID. The latter interpretation may be closest to a literal reading of the spec, but it leads to this weird sequence after receiving the server flight:

1) Client sends Initial packet (to carry ACK of server hello) with destination= server provided CID;
2) Client sends 0RTT packet (to carry EOED) with destination= initial CID;
3) Client sends Handshake packet  (to carry Finished) with destination= server provided CID;

Note that another part of the spec says that "Senders MUST NOT coalesce QUIC packets with different Destination Connection IDs into a single UDP datagram." So, if we refuse to use the server provided CID in the 0-RTT packets carrying the EOED, these packets should not be coalesced.

I think we should be explicit that the handling of the connection ID is common to 0-RTT and Initial packets.  

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1721

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Tue, 04 Sep 2018 19:24:55 -0700

FTR https://tools.ietf.org/html/draft-ietf-quic-transport-14#section-4.10 says clearly that 0-RTT Protected packet should use random DCID.

```
   The very first packet sent by a client includes a random value for
   Destination Connection ID.  The same value MUST be used for all 0-RTT
   packets sent on that connection (Section 4.8).  This randomized value
   is used to determine the packet protection keys for Initial packets
   (see Section 5.1.1 of [QUIC-TLS]).
```

Not sure it is intended or not.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1721#issuecomment-418578570

---

From: Martin Thomson <[email-masked]>
Date: Tue, 04 Sep 2018 19:33:59 -0700

@tatsuhiro-t, that's a relic of the change to allow 0-RTT after Retry.  It should be - at a minimum - amended to say that it matches the connection ID on the corresponding Initial packet (which is hard to concisely describe, ...).

The EOED coalescing issue is a new one though.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1721#issuecomment-418580045

---

From: Christian Huitema <[email-masked]>
Date: Tue, 04 Sep 2018 19:49:32 -0700

Actually coalescing works just fine if we align 0-RTT handling of CID with the spec in 4.6.1. You get:

1) Client sends Initial packet (to carry ACK of server hello) with destination= server provided CID;
2) Client sends 0RTT packet (to carry EOED) with destination= server provided CID;
3) Client sends Handshake packet (to carry Finished) with destination= server provided CID;

Life is good.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1721#issuecomment-418582405

---

From: Christian Huitema <[email-masked]>
Date: Tue, 04 Sep 2018 19:54:10 -0700

The change to 4.10 would be:

   The very first packet sent by a client includes a random value for
   Destination Connection ID.  This randomized value
   is used to determine the packet protection keys for Initial packets
   (see Section 5.1.1 of [QUIC-TLS]).    The very first packet sent by a client includes a random value for
   Destination Connection ID.  The same value MUST be used for 0-RTT
   packets sent on that connection (Section 4.8) until the client learns
   the server preferred CID (Section 6.4.1).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1721#issuecomment-418583098

---

From: Martin Thomson <[email-masked]>
Date: Tue, 04 Sep 2018 23:47:27 -0700

I think that this is the only sensible outcome based on the description we have of the problem.

We should check that this is going to work though.  The current design intentionally has all 0-RTT with the same connection ID so that we could guarantee (ish) that it was consistently routed.  But that was based on the understanding that most 0-RTT in most cases would be sent prior to getting the server's first handshake flight.  Having the switch in connection ID happen, but be relatively rare (you would need partial loss of the server flight).  The assessment was that it would only cause problems.

With Stream 0, we have EndOfEarlyData, so a change in connection ID based on these rules would always happen, and so we'd expect to not see any odd bugs.  Unless I hear screams, I will make a PR following Christian's suggestion (though, note to self: we probably just want to remove the special handling text rather than add more of it, this might be a change that involves deleting text more than adding it).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1721#issuecomment-418618068

---

From: Christian Huitema <[email-masked]>
Date: Tue, 04 Sep 2018 23:51:47 -0700

More fall-out from the EOED requirement..

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1721#issuecomment-418619034

---

From: Martin Thomson <[email-masked]>
Date: Tue, 04 Sep 2018 23:55:16 -0700

Well, more the opposite.  It's a benefit here that the client will always have something to send after knowing what the server wants it to use as a connection ID.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1721#issuecomment-418619821

---

From: Mike Bishop <[email-masked]>
Date: Mon, 17 Sep 2018 11:56:50 -0700

That solution breaks load balancers, because they can no longer distinguish which 0-RTT packets have client-selected CIDs and which have server-selected CIDs.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1721#issuecomment-422130397

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Sep 2018 16:12:01 -0700

Yes, we discussed that breakage in NYC and it seems like people are OK with it.  Mostly.  The change is already in.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1721#issuecomment-424155464

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Sep 2018 16:12:04 -0700

Closed #1721.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1721#event-1864395325

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Sep 2018 16:13:54 -0700

Reopened #1721.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1721#event-1864397840

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Sep 2018 16:13:54 -0700

Fixed in #1788.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1721#issuecomment-424155768

---

From: Martin Thomson <[email-masked]>
Date: Mon, 24 Sep 2018 16:13:57 -0700

Closed #1721.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1721#event-1864397940