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

Jonathan Morton <> Thu, 03 December 2020 16:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 104F93A0EF1 for <>; Thu, 3 Dec 2020 08:07:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Status: No, score=-1.848 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AHyoMezE5lKm for <>; Thu, 3 Dec 2020 08:07:20 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 886D03A0EB2 for <>; Thu, 3 Dec 2020 08:07:20 -0800 (PST)
Received: by with SMTP id a9so3511384lfh.2 for <>; Thu, 03 Dec 2020 08:07:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8Kcz+RaXgbLS8BwOoy04ajPM8tnbnNfbIKShsEY3JEY=; b=O92S5ZKoYvVd7MfhvBXrTQOPMvWNdV42B2VF3kS3jsK8Wb/rkRRISco2jw4PXZNrvJ 8Kef4XRVD66fjqA/iGjRqcghfniwQYMA6M6b5eWyX2gL+7coK0n5ugsCpXG1r+M74u6O Hi90o7nmGXvdetQGtpAYjHS5unLsbjmhw3zZoSeMXMqf1+QcrAtk0jxGySJT6oX9kgy3 JWM5A1svN0Hr7D+CErzDB2QUNqXLpy2gV5bf9OeSkL1hPhvKoS787DEM4/cwgKRLkxIf 7zICWl+Wl37GGE/lvDANX+7wErS2uEe70kvl/GUYSUnHQlA5NCZBaasCzCA0dO9l1mBd 7EjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8Kcz+RaXgbLS8BwOoy04ajPM8tnbnNfbIKShsEY3JEY=; b=m4Q6zkPc+F0mkj+NFfbC1Cnka2+2j3ZTJSq2M3+WZ3xWuz63WoqX2DgXH7q0f6BBrd 590OwYC0l7wvaZkW6WHG7OiBPQBQQyVSocSxJ8UzKgtfrVL/bBTJCj99BkBtFcC+5FWa 8wpbjRpwn/FS/EYGDgNhJ7vIdgl7t9bwfBvkCG8krbMcUujfz8/pnYG7apBq/ZAmhb67 kae0yZ9WHn45h/1Ruqb8JFYPJ3+7+524RAHw/aRK41GxAMs+ajsL3t+ok8b0MKgA3ErU jCmoCC8y6IVXOlX4efQJ9FgwQGRHfgmHMuIUU6A3XjecPYNx4RpO+yhVXdmjfV/voC5s 8CZQ==
X-Gm-Message-State: AOAM533ezTFX/k/Kg207wJZMFDVoKT1wOFdNK4II1Sca0LtRFECqqC1P jH5DYxAuy1HWgs15LCJvqkQ=
X-Google-Smtp-Source: ABdhPJweW+74X1A6oSFXosOABH43uXH0N0Bx2axoS0zuKWkgjeoHyXsJJFlYt37T98A2aabupdFCyQ==
X-Received: by 2002:a05:6512:2103:: with SMTP id q3mr1585047lfr.11.1607011637386; Thu, 03 Dec 2020 08:07:17 -0800 (PST)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id 16sm675653lfr.85.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 08:07:16 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jonathan Morton <>
In-Reply-To: <>
Date: Thu, 03 Dec 2020 18:07:14 +0200
Cc: Markku Kojo <>, David Black <>, Joe Touch <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Bob Briscoe <>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <>
Subject: Re: [tsvwg] draft-ietf-tsvwg-rfc6040update-shim: SuggestedFragmentation/Reassembly text
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Dec 2020 16:07:22 -0000

> On 3 Dec, 2020, at 4:06 pm, Bob Briscoe <> wrote:
> I see that all of Jonathan, David and you Markku are happy with reassembling a mix of ECT(0) and ECT(1) to result in either ECT(0) or ECT(1). (for now). I think we can go one better than that, still without precluding a more specific RFC later. Here's proposed text:
> After the following para:
>    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.
> Add:
> 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 [RFC3168], 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]. 
> Rationale: This avoids constraining future RFCs, but at least lays out all the interoperabilityrequirements we already have for handling this mixture. Then if an implementer wants to just default to choosing one, it hints that they should choose ECT(1).

This seems reasonable to me.  The text could do with a proofreading pass, but the technical content makes sense.

 - Jonathan Morton