Lost Server Initial Takes Too Long to be Retransmitted

[nibanks]

Generally, the server's first flight (of a 1-RTT connection attempt) has a single Initial packet and the rest is made up of 1 or more Handshake packets. If the UDP datagram containing the Initial packet is lost, the server only ends up retransmitting it based off the default RTT based PTO timer.

If/when the client receives the Handshake packets that it can't decrypt (because the Initial was lost) then it has a (possible) signal that the server has responded, but a packet was lost. The client could use this info to immediately retransmit its Initial. If/when the server receives this, it could use this info to retransmit its Initial.

[marten-seemann]

Isn't this a special case of the EMPTY_ACK frame discussed earlier?

[nibanks]

Yes, but the problem is the worst in this case, because the server doesn't have an RTT estimate, so it can't have an accurate PTO for retransmitting. Once it has received a single ACK, the PTO becomes a lot more accurate, and falling back to the PTO is a lot less painful.

[ianswett]

This problem also occurs when the server receives 0-RTT packets it cannot decrypt. In that case, it would be ideal if it could do something to indicate something was received but not processed. I guess it could send a PING in an Initial packet as an alternative to EMPTY_ACK?

I sent out a PR that I believe covers the most important points you mention. PTAL.

[kazuho]

I think the problems here are:

• Receiving a retransmit client Initial does not necessarily indicate a loss. It could simply be the case that the actual RTT is greater than the client's initial RTT. Do we want the server to retransmit packets in that case? Note that a client might use a small initial RTT when it is connecting to a server that it has previously connected to.
• How the server detects a retransmission will become complicated if we adopt #3045.

Considering these aspects, I might be weakly inclined to addressing the issue using an explicit signal, defined either within v1 or an extension.

[mikkelfj]

This problem also occurs when the server receives 0-RTT packets it cannot decrypt. In that case, it would be ideal if it could do something to indicate something was received but not processed.

I think this falls into the category of black-holing invalid packets as they might easily come from an unwanted source.

[ianswett]

I don't believe #3045 complicates things substantially, because if only one UDP datagram is lost, then you would expect to receive an ACK in a relatively short period(no ack delay) of time and loss recovery could function quite well.

[huitema]

Does this need to be standardized? Or does it fall in the range of heuristics that applications may do, but don't need to be specified.

[huitema]

Of course the handshake packet that you receive can be a bunch of random bytes sent by an attacker...

[larseggert]

Discussed in Cupertino. @ianswett to update #3080 based on discussion.

[martinthomson]

The proposed "fix" could lead to a deadlock where the server consumes its entire congestion window without making progress. If the server receives too many Initial packets (bad RTT estimate at the client, say), then it will send lots of data without getting an ACK. As suggested, this is just an optimization, so limiting the number of times this optimization can be used might avoid that problem.

[larseggert]

Discussed in ZRH. No change since Cupertino.

[martinthomson]

Apparently this has consensus. @ianswett, is #3080 ready?

[mikkelfj]

My only problem is that I wouldn't know how to detect duplicate CRYPTO data from a cursory read. Normally you'd feed the data to a TLS blackbox and it would not necessarily provide the information needed. The alternative seems to be to inspect CRYPTO frames, but who is to say that duplicate data is always framed the same?

[ianswett]

@mikkelfj detecting duplicate CRYPTO data is definitely implementation dependent, so I don't want to describe that in the recovery doc.