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

From: Christoph Paasch <[email-masked]>
Date: Wed, 12 Sep 2018 09:51:31 -0700

I am to some extend agreeing with what @huitema is saying. This is adding complexity at a late stage, without giving clear guidance,... as to how to use the max_bytes_before_ack:
* What value should a congestion-control announce to the peer ?
* How exactly should the receiver use the value? During slow-start, should it ACK more frequently to allow the sender to build a rate-estimation? Or should it always wait for the necessary bytes?

AFAICS, this can easily be added later on as an extension once it is clearer how to use it.

-- 
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#issuecomment-420719877

---

From: ianswett <[email-masked]>
Date: Wed, 12 Sep 2018 09:57:13 -0700

At the moment, we're providing no guidance at all, except to not delay ACKs more than 1RTT.

This may not be the right approach, but I think doing nothing here about these ack delay/aggregation issues are almost guaranteed to provide poor performance.

Jana and I have discussed this quite a bit in the past, and it should have made it into a PR sooner.  It's not intended as a last minute addition.

-- 
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#issuecomment-420721717

---

From: ianswett <[email-masked]>
Date: Wed, 12 Sep 2018 09:57:46 -0700

ianswett commented on this pull request.

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

Agreed, but it is simple to implement.

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

---

From: ianswett <[email-masked]>
Date: Wed, 12 Sep 2018 17:00:33 +0000 (UTC)

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

Congestion control is byte-based, not packet based, hence the choice.  But I can see the packet vs byte based going either way.

In order to use max_ack_delay effectively, I think it's almost necessary to be able to update it during the connection.  Fraction of an RTT may not need to be updated during a connection, admittedly.  max_ack_delay also feeds into TLP and RTO timers, so making it fraction of an RTT could be a bit dangerous if one side has a poor estimate of 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/pull/1715#discussion_r217112524

---

From: Christian Huitema <[email-masked]>
Date: Wed, 12 Sep 2018 11:06:24 -0700

@ianswett I agree that receivers could hamper senders' performance if they delay ACK too much. We should say that explicitly in the recovery draft. But sending ACKs too frequently also affects the senders' performance, and we should say that too. Bottom line, it is a balance.

We probably want to set default requirements for the number of packets before ACK and for the max ACK delay -- your arbitrary choices of 10 packets and 10 ms look as good as any, or maybe the min of that and 1/4th of the congestion window (for bytes/packets) or the RTT (for ACK delay), with something like at least two packets and 1ms as safe minimum. It would set a reasonable default. Anything else is dependent of the congestion control implementation at the sender, and probably requires cooperation between sender and receiver. That's what extensions are for.

But I do not think that adding this "byte limit" concept is useful, especially if there is no way to change it during the course of the connection.

-- 
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#issuecomment-420743987

---

From: ianswett <[email-masked]>
Date: Wed, 12 Sep 2018 11:10:25 -0700

As the receiver, you don't know the sender's congestion window, so fraction of RTT(ie: 1/4) is a more practical option I think.

2 packets and 1ms seem like reasonable minimum values.

-- 
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#issuecomment-420745256

---

From: Christian Huitema <[email-masked]>
Date: Wed, 12 Sep 2018 18:28:56 +0000 (UTC)

Actually, TCP implementation need to have at least a rough idea of the sender's congestion window. They use that to set the TCP flow control window. The equivalent in QUIC is the MAX DATA parameter; that too has to be set by the receiver using some kind of guess work. Granted, it is typically an overestimate, because receivers don't want to slow down the senders. But implementation could use that to derive kind of upper bound for the max byte value, or max packet value. If it gets fewer than 10 packets, then use that.

-- 
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#issuecomment-420751223

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Sep 2018 04:36:25 -0700

I think the first issue is that currently TPs are only negotiated at connection establishment. Which, makes it impossible to change them if one change MTUs due to PLPMTUD or a client side migration. 

I also agree that adding clarified recommendations on delayed ACK. I think one full RTT is a bit much delay when one have something to ACK. I am not certain I understand the full relation and precedens of the minimal, maximum etc. Here I think one should be careful to write up rules and analys their impact and what will happen in the various cases, with both really low RTTs (Backplane/loopback), as well as LANs and long fat pipes. In Kista we discussed that 1/4 of an RTT likely makes sense as an upper limit for sender stacks that accept delayed ACKs. 

-- 
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#issuecomment-421331903

---

From: ianswett <[email-masked]>
Date: Thu, 20 Sep 2018 16:10:53 -0700

Based on today's discussion, I'm closing this.

-- 
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#issuecomment-423363196

---

From: ianswett <[email-masked]>
Date: Thu, 20 Sep 2018 16:10:54 -0700

Closed #1715.

-- 
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#event-1858970368