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

Jonathan Morton <chromatix99@gmail.com> Fri, 13 March 2020 14:03 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 88D733A0798 for <tsvwg@ietfa.amsl.com>; Fri, 13 Mar 2020 07:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
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: 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 dK7mrdD13iDA for <tsvwg@ietfa.amsl.com>; Fri, 13 Mar 2020 07:03:54 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 EA3823A078F for <tsvwg@ietf.org>; Fri, 13 Mar 2020 07:03:53 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id w1so10669707ljh.5 for <tsvwg@ietf.org>; Fri, 13 Mar 2020 07:03:53 -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=UnRAli0/OA5pXH4jQ2v9uTjWdn/oKsI793iq+rlS5lU=; b=D5M7rmQ4GsfAd6Xz3xLZCb+Jjd0kba8Y8atFj1WgHwUayKcmML9LgP9SiIEAWYvZ1j vvo/IUtG9/jEwdpRrdp+1KA9bPkA2eaBERvv0sqwNkUe1t/Q7fVwmWhGiqt3aaZeqWOB CLMkYSLTiT77chyyUPHwSL3ugcrfxZsYIl9GAprXF61lWXkx+pbpe6Cj9HtBtjffwCY8 xrRXSJ/7bz9hvKc5oKLOq/vQMPJhdQgcyWLPrNuJAiQjLZypEvCxQHRf5Yo+XS+wk0/+ l4daGqG2nJgwJDuUNpkficzO04MH/wn7QQyyWgS3z7qynvyFSSrq7eoAuWvcdNbwwbQa UDzg==
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=UnRAli0/OA5pXH4jQ2v9uTjWdn/oKsI793iq+rlS5lU=; b=dmyeMXautM87mZbII+lOLgyqXsIoKVtOXu7zqk7liBgmw/+QUUxoE6nHoVmSrYHXqd gj4gTixMr0hTDzOwhPCYZ3ElKdx7zTtvqTI0t0mI8RW51RrzSzO/vZMEOSVKqt7ARI2c 2RAoX1pUqVqnKmXy9dK33rFAR+mWuWVCJxLV5nEmHiHXZunKNon/P8Cx1+RlzFyEB6uS eo4cell7OD43aVJ2Oorc3njBxEFY2tWICIUEIxe/q4hMJj9v1tWKPTfqyRmWyVSpgCRp fnHWbwfVkgTbtd98aiTnEQxEThaJdHEfjcLPiBI+GhB28XmU+qRwweiSTBs7FqzOek26 mJOg==
X-Gm-Message-State: ANhLgQ2JKQhTi6Bh2czDYolXsgUpHW1sVq4ndb0zMrcJ5jjYBU3uXrmD mOU+P8JzHQT8tuXGB8SdYQhG7jT8
X-Google-Smtp-Source: =?utf-8?q?ADFU+vuv535Xl6gNJtr0PDy1K63SmJR1mBMeczicF8qk?= =?utf-8?q?NG2EI1kScEBhq1YZn2COIkl73rl6+DlQ/A=3D=3D?=
X-Received: by 2002:a2e:869a:: with SMTP id l26mr8292233lji.286.1584108231997; Fri, 13 Mar 2020 07:03:51 -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 u10sm3299843ljj.88.2020.03.13.07.03.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Mar 2020 07:03:46 -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: <3ee6e427-9dc9-e885-21a9-df9e35d99006@bobbriscoe.net>
Date: Fri, 13 Mar 2020 16:03:37 +0200
Cc: "Black, David" <David.Black@dell.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C1696430-D2D2-48BB-AB17-EFB77EE474DE@gmail.com>
References: <CE03DB3D7B45C245BCA0D24327794936306F8925@MX307CL04.corp.emc.com> <2873ab79-19ad-0541-e3a4-d1d28dbc7ba0@bobbriscoe.net> <B6D58310-41E0-4172-B555-D28E7926A0B5@gmail.com> <3ee6e427-9dc9-e885-21a9-df9e35d99006@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/JQwjTEkJMngz_ZzJl2XNKk_S5YY>
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: Fri, 13 Mar 2020 14:03:56 -0000

> On 13 Mar, 2020, at 3:03 pm, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> 
> Specific problem: End-to-end, taking into account both fragmentation and reassembly, the "logical OR" reassembly process required in RFC3168 roughly doubles boththe number and the proportion of CE marked packets and the number and proportion of CE-marked bytes (relative to a parallel flow with slightly smaller packets that is not fragmented).

Before I attempt to address your arguments in detail, I want to clarify something fundamental.  I think this may be one good reason why David Black wants to separate the concerns of reassembly (covered by RFC-3168) and decapsulation (covered by RFC-6040) - a sentiment I completely agree with.

Let's consider two original, consecutive IP packets: A B.  They are encapsulated by a tunnel, producing TA TB.  These are both larger than the MTU, so are fragmented into TA1 TA2 TB1 TB2.  On the tunnel path, an AQM applies a CE mark to TB1.  Eventually these packets are decapsulated, prior to which they must be reassembled, and the CE mark must be preserved somehow.

What you seem to imply is that somehow, TA2 and TB1 can be reassembled into one CE-marked packet, leaving TA1 and TB2 separate, and that decapsulation may then apply the CE mark to both A and B.

But this does not jive with what I know about IP-layer fragmentation, in which TA1(ECT) TA2(ECT) always reassembles into TA(ECT), and TB1(CE) TB2(ECT) reassembles into TB, which is then CE marked by the RFC-3168 bitwise-OR rule.  We would then have A(ECT) and B(CE) transmitted onward, which seems to match the intent of the AQM - in particular, the number of CE marks is preserved, not doubled.

What am I missing from the context of your objections?

 - Jonathan Morton