Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: Suggested Fragmentation/Reassembly text

Jonathan Morton <chromatix99@gmail.com> Tue, 08 October 2019 22:55 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 0388F1200DB for <tsvwg@ietfa.amsl.com>; Tue, 8 Oct 2019 15:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=no 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 laW9OPbLEbbn for <tsvwg@ietfa.amsl.com>; Tue, 8 Oct 2019 15:55:13 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 5A7211200B6 for <tsvwg@ietf.org>; Tue, 8 Oct 2019 15:55:13 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id a22so524329ljd.0 for <tsvwg@ietf.org>; Tue, 08 Oct 2019 15:55:13 -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=T5JxyiPDKBB0RHVrg96ewBGX1rvBBaU/mWWEVQFZ9Lg=; b=PAqZaXST6b3FlvL0bfIehYYHewS6Bmd85wXYhvIMMBMsOw8Z03sAfcwhJRykiZvGfL MDLQP30oeMR9VLigBeMoA/SD06QHIYkZUcQij1QCZugEqkUpkWvng0yIS40cu2G1gz3V /JAqsvvY0YfoisjRJCqM/Z49QVuo0tDK76j2cS4cHiY81LXsKIsjnbPJRhbRCGy/VG1F pTsjDmBEyfn2c2FcXCvaSe9LNcqsxXjWx11i34A5zqmSVXSxjK0M6PsRrNa8VfLvBmrl tllIGtaxoSJsv0DBWWHUmVAdX5tj2WIDvOjYqZpg4PmBJCBHRNiFurTJQzAQHVZWc3zh Vcew==
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=T5JxyiPDKBB0RHVrg96ewBGX1rvBBaU/mWWEVQFZ9Lg=; b=j1zabrueLJYJtP/JO8OX0nIEQYjKI9gToNq5qVDOeatAcnY6pKVydSsGIz1oLwHsWR T9G9pABeDmXGSVBcX5ml4YOBw0ta68O7Zevz7lMGyh3OMk6K7RiBWkpRb3kTtarG3n9m +a7I4Yfx+YGx3YqTVehojpim/i4h5Ftf1tV3znd6DyxRMtfNCXA9+765YU2R6boLJE0U 23NH3FvPGzRiDdt8dycp5k47YnSgrxuJ82pgdi2ZdGmkmCLrjK0LgD7pHQ1JlG1gUPld 9JShxBxoLCXUO+90D2n5giY652KrnOESTX/WtOwz84WJabsWjlLwtV/c87+6yMzCKx7q mugA==
X-Gm-Message-State: APjAAAXV2fQMZzog4G9iLuLcmzxAeYoZkBwROSVFafiSGzAbQwkVeg5Z StDILcuNeB8ctI6yqDBHhIs=
X-Google-Smtp-Source: APXvYqxryTJT2FPU5PO7PfLewtXtIO1gRitfyMNcPHBiROxFipWfkOzVwsebmauo/bLm4OXQ3PLeGw==
X-Received: by 2002:a2e:9f4d:: with SMTP id v13mr358598ljk.226.1570575311446; Tue, 08 Oct 2019 15:55:11 -0700 (PDT)
Received: from jonathartonsmbp.lan (83-245-232-88-nat-p.elisa-mobile.fi. [83.245.232.88]) by smtp.gmail.com with ESMTPSA id g21sm20630lje.67.2019.10.08.15.55.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Oct 2019 15:55:10 -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: <CE03DB3D7B45C245BCA0D24327794936307662EA@MX307CL04.corp.emc.com>
Date: Wed, 9 Oct 2019 01:55:08 +0300
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1920ABCD-6029-4E37-9A18-CC4FEBBFA486@gmail.com>
References: <CE03DB3D7B45C245BCA0D243277949363076629A@MX307CL04.corp.emc.com> <CE03DB3D7B45C245BCA0D24327794936307662EA@MX307CL04.corp.emc.com>
To: "Black, David" <David.Black@dell.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/J-tS5_NryJlG2Zkj_MIZzZFrxwM>
Subject: Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: Suggested Fragmentation/Reassembly text
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, 08 Oct 2019 22:55:15 -0000

> On 8 Oct, 2019, at 10:51 pm, Black, David <David.Black@dell.com> wrote:
> 
> **NEW**: Beyond those first two paragraphs, I suggest deleting the rest of Section 5 of the rfc6040update-shim draft and substituting the following paragraph:
>  
>    As a tunnel egress reassembles sets of outer fragments
>    [I-D.ietf-intarea-tunnels] into packets, it MUST comply with
>    the reassembly requirements in Section 5.3 of  RFC 3168 in
>    order to ensure that indications of congestion are not lost.
>  
> It is certainly possible to continue from that text to paraphrase part or all of Section 5.3 of RFC 3168, but I think the above text crisply addresses the problem, and avoids possibilities of subtle divergence.  I do like the “reassembles sets of outer fragments” lead-in text (which I copied from the current rfc6040shim-update draft) because that text makes it clear that reassembly logically precedes decapsulation at the tunnel egress.
>  
> Comments?

Looks good to me.

The one case this doesn't really cover is what happens when a fragment set has a mixture of ECT(0) and ECT(1) codepoints.  This probably isn't very relevant to current ECN usage, but may become relevant with SCE, in which middleboxes on the tunnel path may introduce such a mixture to formerly "pure" packets.  From my perspective, a likely RFC-3168 compliant implementation of arbitrarily choosing one fragment's ECN codepoint as authoritative (where it doesn't conflict with other rules) is acceptable, but this doesn't currently seem to be mandatory.

With the above language, it should be sufficient to update RFC-3168 to cover this case at an appropriate time, rather than scattering further requirements in many documents.

 - Jonathan Morton