Explain asymmetric confirmation condition #2881

martinthomson · 2019-07-09T07:19:00Z

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.

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.

marten-seemann · 2019-07-09T07:22:03Z

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.

martinthomson · 2019-07-09T07:35:36Z

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?

marten-seemann · 2019-07-09T07:38:14Z

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.

martinthomson · 2019-07-09T07:43:57Z

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.

marten-seemann · 2019-07-09T07:57:46Z

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.

martinthomson · 2019-07-09T08:00:16Z

Don't the Handshake packets consume cwnd also?

marten-seemann · 2019-07-09T08:03:32Z

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.

martinthomson · 2019-07-09T08:11:17Z

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

marten-seemann · 2019-07-09T08:12:55Z

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).

martinthomson · 2019-07-09T08:18:42Z

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.

marten-seemann · 2019-07-09T08:31:21Z

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.

martinthomson · 2019-07-09T09:47:20Z

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?

ianswett

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

draft-ietf-quic-tls.md

ianswett · 2019-07-11T15:00:16Z

draft-ietf-quic-recovery.md

+
+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


Suggested change

handshake data, endpoints SHOULD send an ack-eliciting 1-RTT packet. This can

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

marten-seemann · 2019-07-11T15:21:23Z

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?

ianswett · 2019-07-11T15:42:46Z

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

ianswett · 2019-07-20T21:41:48Z

I merged #2806, so you'll need to resolve conflicts, unless you want me to try to do that?

ianswett · 2019-07-21T12:16:53Z

draft-ietf-quic-recovery.md

@@ -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.

+If the handshake is complete, but not confirmed (see Section 4.1.1 and Section


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?

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"?

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

ianswett

One more suggestion: I think line 519 should now say confirmed, not completed?

martinthomson · 2019-10-22T22:34:55Z

OBE

martinthomson added design An issue that affects the design of the protocol; resolution requires consensus. -transport labels Jul 9, 2019

send 1-RTT in addition to retransmitting handshake packets

f522030

Enhance recovery draft with confirmation stuff

795a4d9

ianswett reviewed Jul 11, 2019

View reviewed changes

martinthomson added 2 commits July 15, 2019 08:20

unacknowledged CRYPTO data

7ec9757

It's not really retransmission

50f28c1

nibanks approved these changes Jul 20, 2019

View reviewed changes

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

c98c77e

ianswett reviewed Jul 21, 2019

View reviewed changes

ianswett mentioned this pull request Jul 21, 2019

Advise bundling a PING or other small ACK eliciting frame with Initials #2895

Closed

Move to Handshake section

c04a11e

ianswett reviewed Jul 21, 2019

View reviewed changes

PTO applies prior to handshake confirmation

a1d5495

ianswett approved these changes Jul 21, 2019

View reviewed changes

marten-seemann mentioned this pull request Jul 21, 2019

unrecoverable loss pattern leads to deadlock #2863

Closed

DavidSchinazi approved these changes Jul 21, 2019

View reviewed changes

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

49712fe

martinthomson closed this Oct 22, 2019

martinthomson deleted the unrecoverable-without-1rtt branch December 3, 2019 05:48

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Explain asymmetric confirmation condition #2881

Explain asymmetric confirmation condition #2881

martinthomson commented Jul 9, 2019

marten-seemann commented Jul 9, 2019

martinthomson commented Jul 9, 2019

marten-seemann commented Jul 9, 2019

martinthomson commented Jul 9, 2019

marten-seemann commented Jul 9, 2019

martinthomson commented Jul 9, 2019

marten-seemann commented Jul 9, 2019

martinthomson commented Jul 9, 2019

marten-seemann commented Jul 9, 2019

martinthomson commented Jul 9, 2019

marten-seemann commented Jul 9, 2019

martinthomson commented Jul 9, 2019

ianswett left a comment

ianswett Jul 11, 2019

marten-seemann commented Jul 11, 2019

ianswett commented Jul 11, 2019

ianswett commented Jul 20, 2019

ianswett Jul 21, 2019

ianswett Jul 21, 2019

martinthomson Jul 21, 2019

ianswett left a comment

martinthomson commented Oct 22, 2019

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

Explain asymmetric confirmation condition #2881

Explain asymmetric confirmation condition #2881

Conversation

martinthomson commented Jul 9, 2019

marten-seemann commented Jul 9, 2019

martinthomson commented Jul 9, 2019

marten-seemann commented Jul 9, 2019

martinthomson commented Jul 9, 2019

marten-seemann commented Jul 9, 2019

martinthomson commented Jul 9, 2019

marten-seemann commented Jul 9, 2019

martinthomson commented Jul 9, 2019

marten-seemann commented Jul 9, 2019

martinthomson commented Jul 9, 2019

marten-seemann commented Jul 9, 2019

martinthomson commented Jul 9, 2019

ianswett left a comment

Choose a reason for hiding this comment

ianswett Jul 11, 2019

Choose a reason for hiding this comment

marten-seemann commented Jul 11, 2019

ianswett commented Jul 11, 2019

ianswett commented Jul 20, 2019

ianswett Jul 21, 2019

Choose a reason for hiding this comment

ianswett Jul 21, 2019

Choose a reason for hiding this comment

martinthomson Jul 21, 2019

Choose a reason for hiding this comment

ianswett left a comment

Choose a reason for hiding this comment

martinthomson commented Oct 22, 2019