Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)

Jonathan Morton <chromatix99@gmail.com> Tue, 10 March 2020 23:02 UTC

Return-Path: <chromatix99@gmail.com>
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 DF9EC3A0831 for <tsvwg@ietfa.amsl.com>; Tue, 10 Mar 2020 16:02:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1M3DEFZgbulB for <tsvwg@ietfa.amsl.com>; Tue, 10 Mar 2020 16:02:25 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 065153A0847 for <tsvwg@ietf.org>; Tue, 10 Mar 2020 16:02:24 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id s13so187319ljm.1 for <tsvwg@ietf.org>; Tue, 10 Mar 2020 16:02:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5cZsKl8U/0rRcDEqwNCwB23hMgoifgFWoy9lyQrBjM0=; b=qPeC/yQ2ockvUbjY1hq+C0wEFEluZdqVTrlnjsUWCkWZMJdUeDFGdx5i5sPLOJMSgA QszN8YY4arIZn5sxWiJB3GGmOrc5QSDeEYiIyCek3v667jyzOUhw+pW4LU6w2FADyE8J nE4sP4eam/hwjRZxy8P46g/9BnPs5mziTo5fJ2pa/DPGKG7aXH8t0E1RDrF0+W188in9 vaT6S+cAuI6UCB857n5m7bnQJyZfAD0E+xpHfqURCmXW3hhN6LIhYtLu2JEYApC4640O Vlf81iwx/ORYCnjAFZrHroo74KSgeYG+6FI05w1FnBUAaUC+5ms/QeCoYbqbcJRYj23Q PqmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5cZsKl8U/0rRcDEqwNCwB23hMgoifgFWoy9lyQrBjM0=; b=mL05Q3pQnPBtNcVYL5Jb7kKSuh9cDqRbTAaZDom6fltw0iPfbE5t7zK2UVrSh7+eNx hRVaaHsnt+g9POFTZ5l9coMcPFPZqRaFGkpC93m4hikeC1vpd5/vQjqang5Z9MC5swjt CPMq4LkoXQN4ZsfgQ62b3WEDO6gz9O3dldN2an7j5uxa3hSKxHPI80XCGqOSCfCjuD7f cM5+YsnLV3ZI93MlbqKxHYJRYqgwYkF3Wv46J25ukaPp4UdoemU2Y1t7jh1cYD3FVeW8 Je88Vf8DEjWfqhKsmaMYFL3WjfQf9e+qoMN6wp36zL6VaaCf/eH1cKxZZ6ZOPDeTowYZ Beaw==
X-Gm-Message-State: ANhLgQ2cn/ifgNqclldVzpp/+v/XVgE3vNtU2QHuWOb8m4QOc8lOVPq4 YJ6PVmZVfder2Zrly700d1VGqihh
X-Google-Smtp-Source: =?utf-8?q?ADFU+vs9Kg6YlQvFRmOeugjgtGDscqjpUCxT3V9fnWZm?= =?utf-8?q?/V4q3T8XmZYyxOzaXpHH7tLyzr4M6h3wYA=3D=3D?=
X-Received: by 2002:a2e:9c8:: with SMTP id 191mr256151ljj.259.1583881343230; Tue, 10 Mar 2020 16:02:23 -0700 (PDT)
Received: from jonathartonsmbp.lan (83-245-250-250-nat-p.elisa-mobile.fi. [83.245.250.250]) by smtp.gmail.com with ESMTPSA id h2sm2962024ljm.103.2020.03.10.16.02.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2020 16:02:22 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <2873ab79-19ad-0541-e3a4-d1d28dbc7ba0@bobbriscoe.net>
Date: Wed, 11 Mar 2020 01:02:20 +0200
Cc: "Black, David" <David.Black@dell.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B6D58310-41E0-4172-B555-D28E7926A0B5@gmail.com>
References: <CE03DB3D7B45C245BCA0D24327794936306F8925@MX307CL04.corp.emc.com> <2873ab79-19ad-0541-e3a4-d1d28dbc7ba0@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/hSUEFnkUU2-RTWY_ghAhauPXbp4>
Subject: Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)
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: Tue, 10 Mar 2020 23:02:27 -0000

> On 10 Mar, 2020, at 8:47 pm, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> 
>   This specification does not rule out the logical OR approach of RFC3168.
> .  So a tunnel egress MAY CE-mark a reassembled packet if any of
>    the fragments are CE-marked (and none are Not-ECT).  However, this
>    approach could result in reduced link utilization, or bias against
>    flows that are fragmented relative to those that are not.

As I have stated in the past on this subject, I disagree with this characterisation.  It misconstrues the meaning of CE and the definition of steady state involving it, both for conventional congestion control and for the high-fidelity version.  It also leads to a more complex reassembly implementation being "preferred" than is necessary, which may deter implementors.

For conventional congestion control, the steady state is defined in terms of the time interval (during which cwnd growth occurs) between RTTs containing at least one CE mark (and/or packet loss).  It is necessary for a single CE mark to be delivered promptly, ie. attached to the same packet as the marked fragment belonged to, in order to minimise growth overshoot and keep the control loop properly closed.  The control loop is not sensitive to the "proportion of bytes marked", only that a mark was encountered at a particular time.  It is well known, moreover, that adding delay to a control loop destabilises it - but this is exactly what an attempt to maintain the proportion of marked bytes would do.

For DCTCP-style congestion control, the steady state is defined in terms of the number of CE marks received per RTT.  Fragmentation does not change the RTT, only the number of packets passing a middlebox located on the tunnel path.  It would be reasonable to design an AQM expecting DCTCP traffic so that it produces exactly the correct number of CE marks per RTT at a particular queue depth.  But if the number of marks is effectively halved by a reassembly process that attempts to preserve the number of marked bytes, that queue will continue to grow past that designed ideal point.  We can therefore conclude that DCTCP is also insensitive to the proportion of marked bytes, and this is not a property worth preserving; rather, the total number of marked packets should be preserved.

Finally, I observe that Codel performs marking on a time schedule, not on a proportion of packets passing through.  This is entirely consistent with the above observations about transport behaviour, and further confirms the need to preserve the number of marked packets, not the proportion of marked bytes or packets.

The existing language in RFC-3168 succeeds in preserving the number of CE marks applied to a flow.  Any deficiencies we should consider are in relation to handling the distinction between ECT(1) and ECT(0), as this is what newly becomes significant with both the L4S and SCE proposals.

 - Jonathan Morton