Subject: Re: [quicwg/base-drafts] Byte counting at Congestion avoidance (#3917)

From: kouameboris <[email-masked]>
Date: Wed, 12 Aug 2020 02:19:40 -0700

I would like to ask a question about quiche's congestion control algorithms.
Is there an algorithm that uses ECN marking to detect or control congestion?

-- 
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/3917#issuecomment-672759081

---

From: Junho Choi <[email-masked]>
Date: Wed, 12 Aug 2020 09:43:00 -0700

> Is there an algorithm that uses ECN marking to detect or control congestion?

@Blandine11 If you have a quiche-specific question please open a new ticket on https://github.com/cloudflare/quiche/issues.

-- 
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/3917#issuecomment-672986483

---

From: Junho Choi <[email-masked]>
Date: Fri, 28 Aug 2020 17:36:28 -0700

@junhochoi commented on this pull request.

> +      bytes_acked += acked_packet.sent_bytes
+      if (bytes_acked >= congestion_window):
+        bytes_acked -= congestion_window
+        congestion_window += max_datagram_size

I implemented ABC for cubic in quiche https://github.com/cloudflare/quiche/pull/624 and did some evaluation:
Measured using quiche apps (quiche-server and quiche-client) in 5mbps/60ms rtt/0% loss. Also last highlighted row is when I changed MAX_DATAGRAM_SIZE to 1350 to match with what quiche apps use (quiche has MAX_DATAGRAM_SIZE constant). 

![Screen Shot 2020-08-28 at 5 21 49 PM](https://user-images.githubusercontent.com/1229714/91624295-43120300-e954-11ea-8559-9028131dbfdb.png)

You can see it can save some amount of sent packets (3.8% for cubic, 6.7% for reno, 9.3% for cubic and 1350 mss aligned) with slightly faster download time.

I think it's up to editors for deciding to merge this PR not, but I believe it's good for implementers to start with less issue.

-- 
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/3917#discussion_r479584623

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 28 Aug 2020 18:23:49 -0700

@janaiyengar commented on this pull request.

I'm surprised to see these differences, @junhochoi -- why are the lost packets so different? Why's there any loss when the network has 0% loss?

-- 
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/3917#discussion_r479590127

---

From: Junho Choi <[email-masked]>
Date: Fri, 28 Aug 2020 18:40:31 -0700

@janaiyengar it's basically loss by congestion. e.g. https://blog-cloudflare-com-assets.storage.googleapis.com/2020/05/cubic-hs.png (cubic+hystart case). All values are median number over 10 run. And lost packet here is the number of lost packets detected by quiche sender, so actual packet loss may be lower than 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/3917#discussion_r479591757

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 31 Aug 2020 11:29:27 -0700

Are these controlled at the bottleneck or is this uncontrolled loss on the Internet? The number of packets lost seem quite different, and I'm trying to understand why those loss numbers are so different.

-- 
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/3917#discussion_r480310156