Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-12.txt

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Wed, 28 October 2020 15:56 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425173A03FA for <tcpm@ietfa.amsl.com>; Wed, 28 Oct 2020 08:56:03 -0700 (PDT)
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 frcBK_c_hjMr for <tcpm@ietfa.amsl.com>; Wed, 28 Oct 2020 08:56:00 -0700 (PDT)
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 253603A03F4 for <tcpm@ietf.org>; Wed, 28 Oct 2020 08:55:59 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 3C62A25A12; Wed, 28 Oct 2020 16:55:58 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1603900558; bh=Sd+ggwKtE4TT3VhfqX40X/s96OZgELfQdJWqKiQTP78=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=fSGVlkWtvOpf02MoLKjtHIDb1tSU9masCLh57lsqwSPlOINL4iIUd7u8BwGcvJtvk t8rzIB5osQCyoTpZDD7pcxMhDdjNz7+oxgmeV/kw4Bp4k0AA6ghwrPzIG0CCMMOJTP zh4XjejIxeaDnRlfTKWVoGzdYl4ZR5yBUkhvE8qk=
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 WL1OO9ihO6CS; Wed, 28 Oct 2020 16:55:57 +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; Wed, 28 Oct 2020 16:55:57 +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; Wed, 28 Oct 2020 16:55:56 +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; Wed, 28 Oct 2020 16:55:56 +0100
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: Bob Briscoe <in@bobbriscoe.net>, "tcpm@ietf.org" <tcpm@ietf.org>
CC: "Scheffenegger, Richard" <Richard.Scheffenegger@netapp.com>, Mirja Kuehlewind <ietf@kuehlewind.net>
Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-12.txt
Thread-Index: AQHWrSirbyhXzTEgHki+65A0IwlFJqms6mOAgAA0Y5A=
Date: Wed, 28 Oct 2020 15:55:56 +0000
Message-ID: <3c8de57b23994824b6c51cf5d7fba7ec@hs-esslingen.de>
References: <160388925181.18695.7892567372446756190@ietfa.amsl.com> <4017c549-ac6d-d633-6432-20a6a8a9a342@bobbriscoe.net>
In-Reply-To: <4017c549-ac6d-d633-6432-20a6a8a9a342@bobbriscoe.net>
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/n6YkgGrr2bMkw1ujfg70ETBqVtE>
Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-12.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Oct 2020 15:56:03 -0000

Hi Bob,

What is the future plan regarding the option encoding proposed by the authors?

This has been discussed in past meetings and on the list, for instance: https://mailarchive.ietf.org/arch/msg/tcpm/zo-1OR0nRfhHocX8yvTvpC4BNMo/

I have explained several times my pushback against the encoding currently described in the document, most notably the requirement to keep state in the endpoints to decode the format of a TCP option. I have not changed my mind.

I have also mentioned that, for instance, two option codepoints would IMHO be a better engineering approach ("KISS principle"). That would be a very simple change to the content to the document. Needless to say that there are other alternatives for marshalling parameters in an unambigous way.

There have been other related comments, e.g. from Ilpo.

Best regards

Michael (with no hat)

> -----Original Message-----
> From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Bob Briscoe
> Sent: Wednesday, October 28, 2020 2:04 PM
> To: tcpm@ietf.org
> Cc: Scheffenegger, Richard <Richard.Scheffenegger@netapp.com>; Mirja
> Kuehlewind <ietf@kuehlewind.net>
> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-12.txt
> 
> TCPM folks,
> 
> Back in May'20, it was decided to hold back the AccECN (and the ECN++)
> drafts for a while until the position on L4S in tsvwg was clearer. There
> is no formal dependency on the L4S drafts in tsvwg, but it made sense
> not to burn codepoints without more certainty.
> 
> I've just refreshed the AccECN and the ECN++ drafts, which had expired.
> 
> I included the following minor changes to AccECN, which you can see via
> the diff link below, but in summary:
> * moved wrongly categorized "action if unwilling to provide f/b" to the
> group of bullets relevant to the receiver
> * removed refs to long-expired ecn-fallback draft
> * fixed table 1 after xml2rfc changed formatting
> 
> Thanks to those who pointed these out.
> 
> No changes to ECN++ other than update of some refs.
> 
> Cheers
> 
> 
> Bob
> 
> On 28/10/2020 12:47, internet-drafts@ietf.org wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the TCP Maintenance and Minor Extensions WG of
> the IETF.
> >
> >          Title           : More Accurate ECN Feedback in TCP
> >          Authors         : Bob Briscoe
> >                            Mirja Kühlewind
> >                            Richard Scheffenegger
> > 	Filename        : draft-ietf-tcpm-accurate-ecn-12.txt
> > 	Pages           : 58
> > 	Date            : 2020-10-28
> >
> > Abstract:
> >     Explicit Congestion Notification (ECN) is a mechanism where network
> >     nodes can mark IP packets instead of dropping them to indicate
> >     incipient congestion to the end-points.  Receivers with an ECN-
> >     capable transport protocol feed back this information to the sender.
> >     ECN is specified for TCP in such a way that only one feedback signal
> >     can be transmitted per Round-Trip Time (RTT).  Recent new TCP
> >     mechanisms like Congestion Exposure (ConEx), Data Center TCP (DCTCP)
> >     or Low Latency Low Loss Scalable Throughput (L4S) need more accurate
> >     ECN feedback information whenever more than one marking is received
> >     in one RTT.  This document specifies a scheme to provide more than
> >     one feedback signal per RTT in the TCP header.  Given TCP header
> >     space is scarce, it allocates a reserved header bit, that was
> >     previously used for the ECN-Nonce which has now been declared
> >     historic.  It also overloads the two existing ECN flags in the TCP
> >     header.  The resulting extra space is exploited to feed back the IP-
> >     ECN field received during the 3-way handshake as well.  Supplementary
> >     feedback information can optionally be provided in a new TCP option,
> >     which is never used on the TCP SYN.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-12
> > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-12
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-12
> >
> >
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
> 
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>                 PRIVILEGED AND CONFIDENTIAL
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm