Subject: [quicwg/base-drafts] Loss events for reordered 0- and 0.5-RTT data (#1967)

From: Martin Thomson <[email-masked]>
Date: Mon, 05 Nov 2018 20:29:36 -0800

In the event that 0-or 0.5-RTT data arrives before the cryptographic handshake packets that would normally precede it.  That is, the Initial containing ClientHello might arrive after a few 0-RTT packets, or the 0.5-RTT packets might arrive before the server flight is completely received.

In that case, those packets will be declared lost.  That's fine from a loss-recovery perspective.  However, the congestion controller will treat this as a loss event.  We want to ensure that loss events are driven only by congestion.

Perhaps the congestion controller shouldn't trigger a loss event on packets that might be dropped in this way.  If we do this, we need to be careful about definition.

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

---

From: Subodh Iyengar <[email-masked]>
Date: Wed, 07 Nov 2018 05:18:44 -0800

This also applies to one rtt data as well sent in the client first flight. If one rtt arrives before cfin, then the read key cannot be used by the server yet, and it might drop or buffer a few of these packets. This could appear as a loss to the client. We got bit by this a few months ago. 

-- 
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/1967#issuecomment-436619595

---

From: ianswett <[email-masked]>
Date: Tue, 20 Nov 2018 12:42:03 -0800

We need to clarify this, but it's going to be a challenge to write clear text about these issues.  I'll send out a PR that tries to do so anyway.

-- 
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/1967#issuecomment-440422273

---

From: janaiyengar <[email-masked]>
Date: Tue, 20 Nov 2018 13:11:49 -0800

This is a slightly involved fix.  We basically need to distinguish packets whose drops do not necessarily indicate congestion vs those that do.  As I see it, the packets whose drop does not necessarily indicate congestion are:
1. any handshake packet
2. any 0-RTT data (sent by client)
3. any 0.5-RTT data (sent by server)
4. data received before CFIN, which from the client's point of view is all data sent until ack for CFIN is received (thanks @siyengar for noting this).

1, 2, 3 are ok, but 4 is tricky, since congestive losses in the first RTT are indicators of a large initial window. I'm inclined to leave 4 out conservatively, since it delays the engagement of the CC machinery by a fair bit.

-- 
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/1967#issuecomment-440430960

---

From: Marten Seemann <[email-masked]>
Date: Tue, 20 Nov 2018 15:19:58 -0800

Handshake packets would never be undecryptable for the server, only for the client. 

-- 
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/1967#issuecomment-440464452

---

From: janaiyengar <[email-masked]>
Date: Wed, 21 Nov 2018 15:28:14 -0800

@marten-seemann : Fair enough, but I think it's just simpler to assume this generally for now.

-- 
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/1967#issuecomment-440849278