Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05

Hi Gorry,

Based on the discussions in the mailing list, we should have removed allusions to being able to detect non-congestion losses from the draft. This github issue was closed about same time as the draft uploading. Hence the draft did not absorb all the conclusions. Sorry about that.

Current scope focuses on drop-to-mark approach without trying to detect non-congestion loss.

Will update the draft by this week to reflect the most recent consensus (together with those mentioned in your previous email). 

Rgds,
Yizhou

-----Original Message-----
From: LOOPS [mailto:loops-bounces@ietf.org] On Behalf Of Gorry Fairhurst
Sent: Thursday, July 9, 2020 5:58 PM
To: loops <loops@ietf.org>
Subject: Re: [LOOPS] draft-li-tsvwg-loops-problem-opportunities-05 - How do endpoints understand congestion?

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

-- 
LOOPS mailing list
LOOPS@ietf.org
https://www.ietf.org/mailman/listinfo/loops