[R-C] RRTCC issues: loss, decrease rate

[Mo Zanaty (mzanaty)]

Randell Jesup <randell-ietf at jesup.org> wrote:
> You *might* be able to infer the number of competing streams (or some 
measure of competition) by the slope change after a reduction. In the 
single-flow case, it may be a fairly strong signal that it's 
single-flow, and you might want to include memory of that for a period 
and adjust the reaction rate to be faster.

I agree it is desirable to infer the amount of competing traffic, via observing trends in delay (and loss/ECN) across rate changes, including the specific signal above.

> One reason single-flows are so interesting is that access-link 
congestion is a very common case and very important case for connection 
quality for the user, if not the worrying case (from congestion-collapse 
or fairness perspectives).

I would agree in prior years, as most video devices/applications have addressed this "home alone" case (in proprietary, non-interoperable ways) and benefited from it. Dedicated video devices were common, and it was often easy to know if there was any competing traffic and stop it. But going forward, for newer multi-function devices/apps under design, I'm less confident that addressing the "home alone" case will be very beneficial. Multi-function often immediately breaks the solo flow assumption. Like webrtc games with player video, collaboration software with meeting video, chat with AR layers, etc. Even if you can coordinate all the flows via some type of congestion manager within the device/app, you are rarely the only active device/app on any network, even when seemingly "home alone". Devices that look dormant may be sleepwalking (cloud sync, or other content or software updates), so identifying and stopping competing traffic becomes impractical (not as easy as yelling "everyone off Netflix!").

I think the "home alone / solo flow" case is the right starting point to make progress on the simplest scenario. It should be the first case in the evaluation criteria draft, not because it is the most common scenario, but because it will be simplest to analyze and identify basic design flaws. Anything that fails the first simple test can't possibly survive further. But I would not consider this effort a success if that's as far as we get, or if that's the focus or sweet spot of the final solution.

Mo