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

"Holland, Jake" <> Fri, 13 March 2020 21:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08F7B3A1043 for <>; Fri, 13 Mar 2020 14:20:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 fGHM5Kt6ku1w for <>; Fri, 13 Mar 2020 14:19:59 -0700 (PDT)
Received: from ( [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 480613A1042 for <>; Fri, 13 Mar 2020 14:19:59 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 02DLCMkJ008069; Fri, 13 Mar 2020 21:19:14 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Vp0ZoUoUgdTwYOlLAq5nBj/T+ak37sHjAnLjFOaR0nk=; b=GpXm/poYz1lp6W+QEJ+P3ODqbCxYZDO/IX7POGkG8edvihgrnAPQTdnPOzyJRxFcv4MH 8Qtu7h4yeg3oatfhowKhax8pSzYGaQx3HdMwvCOY29oYNFO2vkfUh+X73IStPHr27kyy qeOZ8q2WtbwharvEadXV0sFxqk6l7Ok1H3xvEUAYZTbdNYfoJ8TxzJ+7bod774RWaz1y eu8FAf74phbzDbWdEfF44blLs5rs6TjKtrHWKM2+Cmn9Gzksu6e/5AVKU+2eSf+IDvGv qyF/8XqkIoe0RXgZi8aTMQl1Z+K9/HNeIqy0VhMEHrh2lmrpYDW+NPWH//Q0Dys0Li2+ YQ==
Received: from prod-mail-ppoint5 ( [] (may be forged)) by with ESMTP id 2yqtaede7f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Mar 2020 21:19:14 +0000
Received: from pps.filterd ( []) by ( with SMTP id 02DLIkPs011801; Fri, 13 Mar 2020 14:19:12 -0700
Received: from ([]) by with ESMTP id 2yqt7u11vu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 13 Mar 2020 14:19:12 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 13 Mar 2020 17:19:11 -0400
Received: from ([]) by ([]) with mapi id 15.00.1497.006; Fri, 13 Mar 2020 17:19:11 -0400
From: "Holland, Jake" <>
To: Jonathan Morton <>, Bob Briscoe <>
CC: "" <>
Thread-Topic: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)
Date: Fri, 13 Mar 2020 21:19:11 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/16.35.20030802
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-03-13_10:2020-03-12, 2020-03-13 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2003130096
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-03-13_09:2020-03-12, 2020-03-13 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 bulkscore=0 lowpriorityscore=0 mlxlogscore=999 mlxscore=0 adultscore=0 phishscore=0 clxscore=1015 malwarescore=0 impostorscore=0 priorityscore=1501 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003130095
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 21:20:01 -0000

On 3/13/20, 12:45 PM, "Jonathan Morton" <> wrote:
>    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.

Ah, thanks Jonathan.  I agree this is a good guess at the model.

I'll try my own phrasing to see if there's a chance I might be caught up now:

(1) If we consider 2 flows, one whose packets are all fragmented into 2 packets
each, and another that's unfragmented, but otherwise identically sending across an
identically congested AQM, an AQM that marks 2% of the packets in the unfragmented
one could end up causing marks on up to 4% of the packets in the fragmented flow,
as counted after reassembly.

If that successfully gets us all on roughly the same page, can we also agree
that logical-OR reassembly preserves the property below?

(2) If a receiver sees N CE-marked packets in a sequence of packets, the network
emitted at least N separate CE-marks while forwarding those packets.

To clarify one of my previous messages, (1) addresses what I was calling
"proportion of CE-marked packets" and (2) speaks to what I meant by "number of
CE-marked packets" in my response.  I was thrown by the "both number and proportion"
claim in the "long response" email.

In retrospect this looks like a semantics debate I'm happy to now abandon, though
I'm grateful for having my confusion about the discussion cleared up, if that
has indeed happened.

Anyway, coming back to the original thread: I certainly do think the (B) option
(from )
as expressed in draft-ietf-tsvwg-rfc6040update-shim-10#section-5 takes positions that
don't seem backed by wg consensus.

I also think that David's suggested approach (in sounds
like the best option on offer.

FWIW, I prefer David's suggestion to the (C) option of deleting any mention of
fragmentation in hopes that nobody implements something 3168-compliant, on the theory
that it's something we might later update.  Clarity about the existing relevant specs
seems just better to me, and this doc can also be updated if we do indeed update the
reassembly rules at some point.

Best regards,