Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-encap-guidelines and rfc6040-update-shim drafts, closes 6 May 2019

Jonathan Morton <chromatix99@gmail.com> Wed, 10 July 2019 15:38 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 A16091202E0; Wed, 10 Jul 2019 08:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.453
X-Spam-Level:
X-Spam-Status: No, score=-0.453 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 B30v7mFJx8fC; Wed, 10 Jul 2019 08:38:33 -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 BA45012027A; Wed, 10 Jul 2019 08:38:32 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id v18so2555461ljh.6; Wed, 10 Jul 2019 08:38:32 -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=FUvNs3HmXWRVoO+bVzALRMYCUN598G4IDL0Nmff457Q=; b=rmrMN1Pr1dbVb0GQfh3pFLmP4vHVdGJQ27G1k4JOjkafuu/XSZUeSdX96Pi/XK+51W RhizKfcyLLyPxvxem4fz9hoUE0uN6U/QIN2EoDG3pWKzkQfm/Mf85KlqWC9g45Ky6jCn NbP4Tj9SCD8ZIvQR2QrO1X+ASnkhoxyeI72iVp3sFygi5FpBwZqZYmOim7WObeZwsW/U YgFT9iC1M/urSjZREJJBtyX+Tf2SHRTTczGJ/rAJ3z6FCWSH8LvTh8khzL9dnG3dhliy z+8RQRMHZMsAWE8MHOBrODODTLJQilohv7Wtv6oB8I2nBrVFVHzQ0zzJH+UWc+XwOztD F49A==
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=FUvNs3HmXWRVoO+bVzALRMYCUN598G4IDL0Nmff457Q=; b=AUvHHjnlnIW+VilMTukj5oZa9sQNXOwEY2ALYsAXshXFUexSJE5ehE2XSsd/nhwEhK 9HqEJNyqF3jgSBbiz1Ft9XJMGP2YmmUNZL8PlsAdnn5qxvq21UM9Jkuoph9G5hFFXkVU 9TWbFRZEX02CHEgzxeEMgrRst2UJiuTP+nX2yiRVA8g7/PLnjMk7+Sob+NdyTu4/aO6p vb8KBD60r2mm2mnUefMM+57gXQvCMc3Ml0tg52r8IYY94U3sKpBsg5BOiiaHM+c7nhd/ EiQBJe2DYUPiAQrCpQpIpr2lufluLcyyOr83O2FYFFHalGjqCW5RhEpA1iZALeyIUzJQ nRUg==
X-Gm-Message-State: APjAAAUoBiyyhcjP+Hv80O8TsRq2uwT4UZ84tEmUfmMOLJZ56LYlVbvQ hiNS5P6S8aQgkLFiML7fErQ=
X-Google-Smtp-Source: APXvYqy4YvCq1y3m9NWV6jUIATZA0rh6zkdKWpXk+tqkBBOwwCdxL/vatg5Y0dUeO8J0+KClZJ3WoA==
X-Received: by 2002:a2e:4794:: with SMTP id u142mr18056802lja.222.1562773110710; Wed, 10 Jul 2019 08:38:30 -0700 (PDT)
Received: from jonathartonsmbp.lan (83-245-234-41-nat-p.elisa-mobile.fi. [83.245.234.41]) by smtp.gmail.com with ESMTPSA id s21sm533377ljm.28.2019.07.10.08.38.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jul 2019 08:38:29 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <d7252ffe-e13c-243c-efa2-bb15e67bd758@bobbriscoe.net>
Date: Wed, 10 Jul 2019 18:38:23 +0300
Cc: Joe Touch <touch@strayalpha.com>, "Black, David" <David.Black@dell.com>, "int-area@ietf.org" <int-area@ietf.org>, tsvwg <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DA78B7A6-92FB-4BCB-A74A-DF53ED722714@gmail.com>
References: <CE03DB3D7B45C245BCA0D243277949363052958E@MX307CL04.corp.emc.com> <598B8434-3B6D-434A-B963-7FEE04D9770B@strayalpha.com> <70abde72-0091-66e3-b819-ad839e1fd028@bobbriscoe.net> <d7252ffe-e13c-243c-efa2-bb15e67bd758@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/-eFAAxQmIJp20n-Zu1-qwbzElMc>
Subject: Re: [tsvwg] [Int-area] 2nd TSVWG WGLC on ecn-encap-guidelines and rfc6040-update-shim drafts, closes 6 May 2019
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, 10 Jul 2019 15:38:34 -0000

> On 8 Jul, 2019, at 3:27 pm, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> 
> These are quite significant updates to outer fragment processing at the tunnel egress. But, given something has to be said, I can't think of a better way (see the original quoted email about why the logical OR of the ECN codepoints as defined in RFC3168 is no longer sufficient - and it's no simpler anyway).

If I may offer such an alternative approach, which avoids the need to keep persistent state at the reassembly point whilst still properly handling RFC3168, L4S and SCE expected semantics:

- If all incoming fragments are Not-ECT marked, the outgoing packet must also be so marked.

- If any fragment has CE set, the reassembled packet must have CE set.

(This guarantees correct RFC3168 and SCE behaviour for each conventional AQM marking action.  Your proposal doesn't, as it will generally result in fewer CE marks downstream especially if the smaller fragments end up being marked; subsequent upstream CE marks have to relieve a counter deficit before they will be honoured.  The tradeoff is that L4S may see some technical "over marking" but this should be tolerable.)

- Notwithstanding the above rules, the ECT(0) vs ECT(1) choice should be made according to the majority of fragmented payload bytes so marked, on the individual packet being reassembled.  In the case of a tie, break in favour of ECT(0).

(We may expect that L4S packets will be entirely ECT(1) marked except for fragments or whole packets carrying CE; this also applies to obsolete Nonce Sum semantics.  SCE and RFC-3168 flows will be ECT(0) marked by default, with perhaps some ECT(1) marking applied by SCE middleboxes.  SCE is reasonably tolerant of disruption to its markings, because the control loop is fundamentally stable.)

- A mixture of Not-ECT and other ECN codepoints is unexpected and may imply upstream shenanigans.

 - Jonathan Morton