Subject: [quicwg/base-drafts] Response to lost handshake packets (#169)

From: martinduke <[email-masked]>
Date: Tue, 17 Jan 2017 10:33:40 -0800

I would like to see some language in the loss recovery document about client actions when the first handshake message is lost. We have overloaded this loss signal with multiple meanings/responses:

(1) Retransmit (due to garden-variety network loss)
(2) Change MTU and retransmit (due to MTU problems, though we might see ICMP here?)
(3) Failover to TCP (middleboxes eating QUIC)
(4) Give up (path failure)

If I were implementing a client using these documents, I am not sure how I would handle a CHLO loss given these conflicting imperatives. I could accept having SHOULDs instead of MUSTs, but there ought to be something.

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

---

From: martinduke <[email-masked]>
Date: Fri, 20 Jan 2017 14:01:09 -0800

There is a fifth (extremely improbable) possibility: the chosen connection ID happens to have collided with a connection ID already active on the server, failed decryption, and been dropped. It might be good to change the connection ID on subsequent ClientHellos.

-- 
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/169#issuecomment-274191507

---

From: ianswett <[email-masked]>
Date: Fri, 20 Jan 2017 14:04:26 -0800

Changing the connection id has a few negatives.  One is that if the first packet isn't lost, it would create two connections.  The second is that if the CHLO is lost, and the 0RTT packets are not, the second CHLO is for a different connection, so the 0RTT packets are useless.

-- 
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/169#issuecomment-274192196

---

From: martinduke <[email-masked]>
Date: Fri, 20 Jan 2017 14:29:31 -0800

Good points, there are various considerations. I know that in some prior iteration Stateless Rejects proposed a new Connection ID, but that doesn't help us here.

Changing it on retransmission #1 is too much, for sure. Perhaps at some later stage, after multiple CHLO retransmissions, the 0RTT data is more or less dead anyway. As the least probable cause, the response can come as a last-ditch effort.

We don't have a multipath draft in scope, but if there was some sort of mechanism to report available addresses, that would allow us to distinguish these packets as bad-luck CHLOs and SREJ them.

-- 
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/169#issuecomment-274197228

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 Jan 2017 23:24:34 -0800

As discussed in Tokyo, (2) is addressed by packet size being 1280, (3) is an application issue, and (1) and (4) should be addressed by retransmitting a number of times and then aborting, a la TCP.

-- 
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/169#issuecomment-275323393