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

[marcelo bagnulo braun <[e-mail]>]

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.

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.

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.

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).

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?

Regards, marcelo