IETF Logo Mail Archive

Re: [tsvwg] draft-ietf-tsvwg-l4sops: recommend ABE as "Classic" ?

rs.ietf@gmx.at Mon, 03 April 2023 11:01 UTC

Return-Path: <rs.ietf@gmx.at>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3B8C151B2F for <tsvwg@ietfa.amsl.com>; Mon, 3 Apr 2023 04:01:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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=gmx.at
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 jInLIR9Uv_aP for <tsvwg@ietfa.amsl.com>; Mon, 3 Apr 2023 04:01:38 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728CDC151B2B for <tsvwg@ietf.org>; Mon, 3 Apr 2023 04:01:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at; s=s31663417; t=1680519690; i=rs.ietf@gmx.at; bh=78kDa44xDd9J67dVQhNRfw+thGm4o5USVG59HblzafA=; h=X-UI-Sender-Class:Date:From:Reply-To:Subject:To:Cc:References: In-Reply-To; b=JGofzgzcYfireIFyVH9aswX/baxwhtgZrAvVKFMdhZ9uU0iJcBTTDP4Bu3xvwK6Le 11mYrN4YGbLDmEdasipaKrTn2ShM8wH2izjHavAsorAzXknG2HIPTSBbTecJ+AMU+8 ZFU1hGzv36kXFqiqJzr2aObQ4ZvzBAoYjUkqNvC5YdWsICIYUeAnWmQI19N7hPutDy LwRxVif9CRoZSlB+7fLTrWMcLr0GTSPslY7VglSneCvWMX6vgvvnEjtye700l6REcT e1vtD5DbTMgnK9Jv/OQMY5wk/lOVQdYGtCvo77QPYDHX9TPFBqFOrY15ZiRP5zFXB5 NBWwhfDluHv8w==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [10.67.132.250] ([217.70.210.46]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MtOGa-1qYNUN3cx4-00utd6; Mon, 03 Apr 2023 13:01:29 +0200
Message-ID: <dc20cabd-ee8d-c2d7-486c-a6a90836a37c@gmx.at>
Date: Mon, 03 Apr 2023 13:01:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1
From: rs.ietf@gmx.at
Reply-To: rs.ietf@gmx.at
To: Sebastian Moeller <moeller0@gmx.de>, Michael Welzl <michawe@ifi.uio.no>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <2B006693-0F0C-4341-806E-6FE98890E6FA@ifi.uio.no> <BC136BC3-673B-4ABE-98D4-92C9BB6AD4CA@cablelabs.com> <CBC2A493-879C-4F9B-B6CE-D94A6D8C9DB1@ifi.uio.no> <A3530965-2622-4B7E-ACFB-7339325A21D3@gmx.de>
In-Reply-To: <A3530965-2622-4B7E-ACFB-7339325A21D3@gmx.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:l1kXe/NuE0FsvV6oearaPmj/Fel7T6ZfEub/dunrP0Xr7b9Y489 hoyH0YeKHG/E8+4tLSlciWqZwWDUFwEWLbzyOhsftnE7lastLV3R5sVH86ZaBR/GtrG5e9R MHj/pphHtlbhfTTK76NuTsO7joHCoSkEGvtHx+nqMcHoOT1/4Ecgj/MRbn98H6g4PtR9slf 0WHdX0X6ljCgpQFd/JQ4A==
UI-OutboundReport: notjunk:1;M01:P0:1V2D9h3y0p4=;Rew+zIEruG88eEbKXldLLUOZbfG wtSq6Uexw3nWOSTIcERNq69SqN/YnBZV8sn7SlKXJLaPp2jKvGtrEEYf5/2aD3tGd5y9fV2X5 yH545NvfrCMQKywdM6BQzCBJMosPwsGMpGGE62TlAEDM6Rh1kDzb2BuxPS7gkMzI9+ihISRCm LEwbkOmy3itL54ffIDUjEeoPqZYL2p6ymKi1uKmPAnXYYJRZzIL5njr6kIvv/WVRVeD3FuqAj aNVcBQaY6te/C5My1iW6kS2OWrUhwKz4og0OkwDP8UIAwjfxQS2fHq1ktuWQJYJGf9MdY9SpD zUAW6EPZboZLtzR+36Nkpzi5zDPwrhDCUJ5ii5ldCP//4uhgz53ehWq9PV0j3GARzm71VNLoj xfsPessgGW18o5HQuyp43tD3++27N1bz5pR/EQpvK3HWEMR+/zxCtQxoInTiKgMzRuXNYLUXr YcnhYhY/0I4IMyltG7J1j9TV6Hg/QC3GEXRHDsV6ijciGY6vDFSDtwfVQBAymPFC6hEYnPNlc /X8uSNe6rGAadBgcpwNoZ/aRvyXJRl0QpYS/9NN7bunVZE4eeRderQsZrvRbdAjPpEEySpYfg sSy21uMrlvKMQ5V0sDRLOzfouTJuEDNEFM49xmyT1k6s9rRL2YVGDk6li1oaGC78rUwZ1dshj F9wGkQpbc9RhGwpvUwEAbwKVzJnbLx5ooiOW6QjD3SdGoCzF3CWRoRh/eW58bId9IDl3Z2t7s MVo6X9RWOQvPcYVK3uKHdou9jtppnJpN9lVdqEaE8EY6uLb04Kg89Fq8qed8ApsXr1N7xTjGy 3oYS4JThu+Qaw2txE28yzN6A32X+1uAv/05gLYD5DQg3yMNc51ZfIoJUSlPn1r5AzOiGI6VFT uO9fKFtVP7cwxdzZCqqGetjD+EB9ug5ePC6yKR38xNlnIDhgz6ODnQemGeMln6mO2zygPAg82 6PdTEg7YQO3SToldFT5EWK/f/ZI=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/uWpjpwvrF-230pfFAxqDXzxCOtA>
Subject: Re: [tsvwg] draft-ietf-tsvwg-l4sops: recommend ABE as "Classic" ?
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Apr 2023 11:01:43 -0000



Am 02.04.2023 um 14:03 schrieb Sebastian Moeller:
> Hi Michael,
>
>
>
>> On Mar 25, 2023, at 21:56, Michael Welzl <michawe@ifi.uio.no> wrote:
>>
>> [ NOTE to everyone: below Greg’s asking for the group consensus on whether the l4sops draft should recommend falling back to ABE (RFC 8511).  Please don’t miss this - please speak up ! ]
>
> 	Good question. RFC 8511 is experimental track so recommending it or not seems to both be acceptable ways forward. Reading "Alternative Backoff: Achieving Low Latency and High Throughput with ECN and AQM" I get a feeling that this is mostly motivated by keeping single flow utilization over long paths high (correct me if I am wrong). As well as by the intent of making ECN usage more attractive by giving it a noticeable.
> 	Given that ABE is an experiment, any updates on how this works over the existing internet and whether it has side-effects?
>
> Regards
> 	Sebastian
>
> P.S.: Even though other TCPs apparently stopped doing that I like how Reno's half the congestion window mirrors the "increase the congestion window every RTT" during slow start, but that is hardly a scientific argument.

FWIW:

On that note - I recently saw a trace, where cubic was doing worse
across a really shallow buffer switch, compared with newreno. One aspect
there appears to have been the fairly significantly larger cwnd while
SACK loss recovery was going on, leading to subsequent lost
retransmissions (which many modern stacks can detect and re-retransmit,
despite this never having been part of any RFC document really).

So, yes, there are specific cases, and a factor 0.5 of cwnd at the end
of traditional slow-start appears to be among them...

Regards,
   Richard

v2.23.0 | Report a Bug | By Email