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

[Magnus Westerlund <[e-mail]>]

Hi,

Yes, so I think ECN is definitely something that can wait for future
improvements. I was simply trying to be as clear as possible that from an
endpoint you don't have that many basic indicators of congestions. 

So I am primarily concerned that this one has the right description for what we
expect it to do. From my perspective I have no issue with this being published
with a clear limited applicability and clear indication of what it is expected
to do. For the intention I am fine with you authors reword it to something
similar that is more consistent with the existing text. I just want it to be
clear that due to the nature of the intent to measure capacity it may push
existing elastic traffic out of the way in the probing to determine maximum
capacity. 

Cheers

Magnus

On Wed, 2021-03-31 at 09:30 +0000, [e-mail] wrote:
> Hi Magnus,
> 
> Thanks for clarifying. 
> 
> The scheduling behaviour of wireless shared media is an issue and first
> results I saw indicated an increased RTT and a rather high access capacity.
> Store until there's sufficient load to use a "bearer" and then send at line
> rate. I think that's one of the reasons why a measurement "preamble" is part
> of the method. As far as I can tell, the above behaviour turned (often at
> least) into a more stable forwarding, as long as measurement traffic arrived
> regularly afterwards.
> 
> We can't get around inducing congestion to recon that we are "over the top".
> I'd be happy to work with ECN marks too, but ECN isn't widespread at devices
> scheduling customer and server traffic with operator connectivity. The
> overshooting carefully is a requirement, and that's a reason why the algorithm
> measures queue-build up by increasing delay and classifies it as a congestion
> indication (as I think do some or all of the latest transport protocols too,
> without comparing the detailed algos). Fairness against competing transport
> hasn't been tested. In my eyes, such a test needs to compare commodity speed
> test vs. competing transport and then IP-capacity metric traffic vs. competing
> transport. Both, commodity speed-test and IP-capacity metric traffic decrease
> the bandwidth of competing transport. One of both might have a significantly
> stronger impact. I don't judge here, as I'm not aware of tests, but I also
> don't think it's ok to state commodity speed tests are fair, as they are TCP
> based. Their design goal is to reliably congest the receiver access until
> drops occur.
> 
> Udpst is open source. In general, and not addressing you personally, I'd
> appreciate all improvements to reduce total test load and test duration, and
> dealing with background traffic or (more generic) dealing with feedback
> indicating varying IP-capacity during a single test session at the receiver.
> If the result is "available capacity" because of such a time-varying receiver
> IP capacity, then that's the result and the test stops. I agree, that a test
> should not try to determine IP access capacity "by all means" (and I think
> neither does the text provided, nor does the implementation). 
> 
> Regards,
> 
> Rüdiger
>  
> 
> -----Ursprüngliche Nachricht-----
> Von: Magnus Westerlund <[e-mail]> 
> Gesendet: Mittwoch, 31. März 2021 09:43
> An: Geib, Rüdiger <[e-mail]>
> Cc: [e-mail]
> Betreff: Re: AW: I-D Action: draft-ietf-ippm-capacity-metric-method-08.txt
> 
> 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