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

Jonathan Morton <> Fri, 13 March 2020 19:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD2FD3A0CC6 for <>; Fri, 13 Mar 2020 12:45:28 -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 4kINBBfjc6hI for <>; Fri, 13 Mar 2020 12:45:27 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C9353A0C9D for <>; Fri, 13 Mar 2020 12:45:26 -0700 (PDT)
Received: by with SMTP id n13so7044759lfh.5 for <>; Fri, 13 Mar 2020 12:45:26 -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=UN7uE+Ts87JJmn08CVY72tpIaLdC7KDJ1i08DetjSOU=; b=nHgqEonkw3dftoebtzK0VBjFvF8h1y/P3IyMtT9T/lho3sDHUuLXs429RAg8VIJyD+ DSRjkFxjI8EPgLF4pI45DZWIVqyGaoZjsRN6PVkjf3EVXQKFXRY57ISHWtVKHH18C9Jx yHsv1Vq2+NIa4qj/BsFRmK6fKkaXsA8cOwVp0h6iFqy5OGdQ0Yc4dM5FoTO8+iNji7Ge XS9nGq921eBVSG158UWYYm+kEMfTJS8JPApnCVVLeCgWPVKMtiw/CcLswWL5WmcrnzZL 9bzvFWLYTtQvYRjV00YsShOnLlIuXnuLN6HLR1KAIJYHoga8VKktXMkCYz8vBo3yubrX sBOg==
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=UN7uE+Ts87JJmn08CVY72tpIaLdC7KDJ1i08DetjSOU=; b=EE7+VHH7mONbBJgoC8b5hO85asCS7M1/40/7/oZRYK8MRAuw4hPQcayjugKJ4nWRs4 cJgozdhkDY9OpfMbLcmVhAE1krMVXaPXa0Hk5AcnYdo4HsvpzYmt8P5tZfxHhNoMXzrs C6xKw4qTKOVRFrQb8kuTaxXEAVJ0AOK9c+jplluq6Y6BcLy4F5MzvZEFKIvepNUZJMzu aLWiBnQGKP+L+eD6HR36xE6G6ojDArPfv2xfYzq1vXUg9t9MT0q+0h95ma8G9aUA1k6p I3Vcjyk5zRKL4Qh3yoFGXvBusIienDjOSWtA3akb32Q0maWG1R10dMtFH479B1HFGuBP bV3w==
X-Gm-Message-State: ANhLgQ3qXTPu5JBkZJHVdFN/7vbsd9sGR6PQXV+R1dfp1BlfEnp+g9kN zbcc7LZuEzyjq+18AghjVyg=
X-Google-Smtp-Source: ADFU+vuUwpSiOeviu0I+KReFEwU7QuAtu6gQFXm2JVH02vBbYpzhLbWKrb5+BypABD8P+3aHW/47Pw==
X-Received: by 2002:a19:cbca:: with SMTP id b193mr9256747lfg.58.1584128724453; Fri, 13 Mar 2020 12:45:24 -0700 (PDT)
Received: from jonathartonsmbp.lan ( []) by with ESMTPSA id i23sm14684846ljg.102.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Mar 2020 12:45:23 -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 21:45:22 +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 19:45:29 -0000

> On 13 Mar, 2020, at 8:50 pm, Bob Briscoe <> wrote:
> Pls can you take these sort of emails off the IETF lists - I'm sure no-one cares for this sort of content-free conversation.

No, because I think this *is* actually important to establish and understand.

>> I'm trying to establish this fundamental point first.  Until I can figure out what you *do* mean by CE marks being doubled, there's no point in discussing anything more subtle.
>> So again, I ask: what context am I missing?

> I said "No." I.e. the AQM is not marking before the tunnel ingress. It is marking between tunnel ingress and egress.
> How can I know what context you're missing if you haven't read the email? Presumably that means you're missing all the context given in the email.

As it happens, I think I now understand what you mean.

If you assume the AQM on the tunnel path is marking probabilistically, then doubling the packet rate over time (by fragmenting the original packets into two smaller ones each) also doubles the marking rate over time, and (assuming sufficiently independent probability of marking) the number of reassembled packets carrying marks also doubles.

You could have just *said* that, and not left me and Jake guessing for the past half-dozen e-mails.  I did not find such a clear statement in your earlier "main" comment either, despite its length.

I should also note that this effect does *not* occur with a time-schedule marking AQM such as Codel, in which the marking rate over time is independent of the packet rate, so if the packet rate is doubled the marking probability is actually halved.  Hence the number of reassembled packets carrying marks remains the same.

With *that* out of the way, I can now address the substance of your main argument.

First, on an RFC-3168 flow, the proportion of marked packets does not matter.  It only matters whether a later CE mark occurs before or after the CWR corresponding to an earlier one - ie. *when* it happens.  If before, then it is ignored.  If after, then it triggers a fresh ECE/CWR cycle.  Since CWR corresponds to the sender performing Multiplicative Decrease, the likelihood is that the queue will drain coincident with it, and no further CE marks will occur until the growth phase of the AIMD sawtooth completes again.

The situation is different for L4S because it performs, and relies on, precise feedback of the number of CE marks, regardless of their spacing.  In that case, an inflation of the marking rate would be expected to have some effect.  But if the control loop is properly closed, that effect will simply be to settle at either a shallower queue depth or a lower marking probability, depending on details of the AQM involved.  As noted above, Codel does the latter inherently.  I think a PI-based scheme would do so as well.

I therefore see no reason to complicate RFC-3168's handling of CE marks upon reassembly of fragmented packets.  We can have a separate conversation about ECT(1), in that other thread I haven't responded to yet.

 - Jonathan Morton