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

Bob Briscoe <ietf@bobbriscoe.net> Fri, 13 March 2020 17:54 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 DB3603A053F for <tsvwg@ietfa.amsl.com>; Fri, 13 Mar 2020 10:54:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.433
X-Spam-Level:
X-Spam-Status: No, score=-1.433 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, 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 rqnKl450Js6f for <tsvwg@ietfa.amsl.com>; Fri, 13 Mar 2020 10:54:20 -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 728843A0474 for <tsvwg@ietf.org>; Fri, 13 Mar 2020 10:54:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To: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=QAQEuLJu1OOQMJtXdFrWZGtQgaRxbk3KzUKcUiHjL+4=; b=ItcIk1hFVFuK+Av0EYq89zxz6T FvYSftFsfxtxU4UA1PIB3TuB94Tm5J25poPrcrDDOtK8ppUWOoGnCTgEdh18TgK04L0ipT2+VKbfT yiuJ002+OZUKsoLVWxg+zTNSeEfzJGAcWPQK2jnbj+htpEyUbhEn1RkA2cNrH2DtAShpJIFbFpcUi y7jsHIp3Doud8knAK6/uTwB0Q7Uc6QT9psqYq6ib5e4/5TID9JoRbpSgRxuk0r2B5G97SavLqCVfC wnk6KoHpzjI/WiqmKFY3Aw/EpxIBiGKkWfA02noTOq+vsiPlv3UwkZtQlyBewpIbp2mBOSBf/bIvj mCzmIYrQ==;
Received: from [31.185.135.141] (port=39332 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 1jCoVm-00FR3H-BY; Fri, 13 Mar 2020 17:54:18 +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>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <2f0b0c0a-146e-5a81-22ed-468752242f5b@bobbriscoe.net>
Date: Fri, 13 Mar 2020 17:54:17 +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: <A633A3BD-2D52-4D55-A4A9-77119FE83CFF@akamai.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
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/Dg-BI1SEapsnrws808qoHctJn6w>
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: Fri, 13 Mar 2020 17:54:22 -0000

Jake,

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.



Bob

On 13/03/2020 17:24, Holland, Jake wrote:
> Hi Bob,
>
> On 3/13/20, 9:42 AM, "Bob Briscoe" <ietf@bobbriscoe.net> wrote:
>>> But this does not jive with what I know about IP-layer fragmentation, in which TA1(ECT) TA2(ECT) always reassembles into TA(ECT), and TB1(CE) TB2(ECT) reassembles into TB, which is then CE marked by the RFC-3168 bitwise-OR rule.  We would then have A(ECT) and B(CE) transmitted onward, which seems to match the intent of the AQM - in particular, the number of CE marks is preserved, not doubled.
>>>
>>> What am I missing from the context of your objections?
>> Well, I don't know, 'cos I don't know how you came to that
>> interpretation (you'll need to point to the sentence that made you think
>> that, if it's still not clear).
> I'm also confused, so although I'm not speaking for Jonathan, I'll point to a sentence
> that made me think the response raised an excellent and relevant point:
> (From https://mailarchive.ietf.org/arch/msg/tsvwg/B2Gnb-jYPiZFYuA3YXNRhktKaT4/)
>
>    'the "logical OR" reassembly process required in RFC3168 roughly doubles both the number
>    and the proportion of CE marked packets and the number and proportion of CE-marked bytes
>    (relative to a parallel flow with slightly smaller packets that is not fragmented).'
>
> I thought the example succinctly suggested that one of the 4 things listed above can't be
> doubled, namely:
>
> - the number of CE-marked packets.
>
> If there's a way for the number of CE packets to be doubled by the "logical OR" reassembly
> process, I would like to see an example.  I haven't been able to think of one.
>
> To me also, this seems a fundamental point worth clarifying.
>
> (I do see that the other 3 metrics can be doubled under some specific assumptions about
> the fragments and probabilities, as likewise demonstrated by the simple example.)
>
> Best regards,
> Jake
>
>

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