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

"Black, David" <David.Black@dell.com> Wed, 24 March 2021 01:01 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 8075F3A1BF3; Tue, 23 Mar 2021 18:01:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.35
X-Spam-Level:
X-Spam-Status: No, score=-2.35 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 uUBd3hTn1FMX; Tue, 23 Mar 2021 18:01:42 -0700 (PDT)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.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 0644A3A1BD1; Tue, 23 Mar 2021 18:01:41 -0700 (PDT)
Received: from pps.filterd (m0170395.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 12O0wRY2007135; Tue, 23 Mar 2021 21:00:51 -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 : content-transfer-encoding : mime-version; s=smtpout1; bh=0Ogr4Vf7TI4ZvDhi+aUgyh6c7VRCGViFuIkIhuPglHA=; b=aXJz07zl3p/n3txF3WA8v3VQggLR7tijrPN49cxL10MyVWCQYBmk2GJo8pVz+t5fYcig b7Dy6L6rRuzT3CbJn2XHe7Zu48JKZPxiXCL24Fj9Q3vHYZOOtPosSKsPqJpygRfw1dr0 2VrFAJLMSakPEMXFnbDnCQ78WmcG0FtMxeyEtj8oEP1fBMOMrt9NtT/jnskOy4jm4Xj7 I6K1mOvhuv8r8edM3DNjGYY4h0lPBs9M9GrtUw/4YQVBKIcVfvarcB97cwERAShOaK6J HHi6eKKcL+svxWiJFjXIBIYEHIbG7Zlz76+InLlwR/Scb8L8k0XTNDqxoMTEfy5L9uk2 Gg==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 37dggkk81t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Mar 2021 21:00:51 -0400
Received: from pps.filterd (m0089483.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 12O10oXA117397; Tue, 23 Mar 2021 21:00:50 -0400
Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2170.outbound.protection.outlook.com [104.47.58.170]) by mx0b-00154901.pphosted.com with ESMTP id 37dx1hh2fa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 23 Mar 2021 21:00:50 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ig5ZMbU72F0nIY8QlbIXThW4oLpmRZu0mYlsOS9NjQ5mL8LgV1cYVU/CkKFqbhu0Iwh8aPqRe1nT4NsBLgDHRXtY0liJj0+8P1kA/7upXs5TZM1+a8oQXymDHb5fzDfgz6iZIOh+ax0jfilhaNPARRzpbl+Bbkyuf0cNb43WADAq+r3mXLlU0M3hw2q4fU5w2GtF3q2Xg8cwLVUqCCm83yq/6weitK4PSnLBin0OBGahTPIr/7w0kxOnztyTJSYHeuCpbGibrOFkaLRl/6by6AwZzA0aJUunBiqOJ3WUYjZ33vQnYR+Dp0Bg9zW3QnPDNJPJcMqrJNkmC37CMPmHJQ==
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=0Ogr4Vf7TI4ZvDhi+aUgyh6c7VRCGViFuIkIhuPglHA=; b=F4u9IdPgR7a8oAOGPJ7BwC0VOm6FY/D3puFuIiouN8X/f3CxVpaQ+0fnhVWsOFmMdnEdb4NPmuhHFHegduL0/8z6p8uSxqEV/nS8Qq9WntibDEBQRBriDCKfDF8IPYub/Jta29lVKxIh3uaeHmD+odoQnm9WL4Fiu+1pXn60XxfndvEKyg6iw9rO38yIOvArOsoUBgZDj1KbzH8doiwQaqwp5UM37C3n9HpnmcHXPiNWWgRXX+NRMsvc10+tD5keMkhG70giqTWghjp9Ve67P45Ik9FxXa2GwJ0XVrJv8VVdoBwaKfHJ/DZ6wFszZFX31o/IhAN59X2kxc6Q90daxQ==
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 MN2PR19MB3359.namprd19.prod.outlook.com (2603:10b6:208:151::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.18; Wed, 24 Mar 2021 01:00:45 +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 01:00:45 +0000
From: "Black, David" <David.Black@dell.com>
To: Bob Briscoe <ietf@bobbriscoe.net>, Jonathan Morton <chromatix99@gmail.com>
CC: 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>, "Black, David" <David.Black@dell.com>
Thread-Topic: ecn-encap-guidelines reframing section
Thread-Index: AQHXIDuxxLe+ftABOkuSmxBNmQTQCKqSRiIQ
Date: Wed, 24 Mar 2021 01:00:44 +0000
Message-ID: <MN2PR19MB40451E51462D82DF2F81D18183639@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <CE03DB3D7B45C245BCA0D243277949363076629A@MX307CL04.corp.emc.com> <CE03DB3D7B45C245BCA0D24327794936307662EA@MX307CL04.corp.emc.com> <1920ABCD-6029-4E37-9A18-CC4FEBBFA486@gmail.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>
In-Reply-To: <10cb995d-7ac0-99c8-4013-5ea8a518e643@bobbriscoe.net>
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-24T00:26:24.6474301Z; 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=98d1fac6-cffd-4eeb-95b5-2211ea41f122; 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: 8bcd8dce-cb08-41a8-6df1-08d8ee60412a
x-ms-traffictypediagnostic: MN2PR19MB3359:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB335969F506A157ACA6E214B483639@MN2PR19MB3359.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: GmaepQJ2q3KIVmA7qz59dzOV23kjJhshLJiOx/37JEiQL3pcEKLEPK7gqdxK3VcKSY/5RKKhaB5YR9lKR++Nra1q9cuCRlrN3waE0mbQNYfOwJcC/3xXsJ4H3qrDgftrELzMnKgCskVSQ1bHFR7bVnI383jn/BBE+3YG5F9zWK47Ow3wo4kRZufs+bPb6KDgSIJcGhxw62+IyrXGUwTwVYHwSttu+XTwjcOCGw3V3zp67BTbw5SCO3/f0xNTmZOC6pK0Vf/gZqEf/nP5Fxlq/CzIln6tlpmjK2kAvTFQ0UdaRpUnJ8ErcQ4+Nao9EbMCjG/YVjFQ1iPZZtxvmazgM4VFR8ZgCY3b3iX2L//eLO1OnpkfROu6lBx0NNDwONXNKSgKvPlOT4fCiZJPKXCqumD/oKjTAv95HrdvK82PJi82soRPjOiEU0HaQ1UOZHmuSINSk8w8ErO22G+yT3qsOEoqjipsdB7PKhXevd9eb4oeHSgP3YQFHtTiDiSEWIQXIBGdsEEdAJjci5reOVhLis2UUO1ZL7nqfnuaNG74E1Y8dflaTceHtBnFd3mYrzz/BkQHNz6C5Ad0O/RuPduAtpyOmoxQg5BJ2RQ0T7whKtMwrvH74ZZyMEgyin/VgNhXoC6BM6mLTIcBl7xZj1quirGSIszF1QhDT6jTb6sV0onKCNOgPYqxG6oCcee4PixkHzSOlHgxE8k686molRZX848M7sL0y982O2Mm96x3y9zlOah6tW881k3JL9yI2u6WnND+GZrGK0ZfKT/NjCJOUxvM6s6TRZeuEFuidrX2IgE=
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)(366004)(136003)(376002)(346002)(396003)(39860400002)(8676002)(316002)(7696005)(110136005)(54906003)(76116006)(5660300002)(52536014)(66946007)(3480700007)(786003)(83380400001)(8936002)(53546011)(2906002)(86362001)(6506007)(38100700001)(71200400001)(9686003)(55016002)(26005)(66556008)(107886003)(478600001)(66476007)(966005)(186003)(33656002)(66446008)(64756008)(4326008)(336755003)(18886065003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?TkpyR1l2TUJ0RUhFTmFHQmRwZk1EOGZmOERnQXBLVkU1Y0NWQ2h3dFdvSGI2?= =?utf-8?B?T2JiVWFtS1E4WlVPdTU1enZZdjQ0STFsOW9ONUdYMkRZU3l2SFYzUWlGQkNz?= =?utf-8?B?OUhyUzgyVGdOSUNRMnd1Wk9QZXMyUS9EQnJ5SlEra3lTMUVkQThPVHNVOXhC?= =?utf-8?B?M0ZHMUE3UmVJZy9JTzN0VDhQL2hIRHVrajFXTXhNZWVMNEdsL3hRc0o3ejBl?= =?utf-8?B?NGhxMStuQk1uS3VlZkpRa0pRWjlteWhLR2pxaVRXMWJUZDA5bE5Rc09ZTVky?= =?utf-8?B?c1BtYng1dmQwOThzVG52TkJuS01yMEFFZkxXWTZ5YmZvUjh2Z1JPeDVsNW5q?= =?utf-8?B?cHpNRkpCWXNQYU9JTzFXQ1VzREJPUGk2elpTY3dlUmwyKzlWWENteklBSGZ5?= =?utf-8?B?cjJ2MUxhOG42NGxrRHA4Mk9IQzBBMzZqMVppM0tkb2d5T2xkMlZVaE5lR2Vt?= =?utf-8?B?aEVvb1VWbEFsNC9wb2pnaE5hOG8yNGZvTk50OEJJNlAvTWR4NWtuN0Vmbnl5?= =?utf-8?B?TXlBWUY0QjBqUlV4UmYyRDRITkRpQTcybitVUEFpSkhGWWk0bXFLdk9ZVER6?= =?utf-8?B?V2k2NnpKOWpEM2dWNURhdkcwd3lsNFREMjJ5eGp2NW5FUnp0NXB0N1IyY0xl?= =?utf-8?B?c3lRcndPZm1jR2tVZlkwM0RwYlVqanp6NmQwdFVFd3VlTDJoMmVySW0vTy80?= =?utf-8?B?YUlRTGdGSmtOdkpHRWxPeFBXeGpEVThMUTlUNEhWbTZKZklVNEpQTGVwRHR6?= =?utf-8?B?QUwrSjdrUDZNUHE3TjQ2VHJqRE0xNnBjUDlmQk5sS3JLYTVER0dEdW9hVWts?= =?utf-8?B?MmpubDNEQjBUR3ZaS3BBZDU3WGVtWmM3bnpPbmRad1VJZ0NRNUs4U0tyT3pa?= =?utf-8?B?aTR5VnR3UldsdW8wZzlwTElTMmx6WFR5MllRcW8xNTcxbVNHVkZ4a1ZGcm1a?= =?utf-8?B?c2NRMHE2dGV3SnhKRUhXR3F2eW5GM3h3d0d0OEk5d2h3bjdteUc0RTFGQjZN?= =?utf-8?B?N1o0ZjczZzJVc1RoU0RJVTdmRHMyMGVGdUgyVHJHQ3lNVDhLKzkyQ1VMOTFs?= =?utf-8?B?STlVQ0xnNTY2RHh1QSttRHJFb0djaGxPOEZnZ0piV0FjblBmbVpXcnBST2Fx?= =?utf-8?B?RTNRTjNrcmRpOFExR2dTdjF2NTZOTXljVUlrMW9SU2tHNVYvbzdhRmVNYkto?= =?utf-8?B?MGRUOTJ4b21qajV5aVVEZHU4YXMrc0U0UjRSVkpSVzVoT0FaR1lkb1FwWXJq?= =?utf-8?B?T3Q2TnR6SENXNmRsVW9PeUIwWG5NRHRCYSt5ZmhySTN0MDloWHJXM2NOMTF6?= =?utf-8?B?UXM2NWg3STlHWUQ2WnI5T2ZRcnBBQmRIRWNxSUIyTWY2SmRhMnBPOWdPUmh6?= =?utf-8?B?Y1ozSmY4cW5UbDZGQ1JGTlV6T1FBc3AzMG9qdUhJcTNXWXhyc0ZBL0hMbjZD?= =?utf-8?B?UkdpNzZmV3FDWGU1VER6aDlNcURocEhGUjIrTE9Wcmhpd0Y5c2FUcXJJQ0pK?= =?utf-8?B?b1JvdU1raDRiZ2xHOXNQMkp6M21QT00zQ1A3SU5GWVVOZ1dPTjl0SUZYSDgw?= =?utf-8?B?b1ltSjZDTCtyeVBING5BOHZReElGcHhleXpKOEdvM1B6NTlVVURkWUxuOHkw?= =?utf-8?B?TlNTYW5zc1VMcFl0eUptblZFVlJ1dytRamF0d2xKQndnbFpZQ0tDSDlLT1U1?= =?utf-8?B?L0wvcFVXYXZNcHVxa295Y1kwbDZ4SW1FQTZOMjhtb0RBVDZCampPa2hWQXFY?= =?utf-8?Q?aAdpCHj3RtsFsDZBDt+rdOGeqRw7+hO0xIdUGwR?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: 8bcd8dce-cb08-41a8-6df1-08d8ee60412a
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2021 01:00:44.9520 (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: UHEkGilytVj03XWmVOklVtxBTD6zGJ74cfwVrDTegcq6qI0Xop2BSj0TVOrIz6alqW+RGte0hkpVgNDLsg35sw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3359
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-24_01:2021-03-23, 2021-03-23 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 bulkscore=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=999 impostorscore=0 priorityscore=1501 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103240004
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxlogscore=999 mlxscore=0 bulkscore=0 malwarescore=0 suspectscore=0 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103240003
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/IUr6nxdiVEXkUnECfdDJui1MUuY>
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 01:01:52 -0000

Bob,

> [BB] Er...hum...
> You seem to have forgotten that you are talking about just dumping the 
> point that I believe was missing from RFC3168. We came to a long-fought 
> agreement that we would not decide on this before publishing these 
> drafts. But now you are proposing we decide on this before publishing 
> these drafts.

Well ... not exactly ... because it appears to me that the reframing section (4.6) of the ecn-encap-guidelines draft does not address IP packet reassembly from IP fragments, and hence falls outside the scope of RFC 3168.

That said, I nonetheless concur with your sense that it would be good to preserve flexibility for addressing this area in a more specific fashion in the future.

>> For replacement, my initial sense matches Jonathan's, in particular that a layer 2
>> congestion mark ought not to result in congestion marking multiple IP packets:
>
> [BB] The whole problem I identified with only thinking in terms of the 
> second SHOULD is that you end up with either inflated or deflated 
> marking, depending respectively whether frames are smaller or larger 
> than packets. That is the whole point of the need for the two 
> contradictory requirements.

My current inclination is that we may be best served by postponing a decision on whether inflated/deflated marking is a bug or a feature, roughly analogous to what we've agreed to for the rfc6040update-shim draft.  The second "SHOULD" is clearly consistent with that approach, as propagating congestion indications quickly reduces the latency of transport protocol congestion response, which is a "good thing" on its own:

>>     The mechanism for propagating congestion indications SHOULD ensure
>>     that any incoming congestion indication is propagated immediately,
>>     not held awaiting the possibility of further congestion indications
>>     to be sufficient to indicate congestion on an outgoing PDU.

Turning to the first "SHOULD," this paragraph from one of Markku's messages frames the conundrum well (at least for me):

	I'm very well aware of the strong case that RFC 7141 makes for 
	packet-mode drop, and it makes this problem even much trickier to solve. 
	However, if we concentrate only on the problem of dropping small fragments 
	and reassembling them, the byte-mode drop together with reassembly logic 
	in RFC 3168 results in the correct outcome.

Of course, a significant aspect of the situation here is that reframing is not just about small fragments.

It's ironic that you (Bob) as an author of RFC 7141 are advocating byte-mode in this context - that's not intended to imply self-contradiction, unsoundness of argument, etc., but rather to serve as an indication of the complexity and subtlety of this situation.  Definitively resolving this situation now appears to require digging in well beyond this high-level byte-mode vs. packet-mode discussion, a journey that I'd really like to avoid in the hope of landing these drafts in our AD's lap in the near future.

So, in what may be an attempt to "have my cake and eat it too" I'd like to suggest rewriting the first SHOULD in terms of an observation that does not directly opine on byte-mode vs. packet-mode and does not use RFC 2119 keywords, e.g.:

OLD
     Congestion indications SHOULD be propagated on the basis that an
     encapsulator or decapsulator SHOULD approximately preserve the
     proportion of PDUs with congestion indications arriving and leaving.
NEW
     For environments in which protocol and/or application response to
     congestion is sensitive to the number of bytes in IP packets with
     congestion indications rather than the number of IP packets with
     congestion indications, encapsulators and decapsulators ought to
     approximately preserve the proportion of PDUs with congestion
     indications arriving and leaving.  See RFC 7141 [RFC7141] for further
     discussion.

Would something like that text work?

Thanks, --David

-----Original Message-----
From: Bob Briscoe <ietf@bobbriscoe.net> 
Sent: Tuesday, March 23, 2021 7:24 PM
To: Black, David; Jonathan Morton
Cc: Markku Kojo; Joe Touch; Markku Kojo; tsvwg-chairs@ietf.org; tsvwg@ietf.org
Subject: ecn-encap-guidelines reframing section


[EXTERNAL EMAIL] 

David,

On 22/03/2021 22:00, Black, David wrote:
> ---------------------------------
>
> Moving onto the ecn-encap draft (Section 4.6), the text involved concerns
> how to propagate layer 2 frame congestion marks to IP packets which might
> be fragments.  As this text is not dealing with reassembly of IP fragments, it
> cannot be in conflict with the reassembly text in RFC 3168, which has nothing
> to say about layer 2 frame congestion marks:
>
>     Congestion indications SHOULD be propagated on the basis that an
>     encapsulator or decapsulator SHOULD approximately preserve the
>     proportion of PDUs with congestion indications arriving and leaving.
>
>     The mechanism for propagating congestion indications SHOULD ensure
>     that any incoming congestion indication is propagated immediately,
>     not held awaiting the possibility of further congestion indications
>     to be sufficient to indicate congestion on an outgoing PDU.
>
> Bob initially suggested the following:
>
>> Possible resolution of the contradiction: the "SHOULD approximately preserve
>> the proportion" is a rough long term average goal while "SHOULD ensure that
>> incoming congestion indication is propagated immediately" is a requirement
>> for after there has been some period (TBD) without any marking.
> I'm going to go one step further and suggest removing the first "SHOULD" - the
> whole notion of rate-based marking of IP packets reassembled from fragments
> is what got us into the tarpit for the rfc6040update-shim draft, and the first
> "SHOULD" appears to be headed into the same tarpit, only perhaps deeper
> as the frames involved may contain multiple packets and/or fragments and/or
> portions of packets and/or portions of fragments.  That's not exactly pretty ...

[BB] Er...hum...
You seem to have forgotten that you are talking about just dumping the 
point that I believe was missing from RFC3168. We came to a long-fought 
agreement that we would not decide on this before publishing these 
drafts. But now you are proposing we decide on this before publishing 
these drafts.

>
> For replacement, my initial sense matches Jonathan's, in particular that a layer 2
> congestion mark ought not to result in congestion marking multiple IP packets:

[BB] The whole problem I identified with only thinking in terms of the 
second SHOULD is that you end up with either inflated or deflated 
marking, depending respectively whether frames are smaller or larger 
than packets. That is the whole point of the need for the two 
contradictory requirements.

>
>> I would say that one mark applied at link layer should result in one mark applied
>> to one IP packet.  Exactly which one doesn't really matter, as long as it has some
>> tangible connection to the frame that was marked.  Word it that way, and we'll
>> be fine.  In particular, this method should work for *both* conventional and
>> high-fidelity sensitive traffic.
> That also has the useful simplification of not asking the implementation of this draft
> to roughly track a long term average in some fashion.

[BB] No tracking of a long-term average is needed in the implementation, 
only in the /requirement/. One example implementation would be a single 
counter per aggregate (for the first SHOULD) and a timeout for the 
second SHOULD. The two override each other to create a compromise that 
addresses each requirement in the traffic scenarios where it is most 
applicable.

If you want me to give example pseudocode in this email, I would love 
to. But I thought we agreed that we are not going to solve the dilemma 
in this text, we are just going to state the requirements. Having worked 
on this draft for so many years, and having developed what I believe is 
a solution, I find that highly unsatisfactory. But we agreed to it.



Bob

>
> Thanks, --David
>
> -----Original Message-----
> From: Jonathan Morton <chromatix99@gmail.com>
> Sent: Sunday, March 21, 2021 2:42 PM
> To: Bob Briscoe
> Cc: Markku Kojo; Joe Touch; Markku Kojo; tsvwg-chairs@ietf.org; tsvwg@ietf.org
> Subject: Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim:SuggestedFragmentation/Reassemblytext
>
>
> [EXTERNAL EMAIL]
>
>> On 20 Mar, 2021, at 8:27 pm, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>>
>> It's not enough to make ecn-encap the same as shim. The reassembly logic in RFC3168 is only defined when packets are reassembled from /smaller/ fragments. When a L2 frame is /larger/ than an IP packet, or /overlaps/ the boundary between IP packets, the reassembly logic in RFC3168 makes is undefined - it makes no sense.
>>
>> For instance, some link layers treat IP packets as a continuous byte stream, then break the stream into the largest possible frames, like so:
>>
>> ----------------->+<---------------------------->+<------------------------------>+<----
>>          Fr1       |                Fr2           |             Fr3                |
>> +-------------+-------------+-------------+-------------+-------------+-------------+---
>> |   Pkt1      |    Pkt2     |    Pkt3     |   Pkt4      |    Pkt5     |   Pkt6      |
>> +-------------+-------------+-------------+-------------+-------------+-------------+---
>>
>> Then, say Fr2 was marked. On decap should Pkt2, Pkt3 & Pkt4 be marked, or just Pkt3 & Pkt4?
> I would say that one mark applied at link layer should result in one mark applied to one IP packet.  Exactly which one doesn't really matter, as long as it has some tangible connection to the frame that was marked.  Word it that way, and we'll be fine.  In particular, this method should work for *both* conventional and high-fidelity sensitive traffic.
>
>   - Jonathan Morton

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/