IETF Logo Mail Archive

Re: [L4s-discuss] Entering CWR state during the loss recovery algorithm (NewReno, SACK)

Francis Rammeloo <francis.rammeloo@gmail.com> Wed, 20 December 2023 17:17 UTC

Return-Path: <francis.rammeloo@gmail.com>
X-Original-To: l4s-discuss@ietfa.amsl.com
Delivered-To: l4s-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F7AC17C536 for <l4s-discuss@ietfa.amsl.com>; Wed, 20 Dec 2023 09:17:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZ77DppPVKKe for <l4s-discuss@ietfa.amsl.com>; Wed, 20 Dec 2023 09:17:58 -0800 (PST)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C11DC151991 for <l4s-discuss@ietf.org>; Wed, 20 Dec 2023 09:17:58 -0800 (PST)
Received: by mail-qt1-x834.google.com with SMTP id d75a77b69052e-42793591b7fso776211cf.2 for <l4s-discuss@ietf.org>; Wed, 20 Dec 2023 09:17:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703092677; x=1703697477; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=apYb0VwHZsqjAFsx8qAY0lAYeyVwYzUWoW0ufEV3R9Y=; b=XPxc9i4950KzM/nl2EkKbRkVtjYv4W6ii1J/e7VVOfXLl3nNS0VqpJN2M8lMugdJfO 7jojlEpiFf/2mrED3663lmRjynoSVxe0ibCfJbiX8/YE5tCasWCUkW0E0cMICvRkyBjN 6zCiQZyVjIVVN/Hzz+MHl8WmD82FJT1UzPzYIbqDh/5ci/56OJqG7TbSOEmo/xm7gS+X vlT80WsH6LjWqLQPbaDHtdm7FAt8zahbHeeGnug68kXNxCQM29Gax9V68WBTsouO+RQr pkSXCa4D2+PW88OvT5W4ttlge2Odx4lwefBMeiaseczXz6AvpZ6xmN2kpxfprHpDHn60 u0Nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703092677; x=1703697477; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=apYb0VwHZsqjAFsx8qAY0lAYeyVwYzUWoW0ufEV3R9Y=; b=giFrFvJEdK6gqCRWEB7QXA0mPjWtiOBl+fr1iKcLXrn4EC1KHJRRGsjx8SsvEROlWI c8vpWAc/bU71ywZzhU7YwuYk0tkl0KLcY94u53a841lAzVxY8jwgn97xMeAehjHwH+6g feJXFzqPV6DFPD3e0tcc3ADLlnUijcts01H9kJCICwPp1KgZh+8Zrue0ZnCrPmALcc3t 5viZ7r4a5YJZP58biMFH9E7ch++lImNo1Kx4DCTKNBAJVxoS1fKrNJFWd7xGYRiodCuh tJhf5EkqFzPbp/BFkZFeS3lcsfrzIqd38eBJ6H8emNeE1Vvhcq3qDtjZgEml8xdafVmT DCgw==
X-Gm-Message-State: AOJu0YyKF3KM2BrgzrzKcRwoobGH8BhGC4VZN3EFHjrYB1FjIdXgNiAM sVO6OQDM9+4i3StTInu94sl26ytlqe37ghX7KCuJe30=
X-Google-Smtp-Source: AGHT+IFr0u1RPMwPb05ryUCAJ6Fi7zTf2NLroo59s6K3eSYR0vXngk9zbYjd0Rum+NPnbU8PJAYFIXwR80Uey5jbAww=
X-Received: by 2002:a05:6e02:1d86:b0:35f:ceb8:70a8 with SMTP id h6-20020a056e021d8600b0035fceb870a8mr760036ila.51.1703092656681; Wed, 20 Dec 2023 09:17:36 -0800 (PST)
MIME-Version: 1.0
References: <CAHS2_A_U4YjN6Ezr15HukGzOSPPh50ZumNTeQ1R1D2B+z86Rrg@mail.gmail.com> <CADVnQy=7hWXHbOKxtB6PaYAjUEohNUU+-rddQ4+2Z1N8OfX_uw@mail.gmail.com> <CAHS2_A8GBOtxPho0uJ7ZDbXTYwDW4UBDfK4Y7Lta0J-UiT8axA@mail.gmail.com>
In-Reply-To: <CAHS2_A8GBOtxPho0uJ7ZDbXTYwDW4UBDfK4Y7Lta0J-UiT8axA@mail.gmail.com>
From: Francis Rammeloo <francis.rammeloo@gmail.com>
Date: Wed, 20 Dec 2023 18:17:25 +0100
Message-ID: <CAHS2_A_1DkZYqzM07BLR374bWnNEC55bYVowtdP2EzpUPN0OjA@mail.gmail.com>
To: Neal Cardwell <ncardwell@google.com>
Cc: l4s-discuss@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d237ca060cf428e8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/l4s-discuss/0506xcM2F7VmmvY3fZwqOKR7VIk>
Subject: Re: [L4s-discuss] Entering CWR state during the loss recovery algorithm (NewReno, SACK)
X-BeenThere: l4s-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Low Latency, Low Loss, Scalable Throughput \(L4S\) " <l4s-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l4s-discuss>, <mailto:l4s-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/l4s-discuss/>
List-Post: <mailto:l4s-discuss@ietf.org>
List-Help: <mailto:l4s-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l4s-discuss>, <mailto:l4s-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Dec 2023 17:17:59 -0000

Oh, yes, using AccurateECN.

Op wo 20 dec 2023 om 18:16 schreef Francis Rammeloo <
francis.rammeloo@gmail.com>:

> Hi Neal,
>
> This is an in-house TCP implementation that runs in a user space program
> on Linux. The congestion avoidance algorithm can be Cubic or "Reno"
> (referring to the window growth strategy) combined with SACK or NewReno for
> the packet loss recovery. Prague can also be enabled independent of the
> previous options. I know Linux requires choosing between Cubic and Prague,
> but technically they can be combined. My current implementation of Prague
> is according to the latest RFC (October 2023).
>
> Best regards,
> Francis
>
> Op wo 20 dec 2023 om 17:57 schreef Neal Cardwell <ncardwell@google.com>:
>
>> Hi,
>>
>> For context, can you please describe the transport
>> protocol, OS/library/implementation, congestion control algorithm, and ECN
>> flavor (RFC 3168 or L4S) you have in mind? I ask because most of these
>> behaviors you mention don't match the Linux TCP Prague behavior when using
>> L4S ECN (which I would imagine would be the default scenario discussed on
>> the l4s-discuss list, though perhaps not?).
>>
>> best regards,
>> neal
>>
>> On Wed, Dec 20, 2023 at 10:03 AM Francis Rammeloo <
>> francis.rammeloo@gmail.com> wrote:
>>
>>> During loss recovery, the CWND is strictly managed by NewReno/SACK. For
>>> example NewReno "inflates" the CWND to allow sending new packets in
>>> response to duplicate acks and when the recovery is complete CWND is set to
>>> SSTHRESH. If CWR is entered during loss recovery then this could interfere
>>> with the loss recovery algorithm. Also when the loss recovery is complete
>>> it will set the CWND to SSTHRESH, so the reduction by CWR can become undone.
>>>
>>> Should entering CWR be "disabled" during loss recovery?
>>>
>>> Greetings,
>>> Francis
>>>
>>>
>>> --
>>> L4s-discuss mailing list
>>> L4s-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/l4s-discuss
>>>
>>

v2.35.0 | Report a Bug | By Email | System Status