Subject: [LOOPS] Charter github issue #5: Non-congestive loss

From: Carsten Bormann <[email-masked]>
Date: Tue, 30 Jun 2020 09:20:22 +0200

In charter github issue #5 <https://github.com/loops-wg/charter/issues/5>,
larseggert writes:

»

The current charter says

> Based on configuration and measurement information, losses can possibly be categorized into congestion and non-congestion losses.

Some indication of how this is intended to be done would be worthwhile. Classification of loss into congestion or non-congestion loss has in general not been a tractable problem; why is this different here? (And is it, really? Saying "possibly" in the charter doesn't exactly inspire confidence.)

How central to LOOPS is this ability to correctly classify losses? It's mentioned in the third bullet, but seems like it would apply more broadly, e.g., to the first bullet as well?

«

A loss that can be correctly characterized as a non-congestion loss does not need to be communicated to the end hosts, so it does not slow them down.  If this performance boost can be achieved, it is a significant deployment incentive, so I think it is rather central to getting LOOPS deployed widely.

Not all intuitions from transport work may apply one-to-one to the way LOOPS will be used.  LOOPS is intended to be run by network operators who may have a more stable insight into what their networks actually do than a transport protocol that needs to work on a wide variety of networks that is essentially unpredictable for the end-hosts.  

So, as an example, if LOOPS runs on a path segment that is fully enabled for ECN marking (see issue #4), losses either are non-congestion losses or they are heavy losses that should provide some additional indicators (e.g., heavy CE-marking of the packets that do make it, erratic latency, etc.).

In practice, this binary assessment can also be extended to three cases:

— non-congestive losses
— non-persistent congestion
— persistent congestion

where persistent congestion could be defined as congestion that lasts long enough to benefit from end-to-end control loops.

I believe that detection of losses as non-congestion induced can often be done unilaterally once some basic measurements are in place, so it may be a great way for LOOPS implementers to differentiate their products — the standard may not have to provide anything but those measurements and maybe a basic mechanism to exercise them.

Obviously, recovering non-congestion losses is “unfair” against flows that do not benefit from LOOPS; we may need to define an appropriate concept of fairness for LOOPS.

Grüße, Carsten

---

From: Lars Eggert <[email-masked]>
Date: Tue, 30 Jun 2020 10:43:46 +0300

Hi,

> A loss that can be correctly characterized as a non-congestion loss does not need to be communicated to the end hosts, so it does not slow them down.  If this performance boost can be achieved, it…

sure. My question was if this is possible to do.

> Not all intuitions from transport work may apply one-to-one to the way LOOPS will be used.  LOOPS is intended to be run by network operators who may have a more stable insight into what their netwo…

You say "may have"? Do they, though? Is there any published academic work, or any RIPE/NANOG talks, or any other public information that operators actually have that insight?

I'll note that over in QUIC, many of these same operators are arguing that they need TCP-like cleartext bits added to the protocol so that they retain insight into what's happening in their network. If they get this information from transport headers, they by definition do NOT have more insight than the endpoints have.

> So, as an example, if LOOPS runs on a path segment that is fully enabled for ECN marking (see issue #4), losses either are non-congestion losses or they are heavy losses that should provide some ad…

I might buy this for a wired networks, but those also have exceedingly low non-congestion loss rates, so that's not really where the applicability for this lies, right? If the focus is on wireless, I'd like to see some validation of this claim for different radio technologies.

> where persistent congestion could be defined as congestion that lasts long enough to benefit from end-to-end control loops.

After the fact, you can differentiate between persistent and non-persistent congestion, because the latter lasted longer than the RTT. But in order for LOOPS to be effective, you need to be able to do this differentiation at the onset of congestion, because otherwise all you do is delay the endpoint's congestion response and cause it to contribute more congestion.

I'm again unaware of any published information that this kind of differentiation at the beginning of a congestion episode is actually doable.

> I believe that detection of losses as non-congestion induced can often be done unilaterally once some basic measurements are in place, so it may be a great way for LOOPS implementers to differentia…

I believe differently. But I don't want to charter a WG, so the onus is on the proponents to provide some data here.

> Obviously, recovering non-congestion losses is “unfair” against flows that do not benefit from LOOPS; we may need to define an appropriate concept of fairness for LOOPS.

It really sounds like some pretty basic research is still needed here before standards work can be successful.

Lars