[tcpm] draft-ietf-tsvwg-ecn-l4s-id

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Sun, 24 March 2019 19:15 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 []) by ietfa.amsl.com (Postfix) with ESMTP id CD081120041; Sun, 24 Mar 2019 12:15:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.893
X-Spam-Status: No, score=-0.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 1XkuFFYs73Pj; Sun, 24 Mar 2019 12:15:46 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5DF2120026; Sun, 24 Mar 2019 12:15:43 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by mail.hs-esslingen.de (Postfix) with ESMTP id 976F325A1B; Sun, 24 Mar 2019 20:15:41 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1553454941; bh=u4I864gYVGfwORrNhJ2VWrpWaRCGRI0YICCQuoebZ/0=; h=From:To:CC:Subject:Date:From; b=IXvaOnXjd5TzOqrcWMhriWXpEkRIENpFmzukwlC2qeQYxvsPRDV3ufWmO6FVeW3Qp on7TxYZ/tBGQ8QnQODt4W+MydNEnICgGR524Ip46I0wPb8RglG7+V02hivdb0rlCxM hYZqJEuZTxYyY3UzIvzkMsCz6228fZK5UAoyldZQ=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([]) by localhost (hs-esslingen.de []) (amavisd-new, port 10024) with ESMTP id c4s_Kc4nMI-7; Sun, 24 Mar 2019 20:15:41 +0100 (CET)
Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Sun, 24 Mar 2019 20:15:41 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Sun, 24 Mar 2019 20:15:40 +0100
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: "draft-ietf-tsvwg-ecn-l4s-id@ietf.org" <draft-ietf-tsvwg-ecn-l4s-id@ietf.org>
CC: "tsvwg@ietf.org" <tsvwg@ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: draft-ietf-tsvwg-ecn-l4s-id
Thread-Index: AdTicaw/eTo/dzaNQFmeZc0gTHeEvw==
Date: Sun, 24 Mar 2019 19:15:39 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D27D05A@rznt8114.rznt.rzdir.fht-esslingen.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/0bdNU5yykBRmWJ4BvbPq5I8DJ38>
Subject: [tcpm] draft-ietf-tsvwg-ecn-l4s-id
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: Sun, 24 Mar 2019 19:15:49 -0000

I have just parsed through draft-ietf-tsvwg-ecn-l4s-id-06 and I run into the following sentence:

TCP:  Support for accurate ECN feedback (AccECN
      [I-D.ietf-tcpm-accurate-ecn]) by both ends is a prerequisite for
      scalable congestion control.  Therefore, the presence of ECT(1) in
      the IP headers even in one direction of a TCP connection will
      imply that both ends support AccECN.  However, the converse does
      not apply.  So even if both ends support AccECN, either of the two
      ends can choose not to use a scalable congestion control, whatever
      the other end's choice.

Can the authors please clarify whether there is a normative dependency of draft-ietf-tsvwg-ecn-l4s-id on draft-ietf-tcpm-accurate-ecn?

If so, I think the formal dependency on implementing AccECN has to be spelt out explicitly. In that case, I would be looking for a statement of the sort "MUST/SHOULD/MAY implement draft-ietf-tcpm-accurate-ecn" somewhere. If such a requirement does not exist, I think the above paragraph is confusing.

As individual contributor, I want to note that I disagree with mandatory dependencies between experiments. I have mentioned in the past that I believe that different experiments must be specified independently of each other and should be implementable independently of each other, specifically also to be able to fail independently of each other. It is possible that I am in the rough part of the consensus. But I haven't changed my mind.

Michael (as individual)