Re: [quicwg/base-drafts] Sender-Controlled Delayed ACK Ratio (#1978)

[ianswett <[e-mail]>]

@janaiyengar , if we're not going to add a generic UPDATE_TRANSPORT_PARAMs frame, then I think it makes more sense to ONLY have an UPDATE_ACK_RATIO/DELAY/etc frame and not add any new transport params, since I think what we have now is good enough to complete the handshake?

I'm favoring adding the ability to update two params:
1) MaxAckDelay (default 25ms)
2) MaxPacketsBeforeAck (currently always 2) - aka how many packets can be received before sending an acknowledgement.

Even though gQUIC has had success with fraction of RTT, I think it's less robust than specifying an actual amount of time, and specifying an amount of time allows for more precise TLP and RTO timeouts, which is very nice.

I agree there need to be bounds on how small an ack delay a sender can request and how small a MaxPacketsBeforeAck?  I'd prefer a hard failure(ie: connection close) to a "I'm just not going to do what you ask and not tell you", so I'd prefer a transport param or other mechanism to communicate the MinMaxAckDelay for a connection and a rule that you can't request a MaxPacketsBeforeAck smaller than 2.

-- 
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/1978#issuecomment-438410558