Re: [iccrg] comments about draft-balasubramanian-iccrg-ledbatplusplus-00

[Praveen Balasubramanian <[e-mail]>]

Thanks for the feedback Marcelo. Inline prefixed by [praveen]. Submitted draft version 01 to address this feedback. I'll try to submit 02 with pseudo code soon. 

-----Original Message-----
From: marcelo bagnulo braun <[e-mail]> 
Sent: Tuesday, September 3, 2019 3:01 AM
To: Praveen Balasubramanian <[e-mail]>; iccrg IRTF list <[e-mail]>
Subject: comments about draft-balasubramanian-iccrg-ledbatplusplus-00

Hi Praveen,

Thanks for writing this up. I have some comments about the document, please find them below.

On section 3.1 I am uncertain if, as currently phrased, this is a problem that LEDBAT has or that LEDBAT has made a design choice to solve a different problem. This is related to the answer that I wrote to Neal's comment in the other email. I will repeat myself a bit.

RFC6817 described the goals the goals of LEDBAT as:

" LEDBAT congestion control seeks to achieve the following goals:

    1.  to utilize end-to-end available bandwidth and to maintain low
        queueing delay when no other traffic is present,

    2.  to add limited queuing delay to that induced by concurrent flows,
        and

    3.  to yield quickly to standard TCP flows that share the same
        bottleneck link."

When there is other traffic in the bottleneck, the goal is defined in terms of the added delay, not in term of the absolute delay.

The text in this section, describes the problem in terms of the difficulty of LEDBAT to actually measure the "real" minimum/base delay. 
I would argue that this is not what LEDBAT has been designed for and we should probably stay away from that. I would suggest removing section
3.1 altogether while keeping sections 3.2 and 3.3, that deal with the effects of the wrong estimation of the base delay limited to the errors caused by the LEDBAT traffic itself. If this is done, probably there should be some rewording in section 3.2 and 3.3 to accommodate the change. I am happy to suggest text, if needed.

[praveen] Correct, LEDBAT aims to keep the queuing delays added by itself below the target. So while measuring base delay is useful, its not critical. For a sufficient number of LEDBAT++ flows the initial and periodic slowdown mechanism works well in practice. I do however think that measurement comparison with a BBR like slowdown mechanism is important in future.

About section 3.4.

I am uncertain I understand the problem this section is describing.

The way i see this, the problem is when there is a mismatch between the size of the buffer of the bottleneck and the amount of packets that result in the LEDBAT target.

If the amount of packets that result in the LEDBAT target is larger than the size of the buffer, then LEDBAT never reacts to queuing delay signal and only reacts to losses. If LEDBAT uses the same parameters than TCP New Reno, it will be competing equally with it defeating LEDBAT purpose.

The problem that i have in the way the section is currently written is that it focusses on the bandwidth of the network, and leaves out the size of the buffer its relation with the target T. In particular, it fails to explain why the target will never be reached (it doesnt mentions that the network starts dropping packets before it reaches the target, which would be important for me to understand this). I mean, i agree with the problem (and the proposed solution) just that I would phrase it differently.


[praveen] You are correct. There is incorrect focus on bandwidth. I fixed the text to refer to bottleneck buffer size while also mentioning that at high speeds the problem becomes worse.

About section 4.1

I would suggest to eliminate the F parameter and just keep Gain. This is more consistent with the original LEDBAT spec and also with section 4.2 that refers to Gain and not to F.

[praveen] Agree this makes the reading easier. Switched to just using dynamic GAIN instead of F.

About section 4.2.

First, the algorithm in section 4.1 is expressed as reaction to packet loss and acknowledgement while section 4.2 is expressed as reaction per RTT. I think it would be better if both sections are described in the same terms either per RTT or per packet. (or both if you prefer).

[praveen]  Rewrote these sections to make things more clear. I will add pseudo code to make things more clear in another version soon. 

Second, the draft currently states:

"This suffices if all competing connections have measured the same base delay.  However, this change by itself does not suffice if the connections have different estimates of the base delay.  In such conditions, picking the constant value of 1 and capping the multiplicative decrease coefficient to be at least 0.5 is required."

But this is exactly the latecomer problem we are trying to solve, isnt it?

So, my suggestion is actually include a description of the final algorithm being proposed here.

I also unclear what do you mean by the constant value and the multiplicative decrease coefficient, as the formula in the draft has two parameters, Gain and Constant, which i dont think are the ones you are referring to?

[praveen] Agreed this was poorly worded. The Constant value is set to 1. And the total decrease is capped to at most 0.5 of the cwnd to ensure reaction to delay signal is akin to loss-based congestion signal (where cwnd is halved). Fixed this text.

Regards, marcelo