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

Jonathan Morton <> Fri, 13 March 2020 17:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43AD83A073D for <>; Fri, 13 Mar 2020 10:56:20 -0700 (PDT)
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 b97PNvzK8BfY for <>; Fri, 13 Mar 2020 10:56:19 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA3DE3A053F for <>; Fri, 13 Mar 2020 10:56:18 -0700 (PDT)
Received: by with SMTP id n13so6794226lfh.5 for <>; Fri, 13 Mar 2020 10:56:18 -0700 (PDT)
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=Jpr1nCopBpQ8PWa3FZUTzFrRbBNz12ch6A0RkeRhc5c=; b=KDCueLDIu9zstZmNqyvMKJbwbXG51Nwye5rNBZ4HJ3tq5oCy9K5AmR6i2qgCNfBeYD mPSgRlnLTEylzJSNgwKyy7ncNKLsXApukJEEQerHLIKrVXWcF4i4PzZgv+NZB3hg9g+o E+wNg6IqljmOU/OTQvHqfiCUbAO2bnx529QWSl6sIszff1sAG7Iome4sDby4XuSul9sH 4jFDrr7R3T5k74p/zQqvb1/YOe2KThufcyCCFVmlBLiRYVDlHfopr0/LdZCar4mg8ehO q/1rdFvRfXTe2nklHEjIKyIz7ORVyN0XJYvYNJxEp0vs39bl1x3B+4Zi5+6yjw2wGNO8 aZTg==
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=Jpr1nCopBpQ8PWa3FZUTzFrRbBNz12ch6A0RkeRhc5c=; b=K2o6YVq5U8O00xV8yxYXlzAlWEmGpqDtG/ucVaNv/crgT2tTILU21MeQSPVQ3yA9Er Cd215gbuLmzhhzwo632kp28lJwdKwoViuEtJGzVlbVxiAJRz/ee1X1NoBEoCr49od+5S UK+K81yzyxPNgkBkYF9CsGc9h8wmJJd+/U325h5HKaLXpzXWbNR+/NvVEjBzhMjuIzb7 3BVbsKDALYHpCGwyazcp1blVcEo98Y2nQ0/TXgK7OY1pG4Us3bRgVVvdxp5VvntwLbns ia5aOX7kfZZSb7Zm4+zl/h5X09g4l2pYpsQljWXYNdhBJrejt896QPPeTun0cXv0cvmW qe5g==
X-Gm-Message-State: ANhLgQ10m+k0TmTOrKgsZyy2h7ZudN0us3GA3kZDXy703Av/bcmFW91o D+0cECdlKMcHiBTXQtCpsfE=
X-Google-Smtp-Source: ADFU+vt8rGMU+ZigDn9XJnAwIzcC+UdayOqj7labSGqkwvy0jYLvYmNTpFlCO6xZp9bB6frwUP+Y6g==
X-Received: by 2002:ac2:562f:: with SMTP id b15mr817913lff.54.1584122177102; Fri, 13 Mar 2020 10:56:17 -0700 (PDT)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id 18sm10523848ljv.30.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Mar 2020 10:56:16 -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 <>
In-Reply-To: <>
Date: Fri, 13 Mar 2020 19:56:15 +0200
Cc: "Black, David" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Bob Briscoe <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)
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: Fri, 13 Mar 2020 17:56:21 -0000

> On 13 Mar, 2020, at 7:45 pm, Bob Briscoe <> wrote:
> No, you have to read the email. The doubling comes at fragmentation, then the reassembly is meant to compensate for it.

Ah, so the situation is that the CE mark occurs *before* the tunnel and the fragmentation.  But this should not cause any problem in the end, either, because the packets are reassembled before being interpreted by the transport receiver.  Reworking my earlier example:

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

TA1(ECT) TA2(ECT) always reassembles into TA(ECT), and TB1(CE) TB2(CE) reassembles into TB(CE) under RFC-3168 rules.  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.

So again, what context am I missing?

 - Jonathan Morton