Re: [tsvwg] Fwd: New Version Notification for draft-heist-tsvwg-ecn-deployment-observations-00.txt

Bob Briscoe <ietf@bobbriscoe.net> Sat, 20 February 2021 09:36 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 EC4A93A0E0E for <tsvwg@ietfa.amsl.com>; Sat, 20 Feb 2021 01:36:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.434
X-Spam-Level:
X-Spam-Status: No, score=-1.434 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, NICE_REPLY_A=-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 4LxT9gRHewYR for <tsvwg@ietfa.amsl.com>; Sat, 20 Feb 2021 01:36:15 -0800 (PST)
Received: from mail-ssdrsserver2.hosting.co.uk (mail-ssdrsserver2.hosting.co.uk [185.185.84.51]) (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 1DC3C3A0E0B for <tsvwg@ietf.org>; Sat, 20 Feb 2021 01:36:14 -0800 (PST)
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=IEpV/aedRb/Ywth7cftFSycDZlRixLHo2+0AQytdQ9Y=; b=ph3msk2Emq4HEgolWGRVidYV64 t2tUFdVE8LDXJ3VtT26QHWv5DcetsLmzqIpgobGijhABPQLaGlo7Mby/+BkhNnqZU5h9jlnC2GAHM bUJ1z6y35e4c2V8iJd0kEV+77DM7OKw13jw7he3UYnaeQgCnHtRPesSrnuZn9gNbZzqBVp4Mj3hs5 /HK9/E378IbZtXftlAjiUqGWk08bWO+w48b0ybIKSf1bsToPKmqr79e9AO+aC1RRKSNFIA+/ZFjNi /MXHyiIvCyrHrXV7LxaIEH0wQQuziDDDg+1BJNxeNg+vEjpiny7EpqlHKJR1jCKMMkne+twnieu0z e2qXAtgg==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:41358 helo=[192.168.1.11]) by ssdrsserver2.hosting.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <ietf@bobbriscoe.net>) id 1lDOgN-0008Am-UU; Sat, 20 Feb 2021 09:36:12 +0000
To: Pete Heist <pete@heistp.net>
Cc: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, TSVWG <tsvwg@ietf.org>
References: <161366419040.16138.17111583810851995947@ietfa.amsl.com> <BF0810D9-E742-4FCB-90B1-6957551B585D@heistp.net> <29EBB69A-2A00-4A1D-A7D0-09469602CD8E@ericsson.com> <414509c71436aac01e894689a4dce7f0251ec0ef.camel@heistp.net>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <6e23258a-877f-2f2b-df6d-a18d20d61ec2@bobbriscoe.net>
Date: Sat, 20 Feb 2021 09:36:11 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <414509c71436aac01e894689a4dce7f0251ec0ef.camel@heistp.net>
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 - ssdrsserver2.hosting.co.uk
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: ssdrsserver2.hosting.co.uk: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hosting.co.uk: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/JYdnGQzfnt34EbK4gG4MlSmlBQU>
Subject: Re: [tsvwg] Fwd: New Version Notification for draft-heist-tsvwg-ecn-deployment-observations-00.txt
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: Sat, 20 Feb 2021 09:36:17 -0000

Pete,

If you plan to post a revision, in the TCP table (Sec.5.3) would you pls 
consider including the counts of ECT packets, as in the non-TCP table in 
Sec.5.3? Otherwise we don't know what percentage of the total ECN 
traffic each count represent.

I'm trying to separate out the IPs known to be behind the FQ-CoDel nodes 
in the backhaul. I.e. separating known from unknown causes.

Separately, a count of total packets, or equivalently a count of 
not-ECT, would be v useful too.

If you can do this without losing the ECE counts, even better. Having CE 
and ECE together enables a rough estimate of the average window.{Note 1}

Specifically,
     avgWindow = ECE * delAckRatio / CE

Thank you (again)


Bob

{Note 1} And lots of other assumptions, such as:
- delayed Ack Ratio including stretch ACKs has to be guessed (e.g. 2???)
- minimal additional ack coalescing in the network
- minimal reordering
- traffic volume dominated by elephants
- the TCP protocol is working as it should
- and so on.


On 19/02/2021 13:06, Pete Heist wrote:
> Yes, that was somewhat unexpected to us at first too, but misuse of the
> ECN field esp. on non-TCP packets seems to explain it in cases where
> there ratios don't look like AQM signaling. The data for TCP is overall
> easier to attribute to ECN when you can see feedback via ECE.
>
> I didn't editorialize much on the results, but I'll use this as a
> chance to add what struck me:
>
> * While ECN negotiations were relatively small at around 1.44%, they
> were spread across 45% of the IPs, so the proportion of paths using it
> seems significant.
>
> * The data seem to show significant 3168 marking AQM deployment, when
> 24% of LAN IPs that negotiated ECN saw CE or ECE. The draft mentions
> how some of it is from known AQM instances and some not. Congestion
> overall doesn't seem excessive, but that could be quantified better.
>
> * A wider survey might help on the non-TCP data.
>
> Anyway thanks for taking a look...
>
> Pete
>
> On Fri, 2021-02-19 at 11:44 +0000, Mirja Kuehlewind wrote:
>> Hi Pete,
>>
>> thanks for putting this together and sharing!
>>
>> I have one question on the data. Maybe I'm not readying this
>> correctly but if I look at the big table at the end, then I see a lot
>> of cases where there are much more CE marks than ECT(0) marks. That's
>> a bit unexpected as usually an AQM should only mark a small portion
>> of the packets. Or do I interpret the data there incorrectly?
>>
>> Mirja
>>
>>
>>
>> On 18.02.21, 17:38, "tsvwg on behalf of Pete Heist"
>> <tsvwg-bounces@ietf.org on behalf of pete@heistp.net> wrote:
>>
>>
>>      > A new version of I-D, draft-heist-tsvwg-ecn-deployment-
>> observations-00.txt
>>      > has been successfully submitted by Peter G. Heist and posted to
>> the
>>      > IETF repository.
>>      >
>>      > Name:             draft-heist-tsvwg-ecn-deployment-observations
>>      > Revision: 00
>>      > Title:            Explicit Congestion Notification (ECN)
>> Deployment Observations
>>      > Document date:    2021-02-18
>>      > Group:            Individual Submission
>>      > Pages:            27
>>      > URL:
>> https://www.ietf.org/archive/id/draft-heist-tsvwg-ecn-deployment-observations-00.txt
>>      > Status:
>> https://datatracker.ietf.org/doc/draft-heist-tsvwg-ecn-deployment-observations/
>>      > Html:
>> https://www.ietf.org/archive/id/draft-heist-tsvwg-ecn-deployment-observations-00.html
>>      > Htmlized:
>> https://tools.ietf.org/html/draft-heist-tsvwg-ecn-deployment-observations-00
>>      >
>>      > Abstract:
>>      >   This note presents data gathered at an Internet Service
>> Provider's
>>      >   gateway on the observed deployment and usage of ECN.
>> Relevant IP
>>      >   counter and flow tracking data was collected and analyzed for
>> TCP and
>>      >   other protocols.
>>
>>      This draft adds some data on the current usage of ECN. It was
>> gathered over several weeks at a cooperative ISP with around 660
>> members, and looks at ECN endpoint activity, AQM deployment and ECN
>> usage on non-TCP protocols. While this study is still relatively
>> small, it’s hopefully at least a little more useful than the
>> stateless counter data I posted late last year, which should set the
>> bar suitably low… :)
>>
>>      Pete
>>
>>
>

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