Subject: [quicwg/base-drafts] 0-RTT packets with Server Connection ID (#584)

From: Igor Lubashev <[email-masked]>
Date: Tue, 06 Jun 2017 01:26:48 -0700

The draft requires the client to use client's Connection ID, even if the server's Connection ID is available. This is an artifact of having just one packet type and wanting to be unambiguous whose connection ID this packet features.

I propose using assigning an extra packet type for "0-RTT packets with Server Connection ID" to make handling connections more reliable.

This is related to #577.

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

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 06 Jun 2017 03:56:13 -0700

The original issue description is about switching to Server Connection ID for 0-RTT packets. This may be a rare race condition when Server Connection ID is available, so it is not very important.

The more important case is when Server Connection ID is available for the client **before** the very first 0-RTT packet is sent.  It is important than for the server (load balancer) to know that Server Connection ID is being used.  This also make this a very similar issue to #577.

-- 
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/584#issuecomment-306451633

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Jun 2017 04:15:07 -0700

@igorlord, Can we repurpose this issue to talk about priming the client with a connection ID that will improve their chances of having 0-RTT accepted by a server?

-- 
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/584#issuecomment-306455448

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 06 Jun 2017 04:19:21 -0700

@martinthomson Yes, with my last comment, I've already started down that road. Please, use this issue to be about priming the client with a connection ID for 0-RTT _and_ the 0-RTT packet explicitly identifying itself as primed.

-- 
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/584#issuecomment-306456355

---

From: ianswett <[email-masked]>
Date: Tue, 06 Jun 2017 05:46:15 -0700

Are you indicating the client would use a different packet type(ie: Client Initial) to indicate it was not client chosen?

-- 
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/584#issuecomment-306475106

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 06 Jun 2017 05:57:45 -0700

Yes, a different packet type would do it.

I want my load balancer to be very simple like:
  forward_to_server_id = has_server_id(packet) ? extract_server_id(packet) : pick_server_id_for(packet, policies);

-- 
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/584#issuecomment-306477919

---

From: Martin Thomson <[email-masked]>
Date: Tue, 06 Jun 2017 06:02:00 -0700

Well, *I'm* not inclined to suggest a new packet type.  We could require that a client use a connection ID if the server picked one.  In that way, the server could be sure (to the extent that it can be) that when it accepts 0-RTT, the connection ID is correct.

-- 
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/584#issuecomment-306478963

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 06 Jun 2017 06:35:29 -0700

Ok, server/load-balancer would just need to treat this case like it would treat Client Initial. I can live with this, I think.

-- 
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/584#issuecomment-306487899