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

"Black, David" <David.Black@dell.com> Wed, 24 March 2021 21:59 UTC

Return-Path: <David.Black@dell.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 8F3E33A0D5C; Wed, 24 Mar 2021 14:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.251, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=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=dell.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 IXe1xq5jQNpl; Wed, 24 Mar 2021 14:59:03 -0700 (PDT)
Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4164A3A0D5A; Wed, 24 Mar 2021 14:59:03 -0700 (PDT)
Received: from pps.filterd (m0170391.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 12OLl4og001865; Wed, 24 Mar 2021 17:58:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=GJyMtPcRjg8ekiyUGYZKOxFBqcA+Oi6hiGpww035tYE=; b=Ii12KQhQY1G5JNHrJUPY8iyoMV6w7jG1M71FF65McjpClawqywfXjHfgYg8ScT+UxN2F HVmu06OqHu1E8sL7SE8YmZzEJcTnipbQOGEWS10zGM4CVXVqOR3CFF+WqGqvxYfNigk5 6+rnF22wO0jv5Z8MidnqBHrbs67XrYMgQm/fklKpCtnjBWNM+EjIyONHLM4UVvbH+FtK A22yYFH3k4B9++8eBVKE6lg+gbcagRgQQyVLWrRKxo1j2UFMSU3PnGw4fLOCobhMWLe7 AnlwBaDSAmqJXp5mjJRW1vl/6pkzPjIg2DtX7ksSCdZKX6tAaSvRaqoOQPBogBtPasMW iQ==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 37dc6wytxn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Mar 2021 17:58:10 -0400
Received: from pps.filterd (m0144103.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 12OLnqPe085431; Wed, 24 Mar 2021 17:58:10 -0400
Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2169.outbound.protection.outlook.com [104.47.59.169]) by mx0b-00154901.pphosted.com with ESMTP id 37dwxwg409-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 24 Mar 2021 17:58:09 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VuwnTEIYapPqJsVzLuLpGBrcU7vFO7/9nGbsqgBrjEu/sw9nb5Mqmst6PXrqnrPizn69wIt02/AS3Fn9oCm4rTp2UWt7p0alc6jm8Tau0ih/cL/YXULSou7k+C66T2ayLorCEo/GhPvpmET+KEAW1VCP7ytXyUBKrsQBgFzPFcpBYsFDhpQRSxPeyVAh/Pt+wpS0izbHBgEXhbpog10MkKLbgSpjQnkM7bNEFZUTnhWvr4WXu8HO/hjiecfDR0Ifi3mS4g3W8MSl+9XC1FpB8fJJqTXzzSZyP++8AZFz3wlOWQP5turQIC+mskz6Kr7B25eZR846OFJ/Iq9zWvNlYA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GJyMtPcRjg8ekiyUGYZKOxFBqcA+Oi6hiGpww035tYE=; b=HeU/rpscQUmGD/Y89BKPZ51ZyOJBpe5CmQWTSSFYmxaW74AEA+uc2I+8krPkgg+jo/+3kbTUhqaQIp/Hsge2k1Ccrd+gClFVHdJhSkz33PcWjBJiZCKpXwcTrOC4Ne/pPRESyb3B2FardOcj+fwcFsEM3NINaY7bWDwwbiq7UXKSuVMo6F6OOAv8zUTRRL2gYHjd6YzIgxCBwcgQs/fNQW3tdTwgm49XTl+MESqOkp1EszDpahYUNl2lSe7cchdFZyvK8/MVaRrUat/lgli0sNJlkWahpPIKIY4Kh8VDcn+YCEDEXSSv7LvndZloMU916SfqJbIAywIv3+B+FujAXA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB3933.namprd19.prod.outlook.com (2603:10b6:208:1e0::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.24; Wed, 24 Mar 2021 21:58:07 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::b1f3:f51d:c01c:2feb]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::b1f3:f51d:c01c:2feb%6]) with mapi id 15.20.3977.024; Wed, 24 Mar 2021 21:58:07 +0000
From: "Black, David" <David.Black@dell.com>
To: Bob Briscoe <ietf@bobbriscoe.net>
CC: Markku Kojo <kojo@cs.helsinki.fi>, Joe Touch <touch@strayalpha.com>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "Black, David" <David.Black@dell.com>, Jonathan Morton <chromatix99@gmail.com>
Thread-Topic: ecn-encap-guidelines reframing section
Thread-Index: AQHXIDuxxLe+ftABOkuSmxBNmQTQCKqSRiIQgACfNgCAAA0AAIAAtejA
Date: Wed, 24 Mar 2021 21:58:07 +0000
Message-ID: <MN2PR19MB404575F25DC665379314002F83639@MN2PR19MB4045.namprd19.prod.outlook.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> <7C06A7EF-E319-4645-ADB6-18393521506A@gmail.com>
In-Reply-To: <7C06A7EF-E319-4645-ADB6-18393521506A@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2021-03-24T21:26:37.4386834Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_ActionId=7308abd7-7d34-4e82-bb7f-7e80a2033abf; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual
authentication-results: bobbriscoe.net; dkim=none (message not signed) header.d=none;bobbriscoe.net; dmarc=none action=none header.from=dell.com;
x-originating-ip: [72.74.71.221]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5d3c0edc-3065-43f6-20a6-08d8ef0fe874
x-ms-traffictypediagnostic: MN2PR19MB3933:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB39335808A5ABCB2027AEF61D83639@MN2PR19MB3933.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: EVZnxfdgRfCjbcvnShX1cW6UhW9zpyeRqgQZlczPIr3ym7QqELtx+T+MaGg9B385lUh1p+mezYHkNxPC7OJtrYSMUrkKXaNuSLPKa1Tw5jcET+VhyIe7yFqVufVC+siA4D2iF+oF9GpmQ48hRznrtOGoDjnl4vCNgSatXoK0uaa8rUO9DmpSvlgXvwzICYZ5f7juD5QvhkxJNE0gxXclx28TwCG5h/LLCBqfHq55CmWeGgIlpBhjRnEdHqoyY8qNKVEAo+UFs/jKRNPXurMsDkxH+i05lylNo1EjzETtMCzdrgdvKSW9jajNYWB7pqaN8uTSPq88xeAFXzU+zQ6pf4rVrUB/gpOs9ST1NdYmtYsNqm4juft8moHjUSkNuNHbOBu9gc3rHS3MCeSUDIWeuStL9DGwR8rHBx1DJkfDk/TeNCSnpZC0JiqGAr7GKJmh5olAu1JEaaIyIXOmTB0onMJgrx8aWYOS6NLNMFpPOvkV0bwSuAcV4YUtfWcIXM4lGxZyS6CPZkkGyVIAyZsm3GcQ7sLTVZjiyjJPu93Nc+P9G7Vk+v9WnKoiwqSATbFt5iSmZu2YuSviBPYtdKE14V4IRLazUFW2bnfEt7moVnBfkzjjX8AvxiKJiPjAdAuumAsuJH4ntPI8gw/kI+1ReeyydDxjS4EgBjJkHosfSww=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR19MB4045.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(136003)(366004)(376002)(346002)(39860400002)(53546011)(5660300002)(83380400001)(76116006)(8676002)(478600001)(8936002)(33656002)(66946007)(64756008)(7696005)(3480700007)(2906002)(66476007)(6506007)(66556008)(71200400001)(6916009)(316002)(86362001)(786003)(55016002)(26005)(186003)(38100700001)(66446008)(54906003)(4326008)(52536014)(9686003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?lmDs1jhGQmRKt1YZ8iWnKgX9DWkOsiZYR/ctoGbOHrvnOczcCLHC7eIzsohn?= =?us-ascii?Q?OIN6rt9Z6sdELe4bpbdaMNvG4dZWcr+3ChDqtYPAX/9w1IWiN4BeBmS8S72c?= =?us-ascii?Q?3QxQL031VnMGZ6myYsi3tfQCDQ89X2uc7HGEeJKhcuvCxVmehp15mZ54NebB?= =?us-ascii?Q?IrQcCYs3o+noQH2nu/DyAjO3HWh/3ATXWL6F8iJdEMOgRoJkdTefHDsuX3Yp?= =?us-ascii?Q?6PraQbYOyQ26oyiAu9e2eZOOrRQooyYd7a40wA7trQiOW/9QmGPQ4UIZURS5?= =?us-ascii?Q?6JeACdNMdZyR73DoEkuOUZoAhYvkdN9b4w7MHI3Cjvkg0qWGrpbsddWU/Yj0?= =?us-ascii?Q?20nWfFPn2TP/45UcAaQyULlp4NWlgsfeedlab1AQCjnVgnyzMey1yybpoP45?= =?us-ascii?Q?gHsp73VPpPGy72EkDoEGD83NyIhTqYwyYEDeOEdrWWSxU04Vm44j0hmzlN2a?= =?us-ascii?Q?fLnkM+yQbvWr98fWcMLtLaTZLnhDByGXA4mT+3WSuxOePbuc8d2TzL0ymPbv?= =?us-ascii?Q?wo5jAvhx49OnHIDIuem21ErvBVOHV6nlYT6Z5bRWk1mS08vxWQLY1FZ1CS+l?= =?us-ascii?Q?HYYXbJcMBRRbfV9/2WJpRNWIZZOERrWI16jiD0I7BqRhz4FM2UDHxmOdjku7?= =?us-ascii?Q?WjPmDyBcgxexqhJmfMOWFjNx5nwTS/h0GjReYlDYm5pRYh+lGyB5SmJUqxIi?= =?us-ascii?Q?2vEg3iVXebwNr1GWjM+Q0Omz9RCcuBU+ASRcX4S778i2I4D7dS7g5Zw9uuQw?= =?us-ascii?Q?4xBjOFH2P3RET9ZYsjc32ouhEBWMNzuZjp8w7dV5izVDxb0HmmJWpsEqP5nT?= =?us-ascii?Q?FpGqNNjZX7VrQ87vpwjFrRVLHXvG9CT6cM/AGwKBusl2hQZxDrcP2bzS4GL7?= =?us-ascii?Q?q52yPcIpKa0qiGIvY9tcCjJUXEIPDxoleb0SFLHQkArkjygy1m4UktCjNr6g?= =?us-ascii?Q?7fuyFrV+464IW7snHQdhS3MoFwFlwRZViPoED85F+yOilovBpgTI1lBnGo1C?= =?us-ascii?Q?klNBJrbd/QEkOZYJ+amUtgpnQWmGHNNwyhhA1y/P+Mx7qJ/hNbrTtI5ZpuH3?= =?us-ascii?Q?WRl/c/uXR+ZntkZUnuDKx15P9CDoSkYPBpK/TeCgKXzeqAlCEps6p0jc5BVY?= =?us-ascii?Q?qd8TlV9Ui7Y9KB6X6PQE30oaRGHfu9u13lzJpDYDXf8rSqzlWLHWDsgj0g12?= =?us-ascii?Q?6x31+chzQysTtVks4b0UbMnqihmL9nNy2Bl3z+fREeThq0989m2sUnlgVeoZ?= =?us-ascii?Q?WeWYFix0z/a5TcrldyxyzsGxpDFnBg9Rqj5ZIk1NgQhWrOhCVfo3HGWoBRsS?= =?us-ascii?Q?UopRXSMLMOleXU0IwYHqft7P?=
Content-Type: multipart/alternative; boundary="_000_MN2PR19MB404575F25DC665379314002F83639MN2PR19MB4045namp_"
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR19MB4045.namprd19.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5d3c0edc-3065-43f6-20a6-08d8ef0fe874
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2021 21:58:07.4804 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 1YzN3RGfNJZ53cWFi/kQ7F7DCRM3LyvTITlAsjsySBc8suRFk4F/b6dG2cPDESBi8xe0juK3iutAkDpShQBueg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3933
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-24_13:2021-03-24, 2021-03-24 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 impostorscore=0 adultscore=0 priorityscore=1501 clxscore=1015 lowpriorityscore=0 mlxlogscore=851 mlxscore=0 bulkscore=0 phishscore=0 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103240157
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 phishscore=0 mlxscore=0 spamscore=0 mlxlogscore=973 bulkscore=0 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103240157
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/3la3kG5-JLU2OPx3zGxxmhWGYEo>
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 21:59:06 -0000

Bob,


>> [BB2] I'm afraid not, because this is not about some niche environment.

>> Both the SHOULDs in the current draft are intended to apply to all known

>> AQMs and all known congestion controls including standard TCP.


I understand and agree with that objection to the "For environments in which protocol and/or application response to congestion is sensitive to ..." text that I suggested - in 20/20 hindsight, that text won't work :-(.


It appears to me that you and Jonathan are debating a marked-PDUs/packets vs. marked-bytes topic which is roughly analogous to the reassembly marking topic that was avoided in the 6040update-shim draft by deferring the decision on whether or not to update RFC 3168's fragment reassembly text.  This was due in part to RFC 3168 limiting what we could do in that draft - while I don't see analogous limits on this draft, I would still like to find a deferral approach that is roughly analogous to what was done in the 6040shim-update draft for consistency ... and in the hope of moving both of these drafts onward out of this WG in short order.



Much as I'm sure you believe that byte-mode marking is the proverbial "right thing to do," could you suggest more neutral text that defers the byte-mode vs. packet-mode marking decision for reframing, please?  I don't want to see these drafts still being in the WG at IETF-111 in July ... and the blocking WG Last Call issue wrt RFC 3168 has been resolved via the agreed text for the 6040update-shim draft.

Thanks, --David

From: Jonathan Morton <chromatix99@gmail.com>
Sent: Wednesday, March 24, 2021 6:35 AM
To: Bob Briscoe
Cc: Black, David; Markku Kojo; Joe Touch; Markku Kojo; tsvwg-chairs@ietf.org; tsvwg@ietf.org
Subject: Re: ecn-encap-guidelines reframing section




[EXTERNAL EMAIL]



> On 24 Mar, 2021, at 11:48 am, Bob Briscoe <ietf@bobbriscoe.net<mailto: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