Subject: Re: [quicwg/base-drafts] unrecoverable loss pattern leads to deadlock (#2863)

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Sat, 13 Jul 2019 23:19:19 -0700

If I understand the issue correctly, the problem is that server drops handshake key too early before client gets ack for its last handshake flight.  Server can ack any client Short packet without client last Handshake flight.  That means that sending any ack-eliciting 1RTT packet from client do not fix this issue.  Coalescing missing Handshake and Short packet would suffer MTU overflow as disscused in PR.
I think server has to wait for client's confirmation of handshake before confirming handshake.  It might be good idea to reconsider explicit signal again?

-- 
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/2863#issuecomment-511176770

---

From: David Schinazi <[email-masked]>
Date: Sun, 21 Jul 2019 08:54:38 -0700

>From the [Discarding Handshake Keys Section](https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#discarding-handshake-keys):

> Most application protocols will send data after the handshake, resulting in acknowledgements that allow both endpoints to discard their handshake keys promptly. Endpoints that do not have reason to send immediately after completing the handshake MAY send ack-eliciting frames, such as PING, which will cause the handshake to be confirmed when they are acknowledged.

We could change this MAY to a SHOULD and it'll resolve this issue.

-- 
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/2863#issuecomment-513565924

---

From: ekr <[email-masked]>
Date: Sun, 21 Jul 2019 08:56:16 -0700

I'm sorry, but I'm having trouble following the initial example.

You said that the client sent a 1-RTT packet and it got lost. In this case, it will continue to retransmit it and will eventually get an ACK, at which point the handshake will be confirmed and it will drop the keys and stop retransmitting ClientFinished. 

And as David indicates above, if the client is not sending at all, then it can just send ack-eliciting frames.

-- 
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/2863#issuecomment-513566038

---

From: Marten Seemann <[email-masked]>
Date: Sun, 21 Jul 2019 08:56:47 -0700

> We could change this MAY to a SHOULD and it'll resolve this issue.

No, it doesn't. As I described in the initial example, and in https://github.com/quicwg/base-drafts/issues/2863#issuecomment-507080436, the client won't retransmit 1-RTT data until the handshake is completed.

-- 
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/2863#issuecomment-513566070

---

From: ekr <[email-masked]>
Date: Sun, 21 Jul 2019 10:22:12 -0700

@marten-seemann well in that case, the source of the problem is the retransmission algorithm, not this. Why does it make sense to not retransmit 1-RTT data when there is an outstanding CFIN?

Just consider the simple case where the client's second flight (CFIN + some data) is lost. When the PTO expires, you should resend all of that.

-- 
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/2863#issuecomment-513572171

---

From: Marten Seemann <[email-masked]>
Date: Sun, 21 Jul 2019 10:48:16 -0700

@ekr The client could have sent an arbitrary amount of 1-RTT data, so you wouldn't want to retransmit all of this. As discussed on the PR (#2881), this can have some weird interaction with the congestion controller as well.

-- 
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/2863#issuecomment-513574089

---

From: ekr <[email-masked]>
Date: Sun, 21 Jul 2019 11:16:33 -0700

Sure, you would, however, want to retransmit *some* of 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/2863#issuecomment-513575990

---

From: ianswett <[email-masked]>
Date: Sun, 21 Jul 2019 12:01:51 -0700

Technically, 1RTT packets can be sent on the PTO when there is unacked Handshake data, but you're correct that if there are two MSS or more of Handshake data, the client would repeatedly retransmit that data instead of sending any 1RTT packets as written today.

I think MT's PR is heading in the right direction.

@marten-seemann do you have an alternate suggestion of how to deal with this situation?

-- 
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/2863#issuecomment-513579031