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:16 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 81D02C17C536 for <l4s-discuss@ietfa.amsl.com>; Wed, 20 Dec 2023 09:16:54 -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_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 YyAA40dExlts for <l4s-discuss@ietfa.amsl.com>; Wed, 20 Dec 2023 09:16:50 -0800 (PST)
Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 AE39EC151991 for <l4s-discuss@ietf.org>; Wed, 20 Dec 2023 09:16:45 -0800 (PST)
Received: by mail-il1-x12e.google.com with SMTP id e9e14a558f8ab-35e70495835so28280935ab.3 for <l4s-discuss@ietf.org>; Wed, 20 Dec 2023 09:16:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703092604; x=1703697404; 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=1FnDcqnH9yJ0rIFfmlYhavIVPAmEatulDoJZoOiBtIA=; b=ETHwlZMoQEX4EMcJRTH7HftzuyHns+BpSijlui8WNYTrWd2SN6hyXm2Iy7vtA/+Ljo yZ2dSnJRViqBWUFoV6W3TM0GbdZrrM5KgLmZN2ReKKPzJJsHd9Q8yz2mpt8P3oaO7tg2 ILTh09eHVLkP0ANHFP3gTIg5D2R7X8jNyfovEQpOxAPQ7Jt0SxtT7ms1YjNBl3GV06C7 fSYkh/KesGMFj/Kt02uSE5Z79aVLXIGa0d9dhe4sv7ny41GPFAQxNBkuQD7pN/FUIfIk 4IyPrtBX2hsInyrxKDy/Wk/zzkQAGaO20z4hw2UI57XjoZ0sMIoCz4QMUamQv1xXetE/ IAIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703092604; x=1703697404; 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=1FnDcqnH9yJ0rIFfmlYhavIVPAmEatulDoJZoOiBtIA=; b=Qc8xLwxzDiAlcCi+yKGpE0OMU1Ld3D2/NNqyr07EXSMLVJLYwrKdIrsjSFaX67bdsG VHhL2+09AljZIXCb1F6qROcSNmGp5CC13Fm9EV8wthFA6x6yJMxEXJ1ZN6ySR9PYcheB OEVsVPgdjIA/yqZjnslGt+99uRymNuQyq1ksF/QO1MXoIDYFz09CCsav3j0gRcXhxFIb 7iyM5l9BJw2bo4a4UMlls/yNNsrta8aL0g4LOSHQddUPG64exouvwI3phGJkeWd4uX2e qtViC3AbvckK6Bhr6eEM21GZXGzs1SVFEmQ8vB8kMzVHYE3QZPq2qL58l4Ixgw04yrXL yhfA==
X-Gm-Message-State: AOJu0YyrWu6gl8YynkRLLkoQg8NnMEpYZpETJHMo9NO/lLKAszuPWZRM FGDOhlqQaxmU9cehtOjVFafVDLrhAr4NfYYS/cZkC2FPFw==
X-Google-Smtp-Source: AGHT+IH6T/I9ssWOBH9SJLuaY0BCfWT/It5dWXySgFabnva45xlOpK1rK1iICVsD3dfLhF3lcxNkG3l7BbLJOA7F3Bk=
X-Received: by 2002:a05:6e02:1706:b0:35f:ceb8:70b0 with SMTP id u6-20020a056e02170600b0035fceb870b0mr859342ill.0.1703092604497; Wed, 20 Dec 2023 09:16:44 -0800 (PST)
MIME-Version: 1.0
References: <CAHS2_A_U4YjN6Ezr15HukGzOSPPh50ZumNTeQ1R1D2B+z86Rrg@mail.gmail.com> <CADVnQy=7hWXHbOKxtB6PaYAjUEohNUU+-rddQ4+2Z1N8OfX_uw@mail.gmail.com>
In-Reply-To: <CADVnQy=7hWXHbOKxtB6PaYAjUEohNUU+-rddQ4+2Z1N8OfX_uw@mail.gmail.com>
From: Francis Rammeloo <francis.rammeloo@gmail.com>
Date: Wed, 20 Dec 2023 18:16:33 +0100
Message-ID: <CAHS2_A8GBOtxPho0uJ7ZDbXTYwDW4UBDfK4Y7Lta0J-UiT8axA@mail.gmail.com>
To: Neal Cardwell <ncardwell@google.com>
Cc: l4s-discuss@ietf.org
Content-Type: multipart/alternative; boundary="000000000000b5f4b1060cf425d1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/l4s-discuss/peGD_ydmQDaPpvprUhAENd7l1cM>
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:16:54 -0000

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