Subject: [quicwg/base-drafts] Congestion feedback for rejected 0-RTT (#762)

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Sep 2017 01:05:05 +0000 (UTC)

When 0-RTT is rejected, any packets protected with those keys will be discarded by the server.  0-RTT rejection means that the server pretends that it can't read 0-RTT.  As a result, servers cannot (MUST NOT actually) acknowledge rejected 0-RTT.

This needs discussion in the recovery draft.  What do we tell the congestion controller about these packets?  The current design seems to only take bytes sent and packet loss as inputs to the algorithm.  That leads to the controller assuming that the packet was received successfully, when we have no way of knowing whether that is true or not.  We certainly don't want the client to ignore the fact that it sent packets, so what do we recommend?

See also #761.

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 07 Sep 2017 16:53:38 -0700

On the list, @janaiyengar says (and I think that this might reflect where we are going with this):

> The sender is not going to receive acks for these packets, so it's best to do a clean slate and start again with the initial window. The sender *could* do something more complicated, like wait "a while" to let the network drain, but without knowing what network bandwidth is,  the sender would still be in the dark about how long to wait. Any wait time here will be wrong, just as wrong as the initial window. So, I would reset the controller's state to initial state.

-- 
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/762#issuecomment-327960526

---

From: mirjak <[email-masked]>
Date: Wed, 13 Sep 2017 06:12:39 -0700

So even if the rejected packets where not ack'ed, the server could still indicate to the client in the TLS handshake that the 0-RTT data was rejected and potentially even tell the client how many packets where rejected. That might be all you need to know for congestion control purposes because if some or all of the 0-RTT packets were lost you might want to reduce the congestion window even below the initial window (assuming the initial window was larger than the minimum window).

However, just resending the 1-RTT with the initial window is probably easier and should be fine in most cases, or in the worse case just delay your congestion control reaction by one RTT.

-- 
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/762#issuecomment-329163257

---

From: ekr <[email-masked]>
Date: Wed, 13 Sep 2017 21:35:23 +0000 (UTC)

On Wed, Sep 13, 2017 at 6:12 AM, mirjak <[email-masked]> wrote:

> So even if the rejected packets where not ack'ed, the server could still
> indicate to the client in the TLS handshake that the 0-RTT data was
> rejected and potentially even tell the client how many packets where
> rejected.
>

Well, you can say it was rejected, though you don't know how many packets
were rejected at this point.

-Ekr

> That might be all you need to know for congestion control purposes because
> if some or all of the 0-RTT packets were lost you might want to reduce the
> congestion window even below the initial window (assuming the initial
> window was larger than the minimum window).
>
> However, just resending the 1-RTT with the initial window is probably
> easier and should be fine in most cases, or in the worse case just delay
> your congestion control reaction by one RTT.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/762#issuecomment-329163257>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABD1ob9bnui6cixnkJe0lewa1uMH0NSNks5sh9TGgaJpZM4PNta6>
> .
>

-- 
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/762#issuecomment-329303874