Subject: [quicwg/base-drafts] Handling un-ackable packets (#751)

From: ekr <[email-masked]>
Date: Mon, 28 Aug 2017 21:59:32 +0000 (UTC)

Consider the case f the client is attempting 0-RTT and sends the sequence:

 CI (1), Data(2), Data(3)  // packet numbers in parens

Now, what happens if CI(1) is lost? The server cannot ACK packets 2, 3 because (a) it's forbidden and (b) it can't validate their integrity. So, it seems like what happens is just that eventually the client times out and retransmits CI, which means that the performance here is limited by the client's RTO, as opposed to if (say) the server's first flight was lost, when the QUIC ACKs can force faster retransmission. 

What I've been considering for DTLS is to have the receiver send an empty ACK (i.e,, one that acknowledges no packets), but that's not possible because of the QUIC ACK structure which requires you to ACK at least one packet.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Aug 2017 00:31:24 +0000 (UTC)

Yes, this isn't a great outcome.  The server can trigger fast retransmission of the CI by sending a stateless retry, but that means discarding 0-RTT data.

There is a more aggressive timer on the retransmission of CI, which helps a little.  There is also text that suggests that holding 0-RTT is potentially useful (though risky).  Do you think that we need a fast retransmission trigger?

-- 
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/751#issuecomment-325520043

---

From: ekr <[email-masked]>
Date: Tue, 29 Aug 2017 00:42:10 +0000 (UTC)

Well, it's relatively fine to hold this 0-RTT data b/c you can't decrypt it anyway (modulo potential DoS issues).

The solution I would propose here is that when we update the ACK frame, we allow an empty ACK, and then that can be used for fast retransmission

-- 
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/751#issuecomment-325521474

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 30 Aug 2017 23:37:12 +0000 (UTC)

On Mon, Aug 28, 2017 at 5:42 PM, ekr <[email-masked]> wrote:

> The solution I would propose here is that when we update the ACK frame, we
> allow an empty ACK, and then that can be used for fast retransmission
>
​This seems reasonable to me. It would every so slightly complicate the
implementation of a "stateless" server (which delays the creation of the
connection until a valid client hello arrives), because presumably these
"empty" ACK frames would be delivered in packets which would consume packet
number space. So when the server finally gets around to responding the the
client's handshake, it would need to account for the packet numbers
consumed by those packets. I don't think this is a problem, just a detail.

​Cheers,

Ryan​

-- 
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/751#issuecomment-326148280

---

From: Martin Thomson <[email-masked]>
Date: Thu, 31 Aug 2017 00:12:17 +0000 (UTC)

@RyanAtGoogle, Maybe we can deal with the packet number issue by minting another packet type.  That might be best given that we would have nothing to send in this packet and ideally you want to ensure that you have a way for the server to show that it actually received a packet (triggering retransmission isn't that big of a deal, but if we can prevent off-path entities from doing that cheaply, that's worth doing).

-- 
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/751#issuecomment-326153203

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 31 Aug 2017 01:26:38 +0000 (UTC)

Sure, that sounds plausible too. Perhaps add a hash of the received packet contents into the body of this new packet type?

-- 
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/751#issuecomment-326163064

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Aug 2017 18:32:34 -0700

See #693.  I think that we would take the conclusion of that.  (Right now that's agreed, I think, but waiting on some restructuring of the document, which in turn is waiting for our PR backlog to thin out some more.)

-- 
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/751#issuecomment-326163908

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 31 Aug 2017 18:37:51 +0000 (UTC)

The idea being that echoing back the connection ID (plus the version specific AEAD) would be sufficient proof of receipt? SGTM

-- 
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/751#issuecomment-326384924