Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim:SuggestedFragmentation/Reassemblytext

"Black, David" <David.Black@dell.com> Mon, 22 March 2021 22: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 1CD183A1371; Mon, 22 Mar 2021 15:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.45
X-Spam-Level:
X-Spam-Status: No, score=-0.45 tagged_above=-999 required=5 tests=[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 YSgwl2GvbYTD; Mon, 22 Mar 2021 15:01:14 -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 1BCCD3A1393; Mon, 22 Mar 2021 15:01:14 -0700 (PDT)
Received: from pps.filterd (m0170397.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 12MLqSmc014169; Mon, 22 Mar 2021 18:00:25 -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=u3D0I2jPoA4W43PSjDAfEHzRSzRjpgVcyj2MrQ1JegY=; b=cusn3wOjcckkPsNoZ1GrsCAiGK7nd941gX/Ve+rNB5h2NHQH6ip7q1pPebbTh4SW6s+E DzMfGAHBix/RO71T0xZ/6lNYVHnGtAyikcBDKg6ILtjPun60BW8dwCTN7ROonWa/m1oU AG1Ax7U/x+0CaJGQdl57aW+lRm8c7PS+TmReOTx2JD/ob1C21blzqFwrlagqS26PsqOJ 5UkHhOblGo/ANm4k1JPjdYHA/uRRNhU1O9JKz6oXLdCz3Pwm6oQLFeVABXd7fj87l2Oa 0Cbx7Fcp59oN8kOREhH34P4x7Julx9YB5fkKYXazqq6z15PPnw8AawSdpNXvaVV0PNbd bg==
Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0b-00154904.pphosted.com with ESMTP id 37da4sy8eu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Mar 2021 18:00:24 -0400
Received: from pps.filterd (m0134746.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 12MM0EH2111622; Mon, 22 Mar 2021 18:00:23 -0400
Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2173.outbound.protection.outlook.com [104.47.55.173]) by mx0a-00154901.pphosted.com with ESMTP id 37dx2wdyyc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 22 Mar 2021 18:00:23 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Uf5+G8uuhZQ/ddtf6bIy3Ld2Xbv5B2Pd5ZJTR1TwrTtUNN3eV3Ovd4TVSgMqwQFuG0RbclvLuHzeZWbj8jaPXrOQf/lZMKPPAD4syU0zeMNikblzIK/urAeAKs2y8O0yeCeXqAQABWs69u7d9bNrXle6DL6xMco+TD3Az7tbAg50CPkJ+QYIyA3FmNDO6NE8vaMeBagKp+91Cxdk/uUZm3NJ4TT2fZKiBsv3a/RSfnrcJLwaJZm+1PXA3GUWRkoLakhdJWaWCPEbFiq8djl/Up/q2UhHZMd+gWxCP7Y2HpKpF1zlRs7PAmbYnqYmpLV9sTLd+KbziWSI3N+FJOxhBQ==
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=u3D0I2jPoA4W43PSjDAfEHzRSzRjpgVcyj2MrQ1JegY=; b=SI0b3QdpGIdBnFO2sboLugu6jiFo/utv+bi1MU7E3OhAlov4PvzzX940+2kn8y7s+IjQFIOKG5IfKlwoGiUp64PNxoQUg0Gn54Memp6K0z9NMulzBKpl+tuRulunMb7WguzjHeP1juOEdV0blt3VYYMq8gn96oUiBd2qxfawkQ5dcPXBE6pfFjaBtxsb2G1+m+HZK6R++2cDqHrN1197mSYuEYpjGXUSxRR+s6WlcVT0eWAUffuMPzN9TNF7sRuWnMS0jJ05waTPH12WpxVj3l0MPCBhQCsfNMYG5kkQGQWrY0Olb30RT6VrRXAOj/aSmYpt4q2pb67nKXhlLQRKAQ==
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 BL0PR1901MB2020.namprd19.prod.outlook.com (2603:10b6:207:38::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.24; Mon, 22 Mar 2021 22:00:21 +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.3955.027; Mon, 22 Mar 2021 22:00:21 +0000
From: "Black, David" <David.Black@dell.com>
To: Jonathan Morton <chromatix99@gmail.com>, Bob Briscoe <ietf@bobbriscoe.net>
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: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim:SuggestedFragmentation/Reassemblytext
Thread-Index: AQHXHoHzyRB0KbbvNUGu9Uh71MX8MKqQe7AA
Date: Mon, 22 Mar 2021 22:00:21 +0000
Message-ID: <MN2PR19MB4045C7AD9873F378FB542CF283659@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>
In-Reply-To: <CD5B98D1-9BAE-4B74-8751-A8AF293AEFC3@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-22T21:01:33.3410199Z; 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=70333f8a-e3d6-44fd-ad6d-301216336e02; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; 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: b171baee-2a88-4fc7-f842-08d8ed7de390
x-ms-traffictypediagnostic: BL0PR1901MB2020:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BL0PR1901MB202048328DE43DEE3D16F0CB83659@BL0PR1901MB2020.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: tork4E20JhwEgqG6fT0K1cCA2O7Uew4Jlt1ehJgrgCR6eCOfi+BlScMHt9ReGQSlYVE1SxHYrFCCtPpWU5tRIAbV8LDuG39HoaEliIt9G/a7GcpiN0fw1Kjc6tprtP3TiuRfNW2AvDd5g00ZzUXckVZ8qEV5jBTzAsQJ+7Es2mObv6S/ucgzbledlu8xb32AcBjtGbm9b9oL0A7gWdIbpquh3JOyuV4wPNxkm9TGGcIpS1werO8qKQznw7TFPqSNY/XOdeFIjTVbNaHJXF/fx+nz2yDnLnhL77qJO1Z08hF+Ih/Tp+shV+Kj+89wDG+PIR5u6sKib7XUWfXDmMNAO+l/gNoVgGzAqjQoitTNeXmGfCkjX4hwdhFUsrEB8j3zxnlvdcnyPxbDiugEza2CwJwD/IIh+8Bu9Ye3MQEl3BVexqN9zUm71mPx8P3+73MgoXZXiAKj0DTQnZOH6O8q3Gf42SaUL6H82t9r+NcT5l7db6QH9ZunexdUSVZnaU4zS8EptdmD8czdr7TodF8mtF0NEWw/rhm4lUmwg5FdudOqAxV1aJZY4YmN2aWIhRvxBO6zmd4PPC0234YHyKWr/itgWLYU6DyojxC1ree6xjmjXU+FnD/EbmpPalFGlAmo8SWZOZn6+OST3SY1dI3K8OCMGpeB/d8xaCLGaJzdhI4=
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)(136003)(366004)(376002)(39860400002)(396003)(346002)(2906002)(83380400001)(66446008)(4326008)(66946007)(66476007)(64756008)(76116006)(478600001)(38100700001)(186003)(66556008)(26005)(107886003)(86362001)(9686003)(33656002)(110136005)(54906003)(55016002)(71200400001)(8936002)(8676002)(7696005)(316002)(6506007)(786003)(5660300002)(53546011)(52536014); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?2MTBS8MQWGhmLUXRRdGdIPBF2PUC2WK5oPBt0q+JFC1ot8FrjzJ14AEUK75i?= =?us-ascii?Q?lTcSxYYu8hYojUWgyYk7NANuxqqbZOT5CL6vRvg50KuFDf0/wpXcFmM3HAPs?= =?us-ascii?Q?WlF9DCJCz/ysu4/BRkl0+hxgi4opU8ZR3Czgm3d42vFJZs22cOK2gqe8K0y8?= =?us-ascii?Q?zylFZQ0uLInVZ/5fMXfo9RIPfAOrnodqWe/AbC7J8eLZj+Qli99qZECe/F0o?= =?us-ascii?Q?Vx8z/A/IrTaw5SMPa7XtXlzWS9K/vM/hzeJyiNLSxFW0H7oytjrzrMIzISWD?= =?us-ascii?Q?bctj2bCQrF3o1QaWcqi0VEVMK5rZM7EReCG/CVmZQ/kaRz2A/sVpnixvrfgG?= =?us-ascii?Q?F7o168ELeD3VON1OZusN8DYwlliEaushzC5GGM2+5yewEOUMQdch1lXWFHiM?= =?us-ascii?Q?SwzZSZGPGyBFo5shOO+CYz4P7zp1qS5uimQY1jUESSTt1kITtt80YlHWlEHF?= =?us-ascii?Q?BnrN3RgPYO/y5JoF6m3ya+O9EQQQeq9TC1gnqkzpxga+RUSUibhN7ruBbepO?= =?us-ascii?Q?HxIgV7HrfNwWQ5NnPT72/XBbwVGeWBE8Qm5hAxqAZ6jBZ4vrx4oXN0pPi1X9?= =?us-ascii?Q?cTJD7cP3AyLbcKuHCg9DPUfe07WJoUpcwUYH8xMIsHoy6kSs3+1W7Wv51A3R?= =?us-ascii?Q?VGD1U31iWGFvHpvIF+ymYsaQGmZ+6fQx9DJpF42rMHRMnW7pDZsaXHRh+69d?= =?us-ascii?Q?MWipiGnAkwIO1HW/HnodlI55ng8CiOVJDkfn4k4JXytpujZSfeHY5EAgfdD1?= =?us-ascii?Q?i/gfzU8qgD4VdmVolyWBdStTQqp7Ck1MxsdJYC4cjr/inJYJfPXFsrBZeOUl?= =?us-ascii?Q?EVCZSd34v3lzMPiyp7g/eQhkylbOHoLPPABt9KJwKGJd+yLFoEHeSB/Khnt0?= =?us-ascii?Q?2OguN9wVQi/bPO3ICp0KdCOWa6mNdAOk6lbAmpol7slzvNFlsET0Y9CvstL5?= =?us-ascii?Q?N9CHnC1UC0UySdKhMbznOkuJI6AwDQzyf4H/aJoK9UQKS6EJ7smw407VbNUB?= =?us-ascii?Q?2mfqtQP0dF22XyqZ9jK/wr3sS8jOMKdt0zAWlMobeoDum8qOEZ8o4q8i6kRj?= =?us-ascii?Q?n4xCbtne9Oi9L8DyVvV677fFztTQu/Tw0TwD0uOg6uy/Nmpyiy2uHpd3yJTY?= =?us-ascii?Q?64X/1CHmd8OW5V7c6GfGd5tRRx+bjfhUqgF82p0xhlj+4dLVezMB6gDe3nuc?= =?us-ascii?Q?cC/Y2cQ5RB1/1qUcfGZrXtMHB+eP44BPLCBqQVruNPTELzhGK3VAn+iUCONI?= =?us-ascii?Q?onynjuB1h2f6EMbK08/tvB3FWl/x7Se5EbG1Xp+l85p5fRVG6KPOqfVbkXsc?= =?us-ascii?Q?bwB63ln+xQ3l+f5MFoWKuSFu?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: b171baee-2a88-4fc7-f842-08d8ed7de390
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2021 22:00:21.6812 (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: BUH/71GseTS6KbVwZQWqjHVFH4s40fDuISSf4SQ7qijZmJEUNFvInKULfxNtJ+gbXdMyF4X6Ve0kHn/4AkUDzA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR1901MB2020
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-22_11:2021-03-22, 2021-03-22 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 phishscore=0 clxscore=1015 malwarescore=0 lowpriorityscore=0 mlxscore=0 suspectscore=0 impostorscore=0 spamscore=0 bulkscore=0 adultscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103220161
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 malwarescore=0 spamscore=0 phishscore=0 suspectscore=0 mlxscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103220160
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/rSOV9WRUhai7iER8-YxLc0cdceI>
Subject: Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim:SuggestedFragmentation/Reassemblytext
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: Mon, 22 Mar 2021 22:01:18 -0000

First, the good news - the reassembly text in Section 5 of rfc6040update-shim
draft looks good:

   Section 5.3 of [RFC3168] defines the process that a tunnel egress
   follows to reassemble sets of outer fragments
   [I-D.ietf-intarea-tunnels] into packets.

   During reassembly of outer fragments [I-D.ietf-intarea-tunnels], if
   the ECN fields of the outer headers being reassembled into a single
   packet consist of a mixture of Not-ECT and other ECN codepoints, the
   packet MUST be discarded.

   If there is mix of ECT(0) and ECT(1) fragments, then the reassembled
   packet MUST be set to either ECT(0) or ECT(1).  In this case,
   reassembly SHOULD take into account that the RFC series has so far
   ensured that ECT(0) and ECT(1) can either be considered equivalent,
   or they can provide 2 levels of congestion severity, where the
   ranking of severity from highest to lowest is CE, ECT(1), ECT(0)
   [RFC6040].

I would slightly rephrase the first paragraph as follows:

   Section 5.3 of [RFC3168] specifies ECN requirements for tunnel egress
   reassembly of sets of outer fragments [I-D.ietf-intarea-tunnels] into IP packets
   when at least one of the fragments is CE-marked.  If none of the fragments
   in a set to be reassembled is CE-marked, then the following two additional
   requirements apply:

and then itemize the second and third paragraphs (e.g., number them 1. and 2.).

The rationale for this rephrasing is that Section 5.3 of RFC 3168 does not specify
a process, but rather imposes requirements on what is allowed.  I also believe
that this text the bulk of what's needed to address the reassembly comment
that's been holding up these drafts.

---------------------------------

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 ...

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:

> 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.

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