search

quicwg / base-drafts

Internet-Drafts that make up the base QUIC specification
https://quicwg.org
1.63k stars 204 forks source link

Congestion feedback for rejected 0-RTT #762

Closed martinthomson closed 6 years ago

martinthomson commented 7 years ago

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.

martinthomson commented 7 years ago

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.

mirjak commented 7 years ago

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.

ekr commented 7 years ago

On Wed, Sep 13, 2017 at 6:12 AM, mirjak notifications@github.com 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.

— You are receiving this because you are subscribed to this thread. 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 .

martinthomson commented 6 years ago

Duplicate of #390.