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

"Holland, Jake" <> Fri, 13 March 2020 19:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE3443A0C78 for <>; Fri, 13 Mar 2020 12:29:16 -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 FLGGIPidZUFS for <>; Fri, 13 Mar 2020 12:29:15 -0700 (PDT)
Received: from ( [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2074C3A0C51 for <>; Fri, 13 Mar 2020 12:29:14 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 02DIu1O4009935; Fri, 13 Mar 2020 19:28:31 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=D2ePsJAhYZEN6l43NBjGetgK4X153i64x2JYzQYyd44=; b=ZffOxtgP4DHngN7zwKbKreXcfJrHHrSBsE0J6zxmFUKBs/0GldS7ZpJWkjd9dES6eHaH ptFXl/wxT879Ou5V/veqa+bNNaWz0PktJCDYUctEqIGo4F4GyuULkjCz7TYcGT13Cr5Q 1TtSY44fhj66asvjAl1tDA/0tir8RNHmn/LAA1C/6JzPP7fYNu2l4lz5N3+PQHiGhG+b O8OefBwUgpOmqchHvXVFQ72A1t6pXsHOeI3FuEYcA09wo6qURw8wGGegrO/DhYmIQGe6 4x2RUEfrT+gJy1E0w83IjOL9GG490+4ZUK5UrdT29evwYO0qSjYbwA3tGlAx+qx2b667 lQ==
Received: from prod-mail-ppoint2 ( [] (may be forged)) by with ESMTP id 2yr1cw3kq6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 13 Mar 2020 19:28:30 +0000
Received: from pps.filterd ( []) by ( with SMTP id 02DIlV5N019234; Fri, 13 Mar 2020 15:28:30 -0400
Received: from ([]) by with ESMTP id 2yqt7v39kp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 13 Mar 2020 15:28:30 -0400
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 13 Mar 2020 15:28:27 -0400
Received: from ([]) by ([]) with mapi id 15.00.1497.006; Fri, 13 Mar 2020 15:28:29 -0400
From: "Holland, Jake" <>
To: Bob Briscoe <>, Jonathan Morton <>
CC: "" <>
Thread-Topic: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)
Thread-Index: AQHV9wxfjE6kv5wi1E2Ik04m06OEOqhCtNwAgAQPnYCAABDegIAALEUA//+WpYCAAH2IgP//pPgA
Date: Fri, 13 Mar 2020 19:28:29 +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_08: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-2003130090
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-03-13_07:2020-03-12, 2020-03-13 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 mlxscore=0 bulkscore=0 malwarescore=0 suspectscore=0 clxscore=1015 mlxlogscore=999 phishscore=0 adultscore=0 spamscore=0 lowpriorityscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003130090
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:29:28 -0000

Hi Bob,

On 3/13/20, 10:56 AM, "Bob Briscoe" <> wrote:
> Same answer as for Jonathan - I'm talking e2e, not just reassembly, 
> taking account of frag and re-assembly relative to another 
> non-fragmented flow. All carefully defined in the email (so pls don't 
> question this sentence, 'cos I didn't want to re-write all the carefully 
> defined stuff again). You have to read the build-up to the scenario too.
> Of course, if I'm wrong, I'll admit it. However, not if someone just 
> asserts that the summary is wrong without pointing to the flaw in the 
> body of the argument.

I guess I'll try again with the example from further down the body of the
email, which seems to contain a more explicit form of the claim in question:
(From )

   The tunnel ingress doubles the packet rate of the flows it fragments. 
   Therefore, during any congestion event, the AQM marks twice as many 
   packets from the fragmented flows as the others {Note 1}. Reassembly 
   restores the packet rate to that at the origin sender. And it removes 
   some of the extra congestion markings that fragmentation added.

   For example, if 100 packets of the unfragmented flow received 2 marks, 
   100 packets of the fragmented flow would turn into 200 fragments, 4 
   would be marked, then reassembly would turn them back into 100 packets 
   and a little more than 2 would be marked (because of the extra size of 
   the inner headers).

   If reassembly used "logical OR" instead, of the 100 forwarded packets, 4 
   would be marked (3.96% to be precise).

This seems mistaken to me.

If 2 of the 100 packets are marked pre-fragmentation, then fragmentation makes
it 4 of 200, then logical-OR reassembly will result in marking only for 2 packets
of the 100 post-reassembly.

There's no opportunity to increase the count of marked packets without receiving
new CE marks while fragmented because the reassembly doesn't cross the un-fragmented
packet boundaries.

It seems to me you're asserting that this would happen, but using a count-based
model (or maybe stream-based model?) that mistakenly fails to account for the way
reassembly avoids crossing IP packet boundaries of the pre-fragmented packets.

Also, since it seems to be an issue:  I don't think this line of inquiry is just
disagreeing with a summary or nitpicking at a minor point--the assertion that the
count of CE-marked packets can increase e2e because of fragmentation and reassembly
seems fundamental to the claim that logical-OR reassembly is broken.

I still leave open the possibility that I've misunderstood, so I'm asking for an
example of a packet sequence e2e that demonstrates how the count of CE-marked packets
can increase due to fragmentation and reassembly, because until I can understand that
it's possible, I tentatively conclude that the bulk of the argument presented was
built on a fundamental error.

I have read the email in its entirety and found no explanation of a fragmentation+
reassembly chain of events that allows a sequence of packets containing 2
pre-fragmented marked packets to turn into a sequence with 4 post-reassembly marked
packets, unless at least 2 extra marks were added while fragmented (the quoted part
above merely asserts it can happen, without an explanation of how anywhere I could

If this is possible in a conformant network, I'm asking anyone who can explain it to
please do so, of course I don't limit my request to Bob.

Best regards,