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

Bob Briscoe <ietf@bobbriscoe.net> Mon, 22 March 2021 16:53 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 3B7C33A0D02 for <tsvwg@ietfa.amsl.com>; Mon, 22 Mar 2021 09:53:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.773
X-Spam-Level:
X-Spam-Status: No, score=0.773 tagged_above=-999 required=5 tests=[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.972, 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 3LimNYFQtWH3 for <tsvwg@ietfa.amsl.com>; Mon, 22 Mar 2021 09:53:16 -0700 (PDT)
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 3E7AB3A0CFC for <tsvwg@ietf.org>; Mon, 22 Mar 2021 09:53:16 -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=pYhEOrZUOd78A2iPaZKMz4RuEQ2oXs3nku7kBXlS9ik=; b=B8KScMbKl/O8OffqWcB0fDpZ9I RBdeX3qxTTNtWDJex8Jd+V4lkQh2X4p22+4gMU5WXwH6Olda5kqMKRfEPrrX6m4wDVfO83R/cfh9g olNvrdSIo0yTVisJtdD7RuTteB5xKNcf1gP8SKEbvLVyXmqmrtkK74UhkM7wQ3zWtg5YyKlitzoU+ +Wvk2MWGXoVtAMaI8r5B8G7G95TMN56Zw8MyOcgi7nr4LvENyVOIOnc7E2hgqWKlZuvV+TBLlJzlN UkWrqniJYFH8E+kIOwmISpiGrJXquvbNluwbFWnvFuaiqt+ELS/WFWGHKAlp1wOkxwlvo1WGp23pp Hu+cyUvQ==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:46734 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 1lONnm-0005vG-FC; Mon, 22 Mar 2021 16:53:14 +0000
To: Pete Heist <pete@heistp.net>
Cc: tsvwg IETF list <tsvwg@ietf.org>, maprg@ietf.org
References: <161519742798.12373.8424747645620734074@ietfa.amsl.com> <4cc306ea278dab68741b0c27713bfb7c84522e11.camel@heistp.net> <72467bfe9a38edee74c4ab8e12ec350e23315ec9.camel@heistp.net> <ce2c8397-1bb9-8634-7822-88b9ba6d3b22@bobbriscoe.net> <0f8a406dc56a24d90a76a337074f62a07b4d4aec.camel@heistp.net>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <ab5add35-529e-6d12-5768-693123004338@bobbriscoe.net>
Date: Mon, 22 Mar 2021 16:53:12 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <0f8a406dc56a24d90a76a337074f62a07b4d4aec.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/DJXv2FkOBpRMnnKD7tI8M-j1oL0>
Subject: Re: [tsvwg] Fwd: New Version Notification for draft-heist-tsvwg-ecn-deployment-observations-02.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: Mon, 22 Mar 2021 16:53:20 -0000

Pete,

On 09/03/2021 01:13, Pete Heist wrote:
> Hi Bob, comment below...
>
> On Tue, 2021-03-09 at 00:25 +0000, Bob Briscoe wrote:
>> Pete,
>>
>> Thanks for the updated draft a fortnight ago, with the extra columns
>> I
>> asked for.
>>
>> I've been excluding the rows with obvious pathologies.
>>
>> Of the 90 IPs in your TCP results, 74 have at least one obvious
>> pathology, leaving only 16 clean.
>> And actually, there was a pathology suggested in your slides today
>> that
>> isn't in the above,
>>       If I check for that too, 83 IPs have at least one pathology,
>> leaving only 7 clean.
>>
>> Any idea what is going on?
>>
>>
>>
>> ==Details==
>>
>> In the TCP results, unlike with QUIC, the reverse feedback is
>> visible.
>> So I can check for more pathologies.
>>
>> I checked for this obvious pathology, that wasn't directly mentioned
>> in
>> the slides today:
>> * Congestion experienced (CE) in one direction but no echo
>> congestion experienced (ECE) feedback in the other.
>> * Or conversely, echo congestion experienced (ECE) feedback in one
>> direction but no congestion experienced (CE) in the other.
> I believe I've got your question right, but let's see. From the vantage
> point of the gateway, we don't always get to see CE in one direction
> and ECE in the other. In fact, it seems a lot of the time we don't.
>
> Say downstream traffic passes through the gateway as ECT(0) and gets
> marked in an AQM later with CE, before arriving at the user endpoint.
> We haven't seen that CE at the gateway, but we still see the ECEs in
> the opposite direction. The same can happen upstream, if CE is marked
> somewhere after packets leave the gateway. That's why we don't require
> the presence of CE marks to mark an entry "possible AQM", but we use
> them if they're present.

[BB] OK that's a feasible explanation... but the numbers still seem weird...

Can you provide more insight into the topology of this ISP. You say it 
is a co-operative wireless ISP. Are all the access links symmetric?

I'm asking because, in the direction from the LAN, it seems highly 
unlikely that 38 of the 90 IPs experienced no ECN marking in the 
upstream access link or the backhaul, but they did experience ECN 
marking somewhere further into the network (which could include another 
access link for p2p traffic).

The results for the 38 IPs backhauled via the FQ-CoDel nodes (known to 
support ECN) are even more unexpected (again taking only the TCP 
results, because they show both directions):
* In the direction from the LAN, 10 of these 38 IPs saw no ECN marking 
from the LAN side (including none from those FQ-CoDel nodes), but they 
did see the feedback of ECN marking from somewhere deeper into the network.
* The results in the direction from the WAN are more what I would 
expect: 30 of the 38 IPs saw no ECN marking from the WAN side, but they 
did see the feedback of ECN marking that must have occurred on the LAN 
side (where the FQ-CoDel nodes are).


Bob

>
> Pete
>
>> Of the 90 IPs in the TCP results, 40 from the WAN have this pathology
>> and 38 from the LAN
>> (taking the direction as that of the data)
>> Only 16 IPs, don't have this pathology in either direction.
>>
>> I would have thought you guys would have picked up these when
>> checking
>> for the ECE/CE >= 2
>> (and/or zeros).
>>
>> If I include the pathology you mention where ECE/CE < 2
>> In all, of the 90 IPs in the TCP results, after I exclude any IP with
>> a
>> pathology, I only have 7 IPs left.
>>
>>
>>
>> Bob
>>
>> PS. I agree it's v strange for an ISP to share capacity between its
>> members by how many flows they are using.
>>
>> On 08/03/2021 22:19, Pete Heist wrote:
>>> I'm following up in this thread to one question that's come up- why
>>> is
>>> an ISP deploying fq_codel in its backhaul?
>>>
>>> In short, this ISP encourages research and experiments by its
>>> members,
>>> and this was a way to both see how much congestion exists, and
>>> attempt
>>> to manage it with AQM when needed. Experiments with fq_codel were
>>> started a couple of years ago, and I helped add support for it to
>>> their
>>> custom router interface early last year. However, it's only
>>> actually
>>> been enabled on a couple of routers, because:
>>> - it takes a while to update routers in this environment
>>> - some of the routers run kernels prior to fq_codel support
>>> - congestion doesn't usually last long enough to give it much
>>> urgency,
>>> and sometimes it's fixed by just adding capacity
>>>
>>> IMO, fq_codel isn't ideal in this situation. When there actually is
>>> congestion to manage, flow-fairness means that one user can
>>> dominate
>>> the queue with many flows, which is exactly one of the problems
>>> we'd
>>> like to avoid. Host fairness could improve on this, or better yet,
>>> member fairness using the member database, as members can have more
>>> than one IP/MAC. But, fq_codel is what's available now, and
>>> generally
>>> usable enough in this case to get started with AQM.
>>>
>>> On Mon, 2021-03-08 at 11:09 +0100, Pete Heist wrote:
>>>> -------- Forwarded Message --------
>>>> Subject: New Version Notification for draft-heist-tsvwg-ecn-
>>>> deployment-
>>>> observations-02.txt
>>>> Date: Mon, 08 Mar 2021 01:57:07 -0800
>>>>
>>>>> A new version of I-D, draft-heist-tsvwg-ecn-deployment-
>>>>> observations-
>>>>> 02.txt
>>>>> has been successfully submitted by Peter G. Heist and posted to
>>>>> the
>>>>> IETF repository.
>>>>>
>>>>> Name:           draft-heist-tsvwg-ecn-deployment-observations
>>>>> Revision:       02
>>>>> Title:          Explicit Congestion Notification (ECN)
>>>>> Deployment
>>>>> Observations
>>>>> Document date:  2021-03-08
>>>>> Group:          Individual Submission
>>>>> Pages:          30
>>>>> URL:
>>>>> https://www.ietf.org/archive/id/draft-heist-tsvwg-ecn-deployment-observations-02.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-02.html
>>>>> Htmlized:
>>>>> https://tools.ietf.org/html/draft-heist-tsvwg-ecn-deployment-observations-02
>>>>> Diff:
>>>>> https://www.ietf.org/rfcdiff?url2=draft-heist-tsvwg-ecn-deployment-observations-02
>>>>>
>>>>> 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.
>>>> A few updates in this version:
>>>>
>>>> * Improved statistics for the separated "known" and "unknown"
>>>> AQMs.
>>>>
>>>> * Clarified the detection method for possible AQMs.
>>>>
>>>> * Added possibility of QUIC-ECN traffic in non-TCP data.
>>>>
>>>> Pete
>>>>
>>>>
>

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