Re: [ippm] I-D Action: draft-ietf-ippm-capacity-metric-method-08.txt

[Magnus Westerlund <[e-mail]>]

Hi Ruediger,

On Tue, 2021-03-30 at 10:48 +0000, [e-mail] wrote:
> Hi Magnus,
> 
> [MW] To accurately measure the capacity of the path the load algorithm strive
> to load the path so that the one way latency increases to indicate that the
> bottleneck buffer is sufficiently filled to achieve high utility. This load is
> not intended to be fair against other applications, it is intended to provide
> as accurate measurement as possible, potentially pushing other applications
> out of the way.
> 
> [RG] The sender rate adaption mechanism operates by congestion feedback, as do
> many standard transport protocols. The purpose of the algorithm is not to
> determine, whether a queue or a policer burst size "is sufficiently filled to
> achieve high utility", the purpose is to accurately determine the access speed
> which can be reached without queue-build up and/or packet loss. After feedback
> indicating a sender rate which has caused congestion has been received, the
> sender rate is adapted until the maximum access speed not causing congestion
> is determined. To decide on a sender rate fulfilling this this criterium, a
> sender rate causing a congestion which can be accurately identified as
> congestion by a measurement system is required. If you are aware of a method
> reaching this goal without causing limited congestion, please share.

Okay, I might be slightly conflating two things. So the indication that the path
bottleneck is filled to capacity is the fact that there are some queue buildup.
Loss and queue build up are the two signals that the algorithm has defined to
indicate load and congestion, as it isn't defining a ECN response. However, I
would argue on a number of link technologhies you will not find maximum capacity
unless you attempt to transmit enough data and actually build up some queue in
the relevant buffer. That is definitely true for a number of radio technologies.
The underlying reason can be both efficiency in inter user scheduling as well as
deal with short term radio fading effects. So capacity and high utility are
necessarly linked to me.


> 
> [RG] I don't understand whether your feedback is focused on improvements of
> parametrization or on the basic behaviour of the algorithm. The algorithm is
> not designed to be unfair.

I am not after improvements of the algorithms I after accruate representation of
the algorithm and intended usage. From my perspective this algorithm does not
need to be either self-fair or fair against any other congestion control
algorithms. And I am fine with that as long as it is clear on the box what it
does. Have anyone run any tests of how this beahves when competing with other
congestion controls, like CUBIC, BBR(1/2), LEDBAT etc? I am not asking for it
but it if it has been run it would be enlightening.

Cheers

Magnus