Re: [iccrg] IETF104 ICCRG TCP Prague presentation

Bob Briscoe <in@bobbriscoe.net> Wed, 03 April 2019 17:40 UTC

Return-Path: <in@bobbriscoe.net>
X-Original-To: iccrg@ietfa.amsl.com
Delivered-To: iccrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5319D120150 for <iccrg@ietfa.amsl.com>; Wed, 3 Apr 2019 10:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 DH8JD99rvfVk for <iccrg@ietfa.amsl.com>; Wed, 3 Apr 2019 10:40:38 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 16945120143 for <iccrg@irtf.org>; Wed, 3 Apr 2019 10:40:37 -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:To:Subject:Sender:Reply-To:Cc: 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=SLYTYG+ADQGP5NcofMvANmjU0p30zbALcpDa97kqL64=; b=4BDnOhs5RaPmiCeq/WUG8N/Oi VLTVPQ8uT7nGk5GLDZuarK1beUHNssO8HW5iWRiXWU4M97/bAIK1zUm+fHtADMC6lSbVb8S59/nRy ma/P6etG4FYGp8ofZrYBbHPXNof498D65x3eWftxVGwlkXYlPHXTeQCdXkPoMjbhK/b0GjdxIg6Yl n8ZKsl7s2sSfMkRdXiMwFAI5mJKOM1EMfKGNjxXxRfCAlUP1VSfELpKQLLyNNnrWPbnUXtR2RScJL 3vyRllAAVhnn/1ZFA9L+t0I9eGACAw0Me9HzliJqCobjoVJiOl1lVbXDogJkCPYvInrWnGEtnhstF 2sq67CWzw==;
Received: from [31.185.128.56] (port=60372 helo=[192.168.0.9]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <in@bobbriscoe.net>) id 1hBjsJ-0007xY-OP; Wed, 03 Apr 2019 18:40:36 +0100
To: Sebastian Moeller <moeller0@gmx.de>, iccrg@irtf.org, tsvwg IETF list <tsvwg@ietf.org>
References: <623CA1C6-3425-46E6-AFD9-6FD7D0DBE422@gmx.de>
From: Bob Briscoe <in@bobbriscoe.net>
Message-ID: <a7bf3c8d-bb9e-e7e8-3343-ccdbac795591@bobbriscoe.net>
Date: Wed, 03 Apr 2019 18:40:34 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <623CA1C6-3425-46E6-AFD9-6FD7D0DBE422@gmx.de>
Content-Type: multipart/alternative; boundary="------------66743B462A2761BB69551C52"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - irtf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/iccrg/kmtrW7zuvr9xIuaQYXyATAH7t_8>
Subject: Re: [iccrg] IETF104 ICCRG TCP Prague presentation
X-BeenThere: iccrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussions of Internet Congestion Control Research Group \(ICCRG\)" <iccrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/iccrg>, <mailto:iccrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iccrg/>
List-Post: <mailto:iccrg@irtf.org>
List-Help: <mailto:iccrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/iccrg>, <mailto:iccrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2019 17:40:41 -0000

Sebastien, (adding tsvwg, given this is all part of the decision over 
L4S/SCE),

On 02/04/2019 12:38, Sebastian Moeller wrote:
> I finally got around to see the TCP Prague presentation, nice, especially the part around slide 11 "Fallback to Reno-friendly on Classic ECN" caught my interest.
>
> The claim made there is that L4S's inability to properly deduce the type of CE signal (normal ECN response expected versus DCTCP-like ECN response expected) would only matter in the case of ECN-marking single queue AQMs and not for flow-queueung AQMs, and I would like to argue that that should be measured rather than solved by declaration.
[BB] I don't know whether you just looked at my slides without the voice 
track. But the voice track makes it clear that is exactly what I've been 
setting up.

To save those who weren't in the room from having to sit through the 
audio, I said that there are two sets of contradictory measurements:

  * those from 'academic' active measurement studies that have found
    hardly any CE
  * those from Apple's passive measurements on Apple devices that have
    found significant localized amounts of CE.

My hypothesis is that the active measurements aren't seeing much CE, cos 
they don't generate enough traffic themselves to congestion the link and 
they would have to coincide with other traffic to see it passively.

I said, in short, I believe the active measurements are more likely 
wrong, and passive more likely right.

Nonetheless the CE that Apple measured could be consistent with classic 
ECN marking from FQ-CoDel, e.g. in OpenWRT devices, which would protect 
competing flows from L4S flows. Apple saw CE "mainly in the uplink", 
which is likely to be FQ-CoDel. And the smaller amount seen in the 
downlink could have been peer-to-peer flows that had been marked on 
entry to the uplink by an FQ-CoDel home router.

With the help of others, I've devised a test for FQ vs FIFO, but we need 
to find where the CE-marking routers are before we apply the test (a 
scatter-gun approach would be infeasible given the need to congest the 
link). In discussions with Apple folks, we think it's best to run tests 
at the CDN end, to identify the network prefixes where CE is appearing 
(the client end used in the original tests usually doesn't know its 
public IP address).

If we find any CE in the downlink from the CDN, that will disprove my 
peer-peer FQ hypothesis. But it won't prove that it's from a FIFO. The 
test for FQ vs FIFO is not straightforward, and I haven't yet worked out 
how we run it in the relevant direction over the paths where we find CE 
(not least 'cos that would involve collecting and identifying client IP 
addresses, which raises privacy concerns). I suspect we'll need to 
co-opt some volunteers in the affected localities, somehow.

An alternative to inline testing will be to find out whether the 
networks where CE is being seen have supplied their customers with 
routers with FQ-CoDel enabled. That won't prove conclusively that all 
the CE is coming from FQ-CoDel, but we can only go so far in trying to 
prove a negative.

>
>
> Consider the following case, that get's more and more common: traffic shaping for both ingress and egress somewhere on the end-customer side of an internet access link. For egress I agree with the rationale, that flow-queueing/fair-queueung should deal with flows that appear unresponsive sooner or later (but I note that this still will increase the memory required for the queueing and should not be considered ideal behavior).
> But for ingress shaping downstream of the "true" bottleneck (I am simplifying over some details here) this rationale falls apart, the unexpected packets the L4S sender kept sending since it misinterpreted the CE mark, will still hog valuable bandwidth of the internet access link, and hence fair queuing on the home end of the true bottleneck will not isolate that homenet from the L4S misunderstanding.
[BB] For the avoidance of doubt, I think you're using 'egress' to mean 
[home -> Internet] (I use it for the other direction, but I can work 
with your terminology).

In the [Internet -> home] direction, you are right that FQ on the home 
end would not isolate the access link from a misunderstanding of any CE 
marking. But I'm not suggesting it could or would. The question is about 
the machine at the Internet side of the access link (BRAS, CMTS, etc) 
that is queuing traffic into the access link towards the home. We can be 
nearly certain it is not doing FQ (these machines serve thousands of 
customers, so I don't believe any use FQ). The question is whether we 
can find one of these non-FQ machines that has an AQM enabled that does 
CE marking.

That's what we're trying to find. It's of course hard to prove a 
negative - that none exist. All we can hope to do is measure a sample of 
the paths we find.


A nit: DCTCP is not /unresponsive/. It responds to congestion, but as if 
it is equivalent to a number of 'classic' (Reno-friendly) TCP flows.

>
> I would be delighted to learn where my assumptions are wrong...
Regards



Bob

>
> Regards
> 	Sebastian Moeller
>
> _______________________________________________
> iccrg mailing list
> iccrg@irtf.org
> https://www.irtf.org/mailman/listinfo/iccrg

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