Subject: [quicwg/base-drafts] Explain asymmetric confirmation condition (#2881)

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Jul 2019 00:19:09 -0700

This leads to indefinite Handshake messages from one side, as Handshake
packets can never be acknowledged.  As discussed, sending anything that
elicits an ACK should fix this.  But making a connection where you sit
entirely idle leads to a weird corner case.

Closes #2863.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2881

-- Commit Summary --

  * Explain asymmetric confirmation condition

-- File Changes --

    M draft-ietf-quic-tls.md (9)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2881.patch
https://github.com/quicwg/base-drafts/pull/2881.diff

-- 
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/pull/2881

---

From: Marten Seemann <[email-masked]>
Date: Tue, 09 Jul 2019 00:22:11 -0700

I don’t think this fixes the issue I raised. You don’t only have to send, but also to retransmit the 1-RTT packets. We have a bunch of text in the recovery document that tells us to do not do this.

-- 
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/pull/2881#issuecomment-509522794

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Jul 2019 00:35:44 -0700

I considered that, and you refer to the fact that the cryptographic handshake packets are the ones that are sent when you have a loss detection timeout. And that these are the only packets that are sent.  I worded this carefully to say that you send 1-RTT, ack-eliciting packets.  Should I say "In addition to retransmitting crypto packets, ..." or something along those lines?

-- 
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/pull/2881#issuecomment-509527089

---

From: Marten Seemann <[email-masked]>
Date: Tue, 09 Jul 2019 00:38:22 -0700

If that’s the way we’re going to fix this (I’m not sure if it’s the best way), we would need to edit the recovery document as well. That would be a pretty ugly special case in the retransmission algorithm we describe.

-- 
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/pull/2881#issuecomment-509527873

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Jul 2019 00:44:06 -0700

Well, keep in mind that "recovery" for PING, which is the way you would approach this if you never had anything to send, depends on you generating a new PING with every transmission.  So it's not that terrible.

For our implementation, we would simply crank the lever and spit out another packet when the PTO fires, which would produce a packet that coalesced the missing Handshake with a 1-RTT packet.

It only gets hairy when the lost Handshake packet overflows the MTU.  Which, sadly, is possible.  If we lost more than a PMTU, it gets a little hairy, because we will probably won't send any 1-RTT packets ever.  I might be willing to let the connection time out in that case 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/pull/2881#issuecomment-509529782

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Jul 2019 00:50:18 -0700

@martinthomson pushed 1 commit.

f5220308f1c8b141e66b5dfb5049c5969023070b  send 1-RTT in addition to retransmitting handshake packets

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2881/files/430ae03d4fcbdfe1f940ad23a317e9a04e31740f..f5220308f1c8b141e66b5dfb5049c5969023070b

---

From: Marten Seemann <[email-masked]>
Date: Tue, 09 Jul 2019 00:57:54 -0700

> Well, keep in mind that "recovery" for PING, which is the way you would approach this if you never had anything to send, depends on you generating a new PING with every transmission.

If I understand your point correctly, you would either need to change `    RetransmitUnackedCryptoData()` into `RetransmitUnackedCryptoDataAndAtLeastOne1RTTPacket()` or `RetransmitUnackedCryptoDataAndSend1RTTPing()`. That sounds doable, but it gets complicated when you take the congestion controller into account: It could happen that you have enough cwnd to send the retransmissions for the Handshake packets, but not for the 1-RTT packet. What you really want is to send the retransmission for the 1-RTT packet as a probe packet (i.e. never blocked by congestion control).

> I might be willing to let the connection time out in that case though.

I don't think timing out is acceptable in the case where just 2 packets are lost. In my opinion, the only case where a timeout is justifiable is if the connection is (effectively) blackholed.

You can see the root cause of #2863 as not a problem with loss recovery at all, but with our definition of "handshake confirmed": The server is dropping the keys too early. If the server kept the keys for longer, this loss pattern would harm the connection at all.

-- 
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/pull/2881#issuecomment-509534345

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Jul 2019 01:00:25 -0700

Don't the Handshake packets consume cwnd also?

-- 
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/pull/2881#issuecomment-509535130

---

From: Marten Seemann <[email-masked]>
Date: Tue, 09 Jul 2019 01:03:40 -0700

> Don't the Handshake packets consume cwnd also?

@martinthomson That's exactly the problem. They consume cwnd, although they're not even lost (as in "dropped by the network"), just dropped as undecryptable by the peer. In this situation, freeing up this cwnd is only possible after completion of the handshake, when all loss recovery state for non-1-RTT packets is dropped.

-- 
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/pull/2881#issuecomment-509536210

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Jul 2019 01:09:00 -0700

795a4d98354adacf727b0e41bf8ddb70f7921644  Enhance recovery draft with confirmation stuff

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2881/files/f5220308f1c8b141e66b5dfb5049c5969023070b..795a4d98354adacf727b0e41bf8ddb70f7921644

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Jul 2019 01:11:26 -0700

So whatever we do to get to confirmation helps.  But until that point, we're headed to a completely unrecoverable state.

-- 
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/pull/2881#issuecomment-509538760

---

From: Marten Seemann <[email-masked]>
Date: Tue, 09 Jul 2019 01:13:04 -0700

We would have to say that the 1-RTT packet has to be treated like a probe packet (i.e. not blocked by the congestion controller).

-- 
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/pull/2881#issuecomment-509539278

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Jul 2019 01:18:52 -0700

Why?  The retransmitted Handshake packets aren't and in this case these are the ones that will run the CWND down.  The 1-RTT PING barely counts.

Can't we just let the CWND burn down?  Do you really think that by this point you will want to send more than CWND worth of these?  I know that it's small at this point (maybe just one packet more than baseline), but if we use INIT_CWND = not_too_small, then we get quite a few goes before this becomes terminal.

-- 
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/pull/2881#issuecomment-509541374

---

From: Marten Seemann <[email-masked]>
Date: Tue, 09 Jul 2019 01:31:29 -0700

Depending on the application this is actually quite likely, or even the common case. Assume that the client has a bit of data to send in the first flight, then this would fill up the cwnd completely. You don't even need must, just 10 packets, minus the Handshake packets in flight (which might contain a certificate chain), and their retransmissions.

> Why? The retransmitted Handshake packets aren't and in this case these are the ones that will run the CWND down. The 1-RTT PING barely counts.

The problem is not the size of the 1-RTT PING, but the fact that we might already be congestion limited once we try to send 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/pull/2881#issuecomment-509545923

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Jul 2019 02:47:29 -0700

> The problem is not the size of the 1-RTT PING, but the fact that we might already be congestion limited once we try to send it.

Right, but this is a condition where 1-RTT packets might not be processed by the server.  The client can't know if the server really needs the Handshake packets or the 1-RTT packet.  If we want to exempt anything from CWND, wouldn't we need to exempt both?

-- 
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/pull/2881#issuecomment-509573810

---

From: ianswett <[email-masked]>
Date: Thu, 11 Jul 2019 08:03:12 -0700

ianswett commented on this pull request.

This is going to conflict with #2806 so I'll try to merge that soon.

> @@ -391,6 +391,15 @@ sent with 1-RTT keys, and the highest value of the Largest Acknowledged field
 in any received 1-RTT ACK frame: once the latter is higher than or equal to the
 former, the handshake is confirmed.
 
+Note:
+
+: Unless ack-eliciting packets protected by 1-RTT keys are sent by an endpoint,
+  the handshake might never be confirmed by an endpoint.  If the peer does
+  confirm the handshake, this could result in perpetual retransmission of
+  Handshake packets, which cannot be acknowledged.  To avoid this problem, in

retransmission of Handshake data, not packets?  Here and on the next line.

> @@ -532,11 +532,18 @@ a PATH_RESPONSE to seed initial_rtt for a new path, but the delay SHOULD NOT
 be considered an RTT sample.
 
 When a crypto packet is sent, the sender MUST set a timer for twice the smoothed
-RTT.  This timer MUST be updated when a new crypto packet is sent and when
-an acknowledgement is received which computes a new RTT sample. Upon timeout,
-the sender MUST retransmit all unacknowledged CRYPTO data if possible.  The
-sender MUST NOT declare in-flight crypto packets as lost when the crypto timer
-expires.
+RTT.  This timer MUST be updated when a new crypto packet is sent and when an
+acknowledgement is received that produces a new RTT sample. Upon timeout, the
+sender MUST retransmit unacknowledged cryptographic handshake data.  The sender
+MUST NOT declare in-flight crypto packets as lost when the crypto timer expires.
+
+If the handshake is complete, but not confirmed (see Section 4.1.1 and Section
+4.1.2 of {{QUIC-TLS}}), in addition to sending unacknowledged crytographic
+handshake data, endpoints SHOULD send an ack-eliciting 1-RTT packet.  This can

```suggestion
Handshake data, endpoints SHOULD send an ack-eliciting 1-RTT packet.  This can
```

-- 
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/pull/2881#pullrequestreview-260758998

---

From: Marten Seemann <[email-masked]>
Date: Thu, 11 Jul 2019 08:21:32 -0700

> This is going to conflict with #2806 so I'll try to merge that soon.

@ianswett I don't think this is an editorial change. Furthermore, I don't believe that a change to the loss recovery algorithm is necessarily the best fix for #2863.
Can we not merge this until Montreal?

-- 
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/pull/2881#issuecomment-510531537

---

From: ianswett <[email-masked]>
Date: Thu, 11 Jul 2019 08:42:54 -0700

This PR and that issue are labeled transport+design, so presumably it'd need a consensus call?

-- 
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/pull/2881#issuecomment-510540406

---

From: Martin Thomson <[email-masked]>
Date: Sun, 14 Jul 2019 15:38:00 -0700

martinthomson commented on this pull request.

+Note:
+

It's definitely packets in this case.  The content isn't relevant to the point, it's that they won't/can't be acknowledged.

-- 
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/pull/2881#discussion_r303264506

---

From: Martin Thomson <[email-masked]>
Date: Sun, 14 Jul 2019 15:40:21 -0700

7ec975789ec99f28ff853961624641ea0fb06f23  unacknowledged CRYPTO data

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2881/files/795a4d98354adacf727b0e41bf8ddb70f7921644..7ec975789ec99f28ff853961624641ea0fb06f23

---

From: ianswett <[email-masked]>
Date: Sat, 20 Jul 2019 13:37:18 -0700

+Note:
+

I thought the whole point of QUIC is that frames or data are retransmitted, not 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/pull/2881#discussion_r305592337

---

From: Martin Thomson <[email-masked]>
Date: Sat, 20 Jul 2019 14:36:46 -0700

50f28c150ccd8ddef4998ee44433ec3308db1e66  It's not really retransmission

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2881/files/7ec975789ec99f28ff853961624641ea0fb06f23..50f28c150ccd8ddef4998ee44433ec3308db1e66

---

From: Martin Thomson <[email-masked]>
Date: Sat, 20 Jul 2019 14:39:59 -0700

+Note:
+

This isn't really about retransmission, so I removed the "re".

-- 
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/pull/2881#discussion_r305594026

---

From: ianswett <[email-masked]>
Date: Sat, 20 Jul 2019 14:41:57 -0700

I merged #2806, so you'll need to resolve conflicts, unless you want me to try to do 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/pull/2881#issuecomment-513501310

---

From: Nick Banks <[email-masked]>
Date: Sat, 20 Jul 2019 14:55:52 -0700

nibanks approved this pull request.

-- 
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/pull/2881#pullrequestreview-264512647

---

From: Martin Thomson <[email-masked]>
Date: Sat, 20 Jul 2019 15:08:25 -0700

c98c77e4646299ffc43a87bb477b246c2fbd5608  Merge branch 'master' into unrecoverable-without-1rtt

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2881/files/50f28c150ccd8ddef4998ee44433ec3308db1e66..c98c77e4646299ffc43a87bb477b246c2fbd5608

---

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

> @@ -629,6 +629,14 @@ MAY use alternate strategies for determining the content of probe packets,
 including sending new or retransmitted data based on the application's
 priorities.

I think it might make sense to work this into the "Handshakes and New Paths" section above?

The way I'm now thinking of this is: It's the client's job to drive the handshake to confirmation, and here's what is necessary to ensure that occurs...  Does that make sense?

-- 
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/pull/2881#pullrequestreview-264534049

---

From: ianswett <[email-masked]>
Date: Sun, 21 Jul 2019 06:38:48 -0700

Also, now that I read the existing text again, I'm wondering if the "Sending Probe Packets" section should be before "Handshakes and New Paths"?

-- 
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/pull/2881#discussion_r305618565

---

From: Martin Thomson <[email-masked]>
Date: Sun, 21 Jul 2019 06:50:26 -0700

c04a11e96ccc0959fd1eaf1074e34cda84d02002  Move to Handshake section

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2881/files/c98c77e4646299ffc43a87bb477b246c2fbd5608..c04a11e96ccc0959fd1eaf1074e34cda84d02002

---

From: Martin Thomson <[email-masked]>
Date: Sun, 21 Jul 2019 06:51:21 -0700

I will leave that change to you, but I have moved this up to the Handshakes and New Paths section.

-- 
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/pull/2881#discussion_r305619114

---

From: ianswett <[email-masked]>
Date: Sun, 21 Jul 2019 06:54:53 -0700

One more suggestion: I think line 519 should now say confirmed, not 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/pull/2881#pullrequestreview-264538341

---

From: Martin Thomson <[email-masked]>
Date: Sun, 21 Jul 2019 07:18:32 -0700

a1d5495f4a0e1e0ba95a64afa38e3f899b874a0c  PTO applies prior to handshake confirmation

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2881/files/c04a11e96ccc0959fd1eaf1074e34cda84d02002..a1d5495f4a0e1e0ba95a64afa38e3f899b874a0c

---

From: ianswett <[email-masked]>
Date: Sun, 21 Jul 2019 08:06:24 -0700

ianswett approved this pull request.

-- 
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/pull/2881#pullrequestreview-264541509

---

From: David Schinazi <[email-masked]>
Date: Sun, 21 Jul 2019 12:34:00 -0700

DavidSchinazi approved this pull request.

-- 
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/pull/2881#pullrequestreview-264551207