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

Bob Briscoe <ietf@bobbriscoe.net> Sun, 15 March 2020 00:01 UTC

Return-Path: <ietf@bobbriscoe.net>
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 D12233A07E3 for <tsvwg@ietfa.amsl.com>; Sat, 14 Mar 2020 17:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.432
X-Spam-Level:
X-Spam-Status: No, score=-1.432 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
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 FoQQ3K5Rhz0u for <tsvwg@ietfa.amsl.com>; Sat, 14 Mar 2020 17:01:22 -0700 (PDT)
Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D748F3A07DF for <tsvwg@ietf.org>; Sat, 14 Mar 2020 17:01:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=13lw4ubq0HZ0YgegaRzRGoK/atINps3U6sGdV4ugSSw=; b=e4zTd3nadwBrV0CkK/LwckuTw byoDq3jr99av9GQgNZbr2Bxf7HSn+/EDHyRMBo7aMRX+Mg5HVAz4riUq4+xLwaYAmlkctikugdSHD Z587Ispa6wG2XzXDjtBtU9auFeRlr+ZacyCieWQDfZSrzS77jgSuqGmvH3gLuOBsK16TN/YKDUUoj 6sBP4e2AFET0FXvEi9KFSbdQsGxkHmrVV8SVQH4u1jJ34IsmekloLEMqv+5TXj8FyODG5wmNyZtCI MxrptSXRPxwZAk7osLUtbAQMYP3lQJnbmCYW+tWh/hg5xmcc+q25gGgtD97rgf0tHSYlYGy3AiuVi f2hsSLt3A==;
Received: from [31.185.135.141] (port=35582 helo=[192.168.0.4]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <ietf@bobbriscoe.net>) id 1jDGiU-000o4u-UT; Sun, 15 Mar 2020 00:01:19 +0000
To: "Holland, Jake" <jholland@akamai.com>, Jonathan Morton <chromatix99@gmail.com>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
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> <C1696430-D2D2-48BB-AB17-EFB77EE474DE@gmail.com> <5d8f11f3-9def-14b1-4923-4eb02caf51eb@bobbriscoe.net> <A633A3BD-2D52-4D55-A4A9-77119FE83CFF@akamai.com> <2f0b0c0a-146e-5a81-22ed-468752242f5b@bobbriscoe.net> <6435701F-2253-4295-B20A-B18A91F965D1@akamai.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <ff365031-375e-1a4a-3755-b483619a96ba@bobbriscoe.net>
Date: Sun, 15 Mar 2020 00:01:18 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <6435701F-2253-4295-B20A-B18A91F965D1@akamai.com>
Content-Type: multipart/alternative; boundary="------------50EE792D5971835CF8B06AE9"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Da0sagcLnvPzh6xKFdHFRUZ9w5o>
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: Sun, 15 Mar 2020 00:01:25 -0000

Jake,

On 13/03/2020 19:28, Holland, Jake wrote:
> Hi Bob,
>
> On 3/13/20, 10:56 AM, "Bob Briscoe" <ietf@bobbriscoe.net> wrote:
>> [BB] 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.
> [JH] 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 https://mailarchive.ietf.org/arch/msg/tsvwg/B2Gnb-jYPiZFYuA3YXNRhktKaT4/ )
>
>     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.

[BB] No. As I said to Jonathan (before this email from you):
     "The AQM is not marking before the tunnel ingress. It is marking 
between tunnel ingress and egress. "

There are only ever any issues with the interaction between ECN and 
reassembly if different fragments of the same packet are marked 
differently (which doesn't happen with marking that was pre-fragmentation).

> [JH] 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.

[BB] No. There's no crossing of IP packet boundaries (of course).

I think you're reading more into it than I'm saying. It's totally simple.

To be unambiguous, I've provided a schematic here:
http://bobbriscoe.net/projects/netsvc_i-f/consig/encap/ecn-reassembly.pdf

[My hosting provider seems to have screwed up the DNS change-over when 
moving me to a new server on Thursday. I think my server is accessible 
to most of the world now, but apologies if it isn't.]

"For the record", I've included a text transcription at the end of this 
email (in case my schematic falls off the web in future).

Essentially, fragmentation inflates the number of packets but reassembly 
deflates it to the original number.
So if the packets are marked while they are fragmented, unless 
reassembly deflates the number of markings, fragmented flows will 
experience incorrectly inflated marking probability.

>
> [JH] 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.

[BB] I asked Jonathan not to respond to the summary without reading the 
whole email.

That was not aimed at you. It was to pre-empt what Jonathan always does: 
reads until the first point he disagrees with, then launches into a 
response, just repeating his assertions, and snips the other persons 
carefully written arguments against each of his earlier points.

Unsurprisingly, despite my request not to, he did it anyway, which is 
why this thread is now an incomprehensible mess.

If someone doesn't agree or doesn't understand, the fastest way to 
converge on understanding is for them to quote the text they disagree 
with or don't understand, like you do.

> [JH] 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
> find).
>
> 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.

[BB] I hope it's clear now that this is not about marking before 
fragmentation (which is a non-issue).
And I hope the schematic helps clear this up.

Cheers


Bob
> Best regards,
> Jake
>
>

=============================================
"For the record" text transcription of the schematic linked here:
http://bobbriscoe.net/projects/netsvc_i-f/consig/encap/ecn-reassembly.pdf

I'll repeat the above paras below and insert statistics at each point in 
the network, using the following terminology:
* Flow F (will be fragmented), with 1500B packets (including one IP 
header) before tunnelling.
* Flow N (will not be fragmented), with 1480B packets (including one IP 
header) before tunnelling.
In both cases, tunnel encap adds an extra 20B IPv4 header.
The MTU of the tunnel ingress is assumed to be 1500B.
Layer-2 headers are not counted.

I'll track 100 packets sent by each flow over the same duration in 
parallel along the same path.
But the metrics I give are accurate to decimal fractions of packets, 
even tho that's obviously not possible.

On leaving source or before arriving at tunnel ingress:

number of packets: F: 100; N: 100
number of CE marks: F: 0; N: 0
number of bytes: F: 150000; N: 148000

>     The tunnel ingress doubles the packet rate of the flows it fragments.

number of packets: F: 200; N: 100
number of CE marks: F: 0; N: 0
number of bytes: F: 154000; N: 150000


>     Therefore, during any congestion event, the AQM marks twice as many
>     packets from the fragmented flows as the others {Note 1}.

Assume AQM applying 2% ECN marking

number of packets: F: 200; N: 100
number of CE marks: F: 4; N: 2
proportion of marked packets: F: 2%; N: 2%

number of bytes: F: 154000; N: 150000
number of CE bytes: F: 3080; N: 3000
proportion of marked bytes: F: 2%; N: 2%

CE-marked bytes are averages, assuming packets of any size are marked with the same probability.


>     Reassembly
>     restores the packet rate to that at the origin sender. And it removes
>     some of the extra congestion markings that fragmentation added.


After the proposed reassembly:

number of packets: F: 100; N: 100
number of CE marks: F: 2.03; N: 2
proportion of marked packets: F: 2.03%; N: 2%

number of bytes: F: 150000; N: 148000
number of CE bytes: F: 3040; N: 2960
proportion of marked bytes: F: 2.03%; N: 2%


Or after RFC3168 reassembly:

number of packets: F: 100; N: 100
number of CE marks: F: 3.96; N: 2
proportion of marked packets: F: 3.96%; N: 2%

number of bytes: F: 150000; N: 148000
number of CE bytes: F: 5940; N: 2960
proportion of marked bytes: F: 3.96%; N: 2%

   
>     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).

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/