Re: [tsvwg] ecn-encap-guidelines reframing section

Jonathan Morton <chromatix99@gmail.com> Wed, 24 March 2021 10:35 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 26DED3A29E5; Wed, 24 Mar 2021 03:35:38 -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 Mtm25AWsQhoB; Wed, 24 Mar 2021 03:35:33 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 8095D3A29E4; Wed, 24 Mar 2021 03:35:33 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id r20so29569470ljk.4; Wed, 24 Mar 2021 03:35:33 -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=PorjQqhhPrWKdDoWeqqthf60n+Xy+krKkDsAnHBcI5w=; b=CEuuF63658rNgHXp+EH697ouiNfRVKhu7wwMxRCm8lHxXW6o6v9FNLRlhQIOzfEYM7 HX08I+8oJS6eGW3gy/V2i/AxNO6NDu0kijKGW7aT8YiAg8H8QSwmBymbZoSNTHvLXqfM r2Pgbj1ZLdL3GCv8mO3wEgI37taovb0xkSFcqBHADJdP2wz08PfMmkcrr13wPOUXF8ju rtKQGVTmM9qPWSTty9Tjun7vO9zHpI6sPAuqDGUqY0C8ui9BaX29+cQW0hLvNwSBM7SU x7KL0A7wBUMz8vMYym8P6ZdtWhbdJm/IQWQc/yGLpWIzBR4N1oPnHEpdCl6cztYhnOHq nTBQ==
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=PorjQqhhPrWKdDoWeqqthf60n+Xy+krKkDsAnHBcI5w=; b=VY6QQTu7MbeeihND8RN6UkMnEN/ouPmYKpiYiOS6M+Nf8q0PbdXXRSZyvo4ACZjhtD WeyTEOjiT+HnGEgKxrA5kQGDCFnbPPcFj+mW7HoxdLcj25HbMIK/d2cuyryO12YK+ozE wKyHb9WcE3I9C2HOkqbmweXy2vUD9MsA6v1rjHm1G2+GE9L+lM88MikH5wCu77LiBCfg ksINA+i44yI5VxSJ/1O7uFgGlmwXPI/PepqEHgjYt3JYSSPv2Jne6pCm4Ll/oaKJRa5H /qpbUDdxb/UqXnnMt94fxKGOPvy3MdTh5/rJpDA2BQBGXhdN71kNXukRyqBFjRvUkwC1 qY7g==
X-Gm-Message-State: AOAM5311WAO97HPn3JpOk2FDufsXKn7S74gs1uOFoOOQI5onpJlv4BLU potId3fIxRqilsEy0vscp/k=
X-Google-Smtp-Source: ABdhPJwikBCR4t3S4YD8C/HtDbcHclgs6UCbAa9O70KzitiHQXlY4EcxeiZCBvyASs1ZoiaPlbCMdw==
X-Received: by 2002:a2e:9bcd:: with SMTP id w13mr1686113ljj.43.1616582130236; Wed, 24 Mar 2021 03:35:30 -0700 (PDT)
Received: from jonathartonsmbp.lan (178-55-25-11.bb.dnainternet.fi. [178.55.25.11]) by smtp.gmail.com with ESMTPSA id u25sm189498lfk.213.2021.03.24.03.35.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Mar 2021 03:35:29 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <6b9f2527-ccbd-af2a-caa3-8a0b7c234aa6@bobbriscoe.net>
Date: Wed, 24 Mar 2021 12:35:28 +0200
Cc: "Black, David" <David.Black@dell.com>, Markku Kojo <kojo@cs.helsinki.fi>, Joe Touch <touch@strayalpha.com>, Markku Kojo <kojo=40cs.helsinki.fi@dmarc.ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7C06A7EF-E319-4645-ADB6-18393521506A@gmail.com>
References: <CE03DB3D7B45C245BCA0D243277949363076629A@MX307CL04.corp.emc.com> <CE03DB3D7B45C245BCA0D2432779493630768173@MX307CL04.corp.emc.com> <6D176D4A-C0A7-41BA-807A-5478D28A0301@strayalpha.com> <CE03DB3D7B45C245BCA0D24327794936307688C5@MX307CL04.corp.emc.com> <alpine.DEB.2.21.1911171041020.5835@hp8x-60.cs.helsinki.fi> <9024d91a-bb08-fb45-84f8-ce89ba90648d@bobbriscoe.net> <alpine.DEB.2.21.2012141735030.5844@hp8x-60.cs.helsinki.fi> <1e038b64-8276-3515-ac45-e0fc84e1c413@bobbriscoe.net> <alpine.DEB.2.21.2103081540280.3820@hp8x-60.cs.helsinki.fi> <3c778eb9-56dc-3d58-0de4-c6373d1090ec@bobbriscoe.net> <alpine.DEB.2.21.2103181233160.3820@hp8x-60.cs.helsinki.fi> <8ac0d6dd-1648-ee8d-d107-55ef7fe7695f@bobbriscoe.net> <CD5B98D1-9BAE-4B74-8751-A8AF293AEFC3@gmail.com> <MN2PR19MB4045C7AD9873F378FB542CF283659@MN2PR19MB4045.namprd19.prod.outlook.com> <10cb995d-7ac0-99c8-4013-5ea8a518e643@bobbriscoe.net> <MN2PR19MB40451E51462D82DF2F81D18183639@MN2PR19MB4045.namprd19.prod.outlook.com> <6b9f2527-ccbd-af2a-caa3-8a0b7c234aa6@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/tXQFky9eiNTvlkY_rCoKel-aCfY>
Subject: Re: [tsvwg] ecn-encap-guidelines reframing section
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: Wed, 24 Mar 2021 10:35:38 -0000

