IETF Logo Mail Archive

Re: [tsvwg] Reasons for WGLC/RFC asap

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Thu, 19 November 2020 14:52 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
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 8247F3A08F6 for <tsvwg@ietfa.amsl.com>; Thu, 19 Nov 2020 06:52:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2kz23ngmrNk for <tsvwg@ietfa.amsl.com>; Thu, 19 Nov 2020 06:52:16 -0800 (PST)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4893A0937 for <tsvwg@ietf.org>; Thu, 19 Nov 2020 06:52:15 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 09E8025A12; Thu, 19 Nov 2020 15:52:14 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1605797534; bh=wNR+gjYQ7ZYaffpWnv5lrgbtQHkks5HElBS3KaxtHDQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=s21v3T45PItx2XT9e4MqUGeQW2djhVAaZBj6mjzqyBjxgI1hq+xzC3b1HtmEqVkgF cxFwHWWUXezRVNOInu2YLWkZkyUiU4Ns2SW8ZX6HDclrEvPlO5A3oPxSHb9vTKuF2J r8aCmZmIbrHmZJ9u+T3PtkpOjrnZjbOWzErcIFEc=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLZ2gKu3EH6C; Thu, 19 Nov 2020 15:52:13 +0100 (CET)
Received: from rznt8201.rznt.rzdir.fht-esslingen.de (rznt8201.hs-esslingen.de [134.108.48.164]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Thu, 19 Nov 2020 15:52:13 +0100 (CET)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8201.rznt.rzdir.fht-esslingen.de (134.108.48.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Thu, 19 Nov 2020 15:52:12 +0100
Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.1979.006; Thu, 19 Nov 2020 15:52:12 +0100
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: Lars Eggert <lars@eggert.org>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
CC: tsvwg IETF list <tsvwg@ietf.org>
Thread-Topic: [tsvwg] Reasons for WGLC/RFC asap
Thread-Index: Ada9kaHRGNO57vIZSgq7zPn1SuIYhAAOTueAABevugAACZ2GgAABCwiAAAUCZIAAASgXAAADrNuA
Date: Thu, 19 Nov 2020 14:52:12 +0000
Message-ID: <1b562fddb34c4ec6af791839e5a885dd@hs-esslingen.de>
References: <AM8PR07MB747626CB7622CB89209018A8B9E10@AM8PR07MB7476.eurprd07.prod.outlook.com> <5dff4f73463c2a7e7cc8dc8255ae9825e78f4c11.camel@petri-meat.com> <4FF8800F-B618-4818-AF5E-1E997EA9FBF3@eggert.org> <HE1PR0701MB2876C4FDA655284D4E563042C2E00@HE1PR0701MB2876.eurprd07.prod.outlook.com> <3EAC47AC-5937-4DB2-8B3C-D8C8A4459FBA@eggert.org> <HE1PR0701MB28761E448ACA1DAE0B2DCF56C2E00@HE1PR0701MB2876.eurprd07.prod.outlook.com> <F73E8DBB-0887-462C-ACC6-FA9212E50DF7@eggert.org>
In-Reply-To: <F73E8DBB-0887-462C-ACC6-FA9212E50DF7@eggert.org>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.140.248]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Fg9sQ3MDoJB1NDXgfBHUy-L8vY8>
Subject: Re: [tsvwg] Reasons for WGLC/RFC asap
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 19 Nov 2020 14:52:19 -0000

I won't comment on the question discussed here. This is just a small reminder not to forget pieces outside TSVWG...

> On 2020-11-19, at 14:36, Ingemar Johansson S
> <ingemar.s.johansson@ericsson.com> wrote:
> > The only way is see is that the L4S
> > drafts are moved to WGLC, then people will hopefully read the drafts and
> > come with requests for clarifications where needed. Until then you can
> only
> > expect more of the same long incomprehensible discussion threads until
> > March, when we will repeat the same process again.
> 
> to clarify: I don't have opinions about the L4S drafts. I haven't read them in a
> while, I agree that I should.
> 
> One point I am trying to make is that since the set of documents we are
> discussing seems incomplete, in that it doesn't seem to contain a TCP variant
> that intends to delivers benefits over L4S paths w/o regressions.
> 
> My main point though is that there seem to be questions raised about the
> performance and behavior of L4S with various TCP variants. This is not an
> issue with the content of the L4S drafts. It's a remaining uncertainty related
> to the experimental evaluation and analysis that the L4S mechanisms have
> seen so far. Going forward with a LC is not going to bring further clarity here.

As per draft-ietf-tsvwg-l4s-arch-08, "[...] the implementation of TCP receivers will have to be upgraded [RFC7560].  Work to standardize and implement more accurate ECN feedback for TCP (AccECN) is in progress [I-D.ietf-tcpm-accurate-ecn]".

draft-ietf-tcpm-accurate-ecn is a WG item in TCPM targeting standards track. In order to finish draft-ietf-tcpm-accurate-ecn, TCPM needs reviews and feedback. For instance, recently the encoding of the TCP option changed. IMHO would be important to understand whether the solution now addresses all known needs.

Has everybody who plans to run or runs TCP-based experiments with L4S already reviewed draft-ietf-tcpm-accurate-ecn? If not, why not?

Please feel free to post comments regarding draft-ietf-tcpm-accurate-ecn on tcpm@ietf.org.

Michael

v2.23.0 | Report a Bug | By Email