Re: [quicwg/base-drafts] Extension frames and congestion/flow control (#1811)

[Rui Paulo <[e-mail]>]

Yes, I'm not talking about ACKs for ACKs.

I believe there are two cases for unreliable streams:

1) Send and forget about the data itself but save metadata in memory: this is the case you're talking about and it's used to grow the cwnd when an ACK arrives.  It increases  bytes_in_flight.

2) Send and forget about everything: this is the more basic approach where sending doesn't elicit an ACK. I'm not sure if it should increase bytes_in_flight, but it should respect cwnd.  

Obviously 1) is better and I also prefer it for DATAGRAM streams.

I'm just wondering if the text isn't too restrictive since we're really talking about an extension.  Imagine an extension that improves the ACK frame but doesn't replace it (ACK_ECN comeback? :-)).

It's true that implementations can break these rules and implement private extensions that don't require ACKs.

P.S.: It looks like PADDING increases bytes_in_flight. This is confusing because bytes_in_flight will increase but nothing prevents a QUIC stack from just sending PADDING in one packet which would never be ACK'ed and bytes_in_flight won't ever be zero again. This would put us in perpetual loss detection mode.  Does that make sense?

-- 
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/pull/1811#issuecomment-425967750