Subject: Re: [ledbat] fairness between competing delay flows in draft-shalunov-ledbat-congestion-00.txt

From: Stanislav Shalunov <[email-masked]>
Date: Thu, 2 Apr 2009 23:29:52 -0700

We have not observed the late-comer's advantage.

As soon as the first flow has a hiccup (for example, because something
needs to wait for a few disk head moves), there will be a gap in the
first flow's traffic, enabling the second flow to measure accurately.

During the session Murari mentioned that in their experience, flows
were also always able to get a reasonable base delay measurement.

Obviously, the more flows, the more uniform the traffic, the more
likely it is that the late comers might be mistaken about the base.
At tens of flows, this is clearly not a problem.  At tens of
thousands, which is what most backbones see for bulk connections, I'd
expect it to start showing.  The coordination problem at tens of
thousands of connections is hard and almost certain to be emergent,
but then extended congestion on backbone links is infrequent.  In the
worst case, it'll all fall back to TCP.

For a small number of flows, the situation most typically encountered
on congested links, base estimation seems to be reliable.

On Tue, Mar 31, 2009 at 5:23 PM, Douglas Leith <[email-masked]> wrote:
> Can I ask what the expected/desired behaviour will be when two or more
> ledbat flows share a link ?
> For example, say a first flow starts, ramps us cwnd until it hits the target
> queueing delay and then a second ledbat flow starts a while later.  Its not
> clear to me from the ID how the first flow would alter its cwnd to make
> space for the second ledbat flow (especially if the second flow does not use
> slow start, or perhaps has an early exit from slow start).
> Also, is there a danger that, similarly the vegas and related algorithms,
> the later starting flow will have difficulty getting an accurate estimate of
> the base RTT since earlier starting flows maintain a standing queue ?
> Doug
> www.hamilton.ie

-- 
Stanislav Shalunov
BitTorrent Inc
[email-masked]

personal: http://shlang.com

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 09 Apr 2009 13:50:29 +0100

Stas,

Point taken about base measurements, but this questions is about the 
motivation for the core part of the control algo:
         cwnd += GAIN * off_target / cwnd. (using the draft's 
terminology: off_target = TARGET - queuing_delay)
Q. Why should the controller's increase and decrease both depend on 
the same formula?

I think this means the shares that competing flows get depend purely 
on the minutiae of the dynamics of each competing flow. That means 
shares depend on arbitrary stuff that sharing shouldn't depend on 
(e.g. whether disk heads move, how many other interrupts are served, 
who arrived first), and there's nothing explicit to control what the 
shares do depend on. However, I assume I must have missed something, 
as I'm sure you've thought of this.

As far as I can work out (haven't had time to work through the 
non-linear case where the small standing queue might disappear 
completely), shares don't explicitly depend on RTT or packet size or 
delayed ack factor (which IMHO they shouldn't). While both the 
acceleration and deceleration of each flow do depend on these factors 
in equal measures (which IMHO they should too). So far so good, but...

...taking RTT as one example, altho the steady state shares won't 
depend directly on RTT, they might depend on second order effects of 
how differences in RTT interact with other random events. If correct, 
that's not good. It's random.

Put another way, repeating the question in my earlier posting:
Q. Why should the controller aim to *increase* delay up to the target?

Instead the window *increase* could operate as a separate continuous 
process (as in AIMD algos). And the threshold only indicates a 
*decrease* is needed if exceeded. Then bottleneck sharing is 
explicitly under control. It is the equilibrium when the two 
decoupled increase & decrease processes balance. 'TARGET' then 
becomes merely a lower threshold for the decrease process, not a 
target for both processes.

Bob

At 07:29 03/04/2009, Stanislav Shalunov wrote:
>_______________________________________________
>ledbat mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ledbat

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research