Subject: [quicwg/base-drafts] Lost Server Initial Takes Too Long to be Retransmitted (#3078)

From: Nick Banks <[email-masked]>
Date: Thu, 03 Oct 2019 17:24:29 -0700

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.

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

---

From: Marten Seemann <[email-masked]>
Date: Thu, 03 Oct 2019 17:27:10 -0700

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

-- 
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/3078#issuecomment-538179703

---

From: Nick Banks <[email-masked]>
Date: Thu, 03 Oct 2019 17:32:26 -0700

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.

-- 
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/3078#issuecomment-538180770

---

From: ianswett <[email-masked]>
Date: Sun, 06 Oct 2019 18:16:14 -0700

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.

-- 
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/3078#issuecomment-538809200

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 06 Oct 2019 19:03:37 -0700

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.

-- 
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/3078#issuecomment-538815280

---

From: MikkelFJ <[email-masked]>
Date: Mon, 07 Oct 2019 01:27:47 -0700

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

-- 
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/3078#issuecomment-538892971

---

From: ianswett <[email-masked]>
Date: Thu, 10 Oct 2019 19:02:15 -0700

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.

-- 
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/3078#issuecomment-540867869

---

From: Christian Huitema <[email-masked]>
Date: Wed, 16 Oct 2019 16:39:41 -0700

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.

-- 
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/3078#issuecomment-542934710

---

From: Christian Huitema <[email-masked]>
Date: Wed, 16 Oct 2019 16:40:50 -0700

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

-- 
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/3078#issuecomment-542934946

---

From: Lars Eggert <[email-masked]>
Date: Wed, 16 Oct 2019 16:45:25 -0700

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

-- 
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/3078#issuecomment-542935854

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Oct 2019 16:50:46 -0700

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.

-- 
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/3078#issuecomment-542937029