From 41fdd5c287285a0da5aff2f953915f0d0140f12a Mon Sep 17 00:00:00 2001 From: Dimitri Staessens Date: Wed, 16 Dec 2020 20:28:03 +0100 Subject: content: Some fixes in congestion blog post --- content/en/blog/news/20201212-congestion-avoidance.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) (limited to 'content/en') diff --git a/content/en/blog/news/20201212-congestion-avoidance.md b/content/en/blog/news/20201212-congestion-avoidance.md index 3f3b083..f395a4f 100644 --- a/content/en/blog/news/20201212-congestion-avoidance.md +++ b/content/en/blog/news/20201212-congestion-avoidance.md @@ -148,16 +148,16 @@ The algorithm is based on the workings of DataCenter TCP (DCTCP). Before I dig into the details, I will list the main differences, without any judgement. -* The rates for additive increase and slow start are the same - _constant_ for all flows (but could be made configurable for each - network layer if needed). This is achieved by having a window that - is independent of the Round-Trip Time (RTT). This may make it more - fair, as congestion avoidance in DCTCP (and in most -- if not all -- - TCP variants), is biased in favor of flows with smaller RTT[^1]. +* The rate for additive increase is the same _constant_ for all flows + (but could be made configurable for each network layer if + needed). This is achieved by having a window that is independent of + the Round-Trip Time (RTT). This may make it more fair, as congestion + avoidance in DCTCP (and in most -- if not all -- TCP variants), is + biased in favor of flows with smaller RTT[^1]. * Because it is operating at the _flow_ level, it estimates the _actual_ bandwidth sent, including retransmissions, ACKs and what - not from protocols operating on the flow. DCTCP estimates bandwith + not from protocols operating on the flow. DCTCP estimates bandwidth based on which data offsets are acknowledged. * The algorithm uses 8 bits to indicate the queue depth in each @@ -188,7 +188,7 @@ outgoing queue depth. The current minimum queue depth to trigger and ECN is 16 packets (implemented as a bit shift of the queue size when writing a packet). We perform a logical OR with the previous value of the packet. If the width of the ECN field would be a single bit, this -operation would be identical. +operation would be identical to DCTCP. At the _receiver_ side, the context maintains two state variables. -- cgit v1.2.3