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

From: ianswett <[email-masked]>
Date: Wed, 29 Aug 2018 17:19:18 -0700

Possibly it needs to be mentioned in recovery as well?

Fixed #1428
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1715

-- Commit Summary --

  * Add max_bytes_before_ack to transport

-- File Changes --

    M draft-ietf-quic-transport.md (12)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1715.patch
https://github.com/quicwg/base-drafts/pull/1715.diff

-- 
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

---

From: ianswett <[email-masked]>
Date: Wed, 29 Aug 2018 17:52:25 -0700

@ianswett pushed 1 commit.

110e7ec  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1715/files/98961b029e7ea46d2e4068dce4fd9b27d5e41d4c..110e7ec99fd76456881310634a5d2a465f241b33

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Aug 2018 18:17:55 -0700

martinthomson commented on this pull request.

> @@ -3425,6 +3433,10 @@ 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 once that many octets of packets
+containing frames besides ACK or PADDING have been received.

What is the logic you are looking for?  Count the total size of received packets, unless they are ACK-only, then send an ACK when count>max_bytes_before_ack?

I would reframe this slightly in that case.  "The max_bytes_before_ack transport parameter can be used to request more frequent acknowledgments.  After sending a packet containing an ACK frame, a receiver counts the size of all packets it receives, omitting packets that only contain ACK or PADDING frames.  Once this count exceeds the value of the max_bytes_before_ack transport parameter it has received from a peer, the receiver MUST send an ACK frame immediately."

-- 
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-150808903

---

From: MikkelFJ <[email-masked]>
Date: Thu, 30 Aug 2018 00:07:31 -0700

mikkelfj commented on this pull request.

IoT devices may receive data at a lower power cost than transmitting. Firing up the transmit radio could be costly. For these applications it makes more sense to transmit ACK's at timed intervals. They might skip an interval if to few bytes have been received.

-- 
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#discussion_r213923464

---

From: ianswett <[email-masked]>
Date: Thu, 30 Aug 2018 04:03:27 -0700

ianswett commented on this pull request.

Yeah, I don't think we want MUST, but I'll add a caveat that if you don't do what the peer requests, you risk reduced performance.

-- 
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#discussion_r213988871

---

From: ianswett <[email-masked]>
Date: Thu, 30 Aug 2018 05:20:25 -0700

6978efe  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1715/files/110e7ec99fd76456881310634a5d2a465f241b33..6978efe54b6c333bd80bab7997425dd48e4cef5c

---

From: ianswett <[email-masked]>
Date: Thu, 30 Aug 2018 05:24:43 -0700

Martin, I tried tweaking your suggested wording, but I failed to come up with something I liked better, so I tweaked what I had.

FWIW, I'm really tired of saying "Except ACK and PADDING" everywhere, so I I'll probably try to tackle that issue(#1595) soon.

-- 
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#discussion_r214009306

---

From: Christian Huitema <[email-masked]>
Date: Thu, 30 Aug 2018 09:28:57 -0700

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
 
+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