Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on ACKing ACKs with good cause

[Neal Cardwell <[e-mail]>]

On Sun, Jul 11, 2021 at 11:55 AM Christian Huitema <[e-mail]>
wrote:

>
>
> > On Jul 11, 2021, at 4:42 AM, Bob Briscoe <[e-mail]> wrote:
>
...

> > The implementation will have its own ACK ratio - that's out of scope of
> AccECN, except to set this max of 6 CEs, which is to mitigate wrap of the
> 3-bit counter of CE-marks (which in the worst case of 100% marking in the
> data direction could then induce 1 ACK per 6 packets). This shouldn't limit
> forward performance, because it only increases the reverse ACK rate if
> there is heavy congestion in the forward path, when the Data Sender should
> be reducing the forward rate anyway.
>
> 1 ACK per 6 packets would cause performance issues on high speed links.
> Common setup is "4 to 8 ACK per RTT", which means intervals much larger
> than 6 packets.


I share this concern about the AccECN requirement of one ACK per 6
CE-marked data segments potentially causing performance issues with
high-speed links. Today, with most high-speed last-hop link technologies
(wifi, cellular, Ethernet) TCP receivers often receive (from lower layers
of the hardware and software networking stack) large aggregates  (often up
to 64KBytes or around 44 packets), and generate a single ACK for that
aggregate. AFAICT changing this scenario to require 1 packet per 6
CE-marked data segments means that during CE-marked scenarios receiving
such an aggregate would require ceil(44/6) = 8 ACKs, increasing the number
of ACKs by up to 8x.

I have two main concerns in that scenario:

(1) CPU load: This seems like it would impose much higher CPU load on the
data receiver, at just the moment when the receiver may already be under
stress due to receiving data near the maximum rate of the link.

(2) Congestion and ACK loss: This requirement for generating up to 8 ACKs
per aggregate seems like it is likely to produce a tight burst of 8 ACKs,
which is going to increase congestion and increase the odds of losing at
least one ACK, which is going to cause accuracy problems for "Accurate"
ECN. :-)

I understand that this proposed "ACK per 6 CE-marked data segments" rule is
necessary to avoid issues with the 3-bit ACE field wrapping. So IMHO this
is one of the good arguments against including the ACE field in the AccECN
design.

The other main concerns I have with the ACE field are:

o Complexity

o Redundancy with respect to the AccECN counter options

o Potential problems with middleboxes

o Known problems with NICs and drivers (based on Ilpo's nice talk, "Accurate
ECN Linux Implementation: Experiences and Challenges", at the April 2020
TCPM interim meeting)

I realize that if AccECN does not have the ACE field feature, then AccECN
and TCP L4S will not be usable on paths with middleboxes that strip the AccECN
counter options. But IMHO living without the ACE field is preferable. IMHO
it's acceptable to say that L4S can only be used with (a) QUIC, or (b) TCP
connections where no middleboxes are stripping AccECN options.

cheers,
neal