Re: [L4s-discuss] Expected ACK ratios with accurate ECN ?

Hi
and thanks for the insight. One thing I did not mention is that we actually load the 5G cell with 5 UEs (= modems) running IPerf. Given that they have roughly the same radio conditions, each UE would get ~1.2Gbps/5 = 240Mbps. Given your calculation below then
0.24 * 10^9 / (1500*8) * .000250 ~= 5 packets
So perhaps 1:12 is quite reasonable after all?

/Ingemar

From: Neal Cardwell <ncardwell@google.com>
Sent: Tuesday, 9 January 2024 18:26
To: Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org>
Cc: l4s-discuss@ietf.org; Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Subject: Re: [L4s-discuss] Expected ACK ratios with accurate ECN ?

On Tue, Jan 9, 2024 at 2:32 AM Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org<mailto:40ericsson.com@dmarc.ietf.org>> wrote:
Hi

I wonder what ACK ratios one can expect with Accurate ECN ?.
In one 5G experiment with large file transfers we see a downlink throughput of 1.12Gbps and an uplink bitrate of 4Mbps, attributed to TCP ACKs.
The downlink is loaded close to 100% so one should expect quite frequent L4S marking.

IIRC the Prague sending rate is supposed to be roughly (1/p - 1) in Mbit/sec, where p is the ECN marking probability. So to reach 1.12Gbps the marking probability should be roughly 1/1120, which is quite low. So ECN marks should be rare and should not interfere with aggregation or change ACKs much.

4Mbps in UL and 65 byte ACK packets would mean 7600 ACKs/s
1.12Gbps in DL and 1500 byte packets would mean 93000 pakets/s
This implies an ACK ratio of 1:12. I think that this sounds reasonable, or ?
Regards
A ratio of 1:12 sounds reasonable to me for that workload. The Prague CC module tries to send bursts of 250us worth of packets:
  https://datatracker.ietf.org/doc/html/draft-briscoe-iccrg-prague-congestion-control-01#section-2.5.2

At 1.12Gbps that's roughly:
  1.12 * 10^9 / (1500*8) * .000250 ~= 23 packets
So if all layers are optimized perfectly then there should be about 23 data packets per ACK. So 12 data packets per ACK is pretty good. Perhaps the receiving  5G chip or driver or GRO coalescing behavior is passing batches of only 12 data packets per skbuff up to the receiving TCP layer (which TCP should then ACK immediately).

cheers,
neal

/Ingemar

====================================
Ingemar Johansson  M.Sc.
Master Researcher

Ericsson AB
GFTL ER Networks RNS Protocol & E2E Perf
Labratoriegränd 11
977 53, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289<tel:+46%2073%20078%2032%2089>
ingemar.s.johansson@ericsson.com<mailto:ingemar.s.johansson@ericsson.com>
www.ericsson.com<http://www.ericsson.com/>

  The past is never the past. It is always present.
       And you better reckon with it in your life
   and in your daily experience, or it will get you.
                  It will get you really bad.

                      Bruce Springsteen
=====================================

--
L4s-discuss mailing list
L4s-discuss@ietf.org<mailto:L4s-discuss@ietf.org>
https://www.ietf.org/mailman/listinfo/l4s-discuss