Re: [quicwg/base-drafts] Add max_bytes_before_ack to transport (#1715)

[Christian Huitema <[e-mail]>]

huitema commented on this pull request.

I am not enthusiastic about that. It feels like a spur-of-the-moment addition. I am not sure that it solves a real problem, compared to a time based approach. Also, if we did add something like that, we may want a way to tune the variable during the lifetime of the connection.

> @@ -1671,6 +1672,13 @@ disable_migration (0x0009):
   address other than that used to perform the handshake.  This parameter is a
   zero-length value.
 
+max_bytes_before_ack (0x000c):
+
+: An unsigned 32-bit integer that indicates the maximum number of bytes received
+  before an ACK frame should be sent. The peer sending this value indicates
+  to the receiver the value it should use.  If this value is absent, the
+  receiver may use any conformant acknowledgement algorithm.
+

The current algorithms are either time based or packet based, requiring for example several ACKs per RTT, and specifying a maximum delay or a maximum number of packets before an ACK will be sent. What is the rationale for adding a byte based control? Also, given that the algorithms are time based or packet based, why not specify max_packets_before_ack, or max_ack_delay?

> @@ -3425,6 +3433,13 @@ immediately or when a delayed ack timer expires. The delayed ack timer MUST
 NOT delay an ACK for longer than an RTT, which ensures an ACK frame is sent
 at least once per RTT if new packets needing acknowledgement were received.
 
+If the max_bytes_before_ack transport parameter has been received, the
+receiver SHOULD send an ACK frame immediately when at least that many octets
+of packets containing frames besides ACK or PADDING have been received since
+sending the previous ACK frame. If a receiver sends ACK frames less frequently,
+it risks causing the sender to send more slowly, which may lower the delivery
+rate at the receiver.
+

This is not free. It comes in addition to existing logic which is already designed to prevent sender starvation. It requires at least one additional counter in the connection state, i.e., "max bytes sent at the last ACK time", and of course additional tests in the ACK sending logic. 

-- 
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/1715#pullrequestreview-151076864