IETF Logo Mail Archive

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

Neal Cardwell <ncardwell@google.com> Wed, 20 December 2023 23:29 UTC

Return-Path: <ncardwell@google.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 A29B4C14F5F0 for <l4s-discuss@ietfa.amsl.com>; Wed, 20 Dec 2023 15:29:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.607
X-Spam-Level:
X-Spam-Status: No, score=-17.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, 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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 qDXq8FXsFX5P for <l4s-discuss@ietfa.amsl.com>; Wed, 20 Dec 2023 15:29:04 -0800 (PST)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 F3A98C14F5E4 for <l4s-discuss@ietf.org>; Wed, 20 Dec 2023 15:29:03 -0800 (PST)
Received: by mail-ot1-x334.google.com with SMTP id 46e09a7af769-6dbab240a9fso109914a34.1 for <l4s-discuss@ietf.org>; Wed, 20 Dec 2023 15:29:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1703114943; x=1703719743; 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=ghSYTLAFRP2emDLTCD7UhXxkjNc1Kt2/SiKlBC1ZNss=; b=e2OS8eognrItpRGpHA8Um0es1bt7QxfAUOZK3M5ivlYZzUsHbxYuU0CSzzFnCYdH8w iA+MNAHMxuL79INFioUb7qnQ31rmNm8AU7Q8jpt62N4A4sBs5jmJNwlxRAb8nb6VtTfW 3RDQx5woyUUa9t+vhIVUacGvNWrC6A61Dh1pwKzX/6M4v+WhF7EVgQpmBs5t7aKuJVEl 5COIQewO83cLxNQaxyuMqE3IJMV5r5xfQJM78BeCbxiBGLhiB/Pg2I0Udv4K/PhnpJhw HWyEYdTBFNh38qhSM+mYDx2UOPU56jSjBnAnTVy/TEhB8xZbnK8psxG3IZjh/zxDtwJl VQyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703114943; x=1703719743; 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=ghSYTLAFRP2emDLTCD7UhXxkjNc1Kt2/SiKlBC1ZNss=; b=ZZrlVk3eLlLN3ENMp04jpzvoULhhRedvrBQeABSqzjMNO2W6kiFbAHrpvbbQSNlNrJ XcgC9ZA7NGsGSAVq8psoChl47npoRhr4Ej4XMTbNn2ThhA90DJ8fr0oGIyYmos+T93HI 0HSWToOSV1/bQzMHqqBGZ8MqkKNXy2LlK+toMDKmdTXptfj69SycLdPACNlZLJDohO9l Ncaar7rKhEiW7CBkZB0+/YXMf4VLG0k8LDy7RopOyAf5/VdgcVi4H1UbKpF3CA3v8Hrq IhPvFywOFt52dJPnVq4wmu9YxhaNdlRvFB/0g4WcfVOLZoKuU9h8zNvT4moFo8+vuqYH vmhQ==
X-Gm-Message-State: AOJu0YweltHthukoBgHAb9ELIqcT5jP3BkhJaOmhfAyed1N0cO4x+iFm 6+ohY2S8Lvr2lZn5cCZsL/kr8cfGcbcoZE6URkh0zA==
X-Google-Smtp-Source: AGHT+IFtGIYOGz9jjH57jvvucDAWu+OceqI6vD9jFwovRqRYxBju+looCuIj0EP2q4m9GnmQdBi8HdZsWlvfzv3ey+g=
X-Received: by 2002:a05:6830:1da4:b0:6db:b744:6f28 with SMTP id z4-20020a0568301da400b006dbb7446f28mr61681oti.50.1703114943000; Wed, 20 Dec 2023 15:29:03 -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> <CAHS2_A_1DkZYqzM07BLR374bWnNEC55bYVowtdP2EzpUPN0OjA@mail.gmail.com>
In-Reply-To: <CAHS2_A_1DkZYqzM07BLR374bWnNEC55bYVowtdP2EzpUPN0OjA@mail.gmail.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Wed, 20 Dec 2023 18:28:41 -0500
Message-ID: <CADVnQyn0xPmDgW1bFih1PHdmTYu1OO8_r084KMRFGWS7ho180Q@mail.gmail.com>
To: Francis Rammeloo <francis.rammeloo@gmail.com>
Cc: l4s-discuss@ietf.org
Content-Type: multipart/alternative; boundary="00000000000030d3ed060cf9590c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/l4s-discuss/DEA64NqRTSxpyld7RjrejQ4SEQs>
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 23:29:04 -0000

OK, thanks for the context. Let's see what the Prague/L4S team members
recommend.

neal


On Wed, Dec 20, 2023 at 12:17 PM Francis Rammeloo <
francis.rammeloo@gmail.com> wrote:

> 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.27.8 | Report a Bug | By Email | System Status