Re: [quicwg/base-drafts] Flow/congestion control and rejected 0-RTT (#390)

[Martin Thomson <[e-mail]>]

> One important point is that even if the 0RTT packets are 'lost' and need to be retransmitted, they should not be considered lost from a congestion control perspective.

Yes, that is why I had separate points for this.  "lost" doesn't quite cut it.

> If we could say rejected 0RTT packets don't count towards flow control, I think we would no longer have to exempt stream 1 from counting towards connection level flow control, which would be nice.

Since they *can't* count, that's academic.  I'm more concerned about flow control when 0-RTT is accepted.  Connection flow control can still kick in.

There is an alternative design, which would require rolling back a change (it's one that I don't like so I am biased a little, but I really like this alternative).

We require clients to remember transport parameters.  In particular, we require that clients remember the connection-level flow control limit.  We define a new transport parameter that only applies to 0-RTT: maximum bytes.  The same limit exists in TLS, and I was going to propose that we include this anyway (I've opened #405 to do this, since I obviously neglected to do so).

If we choose to apply that limit to STREAM payloads (my preference), then we can say that this value MUST be at least X octets less than the initial connection flow control offset (Finished is usually the hash output, so I imagine that 128 octets would be plenty of slack).  Then, you always have space for at least a Finished message.  

Note: Client authentication doesn't interfere with this because it can't be used in conjunction with 0-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/390#issuecomment-286593325