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/
- [tsvwg] Status of ECN encapsulation drafts (i.e.,… Black, David
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Black, David
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Jonathan Morton
- [tsvwg] SCE / L4S and fragmentation (was: Status … Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Holland, Jake
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Holland, Jake
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Holland, Jake
- Re: [tsvwg] SCE / L4S and fragmentation (was: Sta… Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Sebastian Moeller
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Rodney W. Grimes
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Sebastian Moeller
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] SCE / L4S and fragmentation Bob Briscoe
- Re: [tsvwg] SCE / L4S and fragmentation Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Rodney W. Grimes
- Re: [tsvwg] SCE / L4S and fragmentation Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Joseph Touch
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Joseph Touch
- Re: [tsvwg] SCE / L4S and fragmentation Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Bob Briscoe
- Re: [tsvwg] SCE / L4S and fragmentation Bob Briscoe
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Sebastian Moeller
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Sebastian Moeller
- Re: [tsvwg] SCE / L4S and fragmentation Sebastian Moeller
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Jonathan Morton
- Re: [tsvwg] SCE / L4S and fragmentation Wesley Eddy
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Joseph Touch
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Joseph Touch
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Joseph Touch
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Rodney W. Grimes
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Joseph Touch
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Jonathan Morton
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Joseph Touch
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Rodney W. Grimes
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Joseph Touch
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Rodney W. Grimes
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Joe Touch
- Re: [tsvwg] Status of ECN encapsulation drafts (i… John Leslie
- Re: [tsvwg] Status of ECN encapsulation drafts (i… Holland, Jake
- Re: [tsvwg] SCE / L4S and fragmentation Black, David