Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - How do endpoints understand congestion?

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Thu, 09 July 2020 09:57 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: loops@ietfa.amsl.com
Delivered-To: loops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149AF3A011B for <loops@ietfa.amsl.com>; Thu, 9 Jul 2020 02:57:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 e8YsvM8ITZLP for <loops@ietfa.amsl.com>; Thu, 9 Jul 2020 02:57:55 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6F44E3A00E4 for <loops@ietf.org>; Thu, 9 Jul 2020 02:57:54 -0700 (PDT)
Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 38EF61B000A3 for <loops@ietf.org>; Thu, 9 Jul 2020 10:57:53 +0100 (BST)
To: loops <loops@ietf.org>
References: <dd240ea2-f1b7-28eb-00ad-bb037c764d4d@erg.abdn.ac.uk> <C5795E6B-14AE-47ED-ADB1-DBEEE37A024A@tzi.org> <e57dbf09-d1d0-e899-f12d-59db29a11f21@erg.abdn.ac.uk> <19d1f8379e464b70a00c025371a15e31@huawei.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <22cf10dc-c85d-255b-8131-6f336b639029@erg.abdn.ac.uk>
Date: Thu, 09 Jul 2020 10:57:52 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <19d1f8379e464b70a00c025371a15e31@huawei.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/loops/V412khwrQvfgjgxjnBmBqQ7eryw>
Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - How do endpoints understand congestion?
X-BeenThere: loops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Local Optimizations on Path Segments <loops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/loops>, <mailto:loops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/loops/>
List-Post: <mailto:loops@ietf.org>
List-Help: <mailto:loops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/loops>, <mailto:loops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2020 09:57:57 -0000

Hi,

I have questions about congetsion control will be performed. The problem 
statement says:


“LOOPS (Local Optimizations on Path Segments) is a network-assisted
    performance enhancement over path segment and it aims to provide
    local in-network recovery to achieve better data delivery by making
    packet loss recovery faster and by avoiding the senders over-reducing
    their sending rate.  “

[gf] ... which seems interesting.

Section 3.3 outlines precisely the problem that
“In long-haul links, when the loss is caused by non-persistent burst
    which is extremely short and pretty random, the sender's reaction of
    reducing sending rate is not able to respond in time to the
    instantaneous path situation or to mitigate such bursts.  On the
    contrary, reducing window size at the sender unnecessarily or too
    aggressively harms the throughput for application's long lasting
    traffic like bulk data transfer.”

[gf] ... Which sounds like it asks questions where I did not find an 
answer: How does the network segment differentiate between different 
pathologies that result in loss? I can imagine some random physical 
layer loss that isn't congestion. I can imagine some random loss that is 
a result of corruption in a shared media... which may or may not be 
link-layer congestion? How does the network segment know?

So, one reason for asking is I saw these two statements, on informing 
the end-to-end transport protocol about congestion loss events that 
distinguish losses:

"Existing tools such as ECN will be used."

“ A more recent draft,
    [I-D.ietf-tsvwg-tunnel-congestion-feedback], proposes to activate ECN
    for the tunnel regardless of whether the end-to-end protocol signals
    the use of an ECN-capable transport (ECT), which requires more
    complicated action at the tunnel egress.”

[gf] How does this help, please explain?

... The draft mentioned hasn't been changed since Jan 2017, and has not 
yet captured much experience or comment, so I am quite uneasy about 
predicting what will finally happen with thart draft. That aside, I'd 
like to understand how ECN helps in this case, since the 
congestion-control reaction seems a key part of any LOOPS method.

Best wishes,

Gorry