Hi Vihdi and thanks for reply. Yes there could be a benefit for the case that you describe and RFC8888 is used for that purpose in the implementation of SCReAM as the true amount of acked and "acked and marked" bytes is used in the congestion avoidance part.
I beliveve that it would actually be relatively easy to hack the SCReAM code so that it bases the congestion avoidance on acked and "acked and marked" packets instead, to see what the impact on performance is. /Ingemar PS: I will be a remote attendee next week. From: Vidhi Goel <vidhi_g...@apple.com> Sent: Thursday, 14 March 2024 23:17 To: Ingemar Johansson S <ingemar.s.johansson=40ericsson....@dmarc.ietf.org> Cc: martenseem...@gmail.com; quic@ietf.org; Ingemar Johansson S <ingemar.s.johans...@ericsson.com> Subject: Re: Question on draft-seemann-quic-accurate-ack-ecn-00 Hello Ingemar, Having been implemented Prague myself, this is mainly to get more accuracy around doing increase for non-marked bytes during congestion avoidance. Currently, we have no way of knowing that as we only know that some N packets were not CE marked but we don’t know which ones. If you see the example that I added in the draft, with the change proposed, an implementor can exactly know which packet was received with which code point. This way, one can map the packet to packet size at the sender and accurately compute non CE marked bytes. This is quite useful to do more accurate increase for cwnd to stay closer to the link capacity without building any excessive queues. It may look like the change has subtle impact but with a large number of flows sharing the bottleneck, it definitely has impact on how tightly we control the increase in queuing delay. Happy to discuss this during IETF. Thanks, Vidhi On Mar 14, 2024, at 7:21 AM, Ingemar Johansson S <ingemar.s.johansson=40ericsson....@dmarc.ietf.org<mailto:ingemar.s.johansson=40ericsson....@dmarc.ietf.org>> wrote: Hi Marten + others I read through the draft https://datatracker.ietf.org/doc/draft-seemann-quic-accurate-ack-ecn/ Given that this adds more complexity than the default ECN counters, could you elaborate a bit more around which partcular cases where it would be beneficial with your proposed ECN feedback? Regards /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 ingemar.s.johans...@ericsson.com<mailto:ingemar.s.johans...@ericsson.com> www.ericsson.com<http://www.ericsson.com/> The right to be ridiculous is something I hold dear... U2 =================================
