[tcpPrague] Prague Cwnd reduction in CWR state

Deepak K <deepakkavoor99@gmail.com> Fri, 14 August 2020 19:06 UTC

Return-Path: <deepakkavoor99@gmail.com>
X-Original-To: tcpprague@ietfa.amsl.com
Delivered-To: tcpprague@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5A9963A11E0 for <tcpprague@ietfa.amsl.com>; Fri, 14 Aug 2020 12:06:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cXsYEl08eTE3 for <tcpprague@ietfa.amsl.com>; Fri, 14 Aug 2020 12:06:57 -0700 (PDT)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF943A11E3 for <tcpprague@ietf.org>; Fri, 14 Aug 2020 12:06:56 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id t7so8416388otp.0 for <tcpprague@ietf.org>; Fri, 14 Aug 2020 12:06:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=LRlEeGt6vdxaoNqa05QycXFUM7kh1wSqCR6jqRRjpNA=; b=h3ZeuqaQ11fDwsHobj8Yl2iX9KUCWCfLT6vbxLmjPEBCoRSPo63cwPGNZ3fTiKpWwI pqcWswJ+kcxE4Fw5umfwaCnShSEMvbaS4C2frCwKzVoMR6WeIYWfQoOJ+qIeFQ6rtD1b SIyWIJSX0UNiau5BKRoQDrbOxwJOitGofM9UTZS4fMT8tcNm73egG+ldrCBEA2DKxV7b tqaJNPPFBty5pLkKmbW6soUSQGCuNBVpVKpbCJhCRawa5o9Po4N2m1FfB9zYQO1zrYpw pxsdNI7qJFSituGaimwws8GHmhKTWi/3MUzc2F/7AZKOiOiMNU34BZYTd4R3Ca2DSbvh lPHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LRlEeGt6vdxaoNqa05QycXFUM7kh1wSqCR6jqRRjpNA=; b=RSpGIgq0NlXXVI5XFgeNWPEkZyFzQ0x0ep65NzlgGbrmePBLUGWyGvH7Cc3Xi0PBds TCWpPA+YzBfXaNTt9GDDh1rHE4L1gilQNyu1suNzyGGVoAuO6HjtyKEQf4TkWwuaUuxr 8Jpqlyi09sJYS+Qh3tQ+gDtmh4lwQdRgYToB3uPJi5Pf5zOs4BjJXG8Arwh1pNCMBxJw owVJV7UHXByfQdEjCs/gHZ8g85pxtEMJQuyA/VG6A5VlNYwvW+TrQbjLPXGTYpwlbSjA xH6Bxlm+i/J81UIyc3zg1r+diWZl7IvUAfW5A5Sl1yTjf5FJLP22mjsAJMpKd8AZBdYX zpXg==
X-Gm-Message-State: AOAM5314bO1b9qKt0A2v4IrjToU3IHkFNJnA8Mc+oX6reFjuUhTpOkhr j72Th3QdJcRdgMEgCQSEuxmfuPSZtU0WpiCz+beimDELB/vi8A==
X-Google-Smtp-Source: ABdhPJwHdwb20UzdJx7oBbQFzKOutqR/NnfaJnZ0Vu+2dKEPD96ETElfgsGa0DGPwJEYNhS+vhLwP/aiEpScEMxQbhk=
X-Received: by 2002:a9d:4704:: with SMTP id a4mr2748374otf.349.1597432015856; Fri, 14 Aug 2020 12:06:55 -0700 (PDT)
MIME-Version: 1.0
From: Deepak K <deepakkavoor99@gmail.com>
Date: Sat, 15 Aug 2020 00:36:09 +0530
Message-ID: <CAL8XqGpw0O-Yiw22vCNbAkUdS-Nu6WVaGLakiaVMLDSqnPjijw@mail.gmail.com>
To: tcpprague@ietf.org
Content-Type: multipart/alternative; boundary="000000000000dbae8005acdb1fbc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpprague/IOitgfmuSU5auBhlK7YgW4fGSAg>
Subject: [tcpPrague] Prague Cwnd reduction in CWR state
X-BeenThere: tcpprague@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <tcpprague.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpprague/>
List-Post: <mailto:tcpprague@ietf.org>
List-Help: <mailto:tcpprague-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpprague>, <mailto:tcpprague-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Aug 2020 19:06:59 -0000

Hi everyone,

I am currently trying to align TCP Prague in the ns-3 network simulator
with that of Linux.
In the process, I came across an interesting behaviour: if the sender is in
a CWR state, the cWnd update would look something like
cWnd = cWnd - cWnd * alpha / 2     --- (1)
I noted that this is how DCTCP updates its cWnd in Linux.

But in the case of current Linux Prague code, the value
reduction = cWnd * alpha / 2           --- (2)
is subtracted from the cwnd_cnt variable, which sort of acts as a cushion
and reduces the cWnd over many RTTs (in prague_update_cwnd( ) ), instead of
reducing it instantaneously.

I would like to mention a noticeable difference resulting from the approach
taken in (2). All the following simulations were carried out in ns-3.

While reproducing the single-flow topology from Pete Heist's scenario (
https://github.com/heistp/sce-l4s-ect1#scenario-1-one-flow : a Prague
sender, DualQ bottleneck and a Prague receiver), I decided to implement
both approaches in ns-3 to see how they differ from each other.

For lower bottleneck bandwidths (5mbps and 50mbps in the scenarios), I
didn't observe much difference between (1) and (2), and the approach in (1)
aligned with the cWnd graphs from Linux (which I obtained separately via

However, for the scenario with a higher bottleneck speed - 250mbps in
particular, the difference between (1) and the Linux approach (2) was
With (1), the cWnd was reduced by a smaller value when compared to (2), in
ns-3.This meant that (2) took more time to reach a stable value in Additive
Increase compared to (1). I also observed that cWnd reduced to a much lower
value in Linux (again, graphs obtained via namespaces) when compared with
the ns-3 plots from (1).

My guess would be that in (2), since cWnd is decreased gradually, the
sender would not immediately relieve the queue of congestion, and hence
would receive few more ECE marks leading to further reduction later on when
compared to (1).

I noted this behaviour for both higher (80ms) and lower (20ms) values of
RTT, with a 250mbps bottleneck.
Could you comment on the reason for choosing approach (2) in Linux instead
of (1)?