> On 24 Mar, 2021, at 11:48 am, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> 
> Before we discuss the requirement, can we make sure we're all on the same page regarding some basic facts about preserving markings when PDU boundaries change:
> 
>                    | marked    marked
>                    | PDUs      bytes
> -------------------+------------------
> preserving prop'n  |  ==        ==
> preserving number  |  !=        ==
> 
> For those who prefer writing, this means that, when the boundaries between PDUs change, preserving the proportion of marked PDUs, the proportion of marked bytes, and the number of marked bytes all mean the same thing. But preserving the number of marked PDUs is not the same as any of the others. And note that preserving the timing is the same as preserving the number of marked PDUs.
> 
> Does everyone agree on these factual points, at least?

I'm unclear what "PDU" means in this context.  I think we should use "inner packet", "outer packet" and "link frame" to be unambiguous, at least during the discussion.

Clearly, if one marked link frame results in two marked inner packets, when the link frame itself is smaller than either of the inner packets - as in your illustration earlier - then that preserves *neither* number nor proportion.  An argument could be made either way where the link frame is large enough to enclose more than one complete inner packet, but I'm going to argue for preserving the number of marks.

> For instance, consider CoDel counting 200 PDUs between marks on the outer headers, then imagine that on decap the boundaries between the PDUs are changed to create half as many PDUs...
> Then, if each single mark is preserved as a single marked PDU, it will result in only 100 PDUs between marks. This is because the total number of PDUs has changed, so you cannot preserve both the number of marked PDUs and the number of unmarked PDUs.

This is a straw man.  If Codel marked the inner packets before encapsulation, those inner packets will still carry CE marks after passing through a re-framing link, before any processing of congestion marking subsequently applied to the link frames.  Number and proportion are therefore *both* preserved without having to do any extra work.

What we need to consider is the application of *new* congestion marking to the link frames or outer packets, and transferring those congestion indications adequately to the inner packets they encapsulated.  The link frames don't need to carry any indication that the inner packet was already marked for this to work; only that a congestion mark may be applied and will be honoured at decapsulation.

Hence my suggestion that one marked link frame should result in one marked inner packet.  One mark was applied by the AQM; one mark should be seen by the transport.  This behaviour is easy to predict and analyse; knowing the marking frequency of the AQM, you can derive the behaviour of the congestion control algorithm.  It should also be straightforward to specify and implement.

 - Jonathan Morton