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

Jonathan Morton <chromatix99@gmail.com> Tue, 10 March 2020 20:40 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 5DB463A0D18 for <tsvwg@ietfa.amsl.com>; Tue, 10 Mar 2020 13:40:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level:
X-Spam-Status: No, score=-1.849 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Ko8T06ue2EX6 for <tsvwg@ietfa.amsl.com>; Tue, 10 Mar 2020 13:40:39 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 9B4563A0D07 for <tsvwg@ietf.org>; Tue, 10 Mar 2020 13:40:38 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id i10so12079729lfg.11 for <tsvwg@ietf.org>; Tue, 10 Mar 2020 13:40:38 -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=MpEMJYsXYZpOcYIQUIPQhZu2dgp4I/ix0Ce+ogsxC7s=; b=s2BwsSXhMDnau8xkn+NZDm6tnx0p27dfEGswtKNJfQt720y2rDm54MF9FnBuNXXJtP dTcjiw4oy/7Y9IXOzFywGZt94gCiO9XgGffVqvTaqNxQt5b8cN7JJcEryylFRIhQTJQF R36imOxSfqXzN4/H17mdiAbEzxRagJEonBqwgqDRMmggWtz3lnBzTYyE8fmuRToFguZK q2FOtNd2k2glaljIrbKSnmhz69oxXAorgUNW4Xg4QGsePFfFO7nkn52FslwH4UMf/K6n ZvqaCSQsr/DE+e1DjoalVCmDt7ESSSjRXMNCLAfqFmZ8rRjV+RrNG3ciSOtx+B5t4+He omHA==
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=MpEMJYsXYZpOcYIQUIPQhZu2dgp4I/ix0Ce+ogsxC7s=; b=JYn/KM2siqkCi7vqN9zOKgUILg8AMO2Rsd1hk4NF4vFpVxFR0eadKrDUmpDBpZp2Rx YlQzGJ26IKEQkbkcZIu4bRGRddo3rpxtzc26Wu1NU+5P3tWJt0VB3RwSwIDyC2vkzL0v 2iLmbhz1x2VURwQsBBOPUx1jDvr8nHWppliV06/gm5HzBwvk/dwS274M+ANY8ebopGs3 kuj2IJiiZcJ3dQzZKdVi0AWpnl2K+N13BbqK8pftflRAK63BlbLNN5shbzh5nwxU1Dc9 Q9PsHpl6D6jPztKU3NmIMH5I5AkUYRaoqKRQHgWVNResQELkQ1K6j467+afyySrXKtIm t1vA==
X-Gm-Message-State: ANhLgQ0XWJpmTDH84JrdD+2dDPsD8/ivRKJBInnh+UYTszla/4St2omU eQa2ChrFGe+ch2Pp/RspEBg=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vufwj2NPJxP66QqrQskWK+WiJ19UHl3OtCnVTQO?= =?utf-8?q?iZzUnTWuJPj+UTK67fZOQpfdiTSo+Ekz/Q=3D=3D?=
X-Received: by 2002:ac2:5929:: with SMTP id v9mr10422881lfi.66.1583872836896; Tue, 10 Mar 2020 13:40:36 -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 f26sm7300525lfl.43.2020.03.10.13.40.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Mar 2020 13:40:36 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: =?utf-8?q?=3CMN2PR19MB40452EBBC3FB79782C7EDD7183FF0=40MN2PR19MB?= =?utf-8?q?4045=2Enamprd19=2Eprod=2Eoutlook=2Ecom=3E?=
Date: Tue, 10 Mar 2020 22:40:34 +0200
Cc: Bob Briscoe <ietf@bobbriscoe.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A8AFF070-5280-4554-9CEB-87373C96ED5F@gmail.com>
References: <CE03DB3D7B45C245BCA0D24327794936306F8925@MX307CL04.corp.emc.com> <2873ab79-19ad-0541-e3a4-d1d28dbc7ba0@bobbriscoe.net> =?utf-8?q?=3CMN2PR19M?= =?utf-8?q?B40452EBBC3FB79782C7EDD7183FF0=40MN2PR19MB4045=2Enamprd19=2Eprod?= =?utf-8?q?=2Eoutlook=2Ecom=3E?=
To: "Black, David" <David.Black@dell.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/-HNv_DsnVwssJ8Nxor9QF2G2IU4>
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 20:40:48 -0000

> On 10 Mar, 2020, at 10:35 pm, Black, David <David.Black@dell.com> wrote:
> 
> As draft shepherd, let me suggest an alternate way to think about fragmentation and reassembly that may result in simpler text.
>  
> The current situation arises in large part from viewing fragmentation and reassembly as being part of tunnel encapsulation and tunnel decapsulation respectively.
>  
> Instead, I suggest that we view all four of these as separate but related processes, specifically:
>  
> 	• A tunnel ingress encapsulates the inner packet and then fragments the resulting (encapsulated) outer packet if necessary for transmission.
> 		• RFC 6040 and this document specify the ECN requirements for encapsulation.  RFC 3168 specifies ECN requirements for fragmentation.
> 	• A tunnel egress reassembles the outer packet and then decapsulates the resulting (still encapsulated) outer packet to produce the inner packet.
> 		• RFC 3168 specifies ECN requirements for reassembly.  RFC 6040 and this document specify the ECN requirements for decapsulation.
>  
> Optimized implementations may of course mix encapsulation and decapsulation processing with fragmentation and reassembly processing, respectively, but the results are required to be the same as if the above orders of processing were followed and that processing adhered to the requirements listed above.
>  
> I think the result will be clearer, and will also make it obvious that nothing new is being required, especially if “RFC 6040 and this document specify” can be changed to “RFC 6040 specifies” in both sub-bullets above.
>  
> What do you think of this approach?

It seems like a perfectly reasonable approach to me.  We can then focus on what the two existing documents say about their respective parts of the process, and whether they remain compatible with high-fidelity congestion control (and other modern circumstances).

 - Jonathan Morton