[R-C] LEDBAT - introductions?

[Michael Tuexen]

On Apr 6, 2012, at 7:52 PM, Matt Mathis wrote:

> And I think you are missing my big point: delays sensing does not work
> for general purpose congestion control, due to known stability and
> fairness problems.  Unless the scope of the RTCweb problem is somewhat
> narrowed, it is guaranteed to fail, because the larger problem is
> already known to be intractable.
> 
> The 50k meter view:
> Applications that are expecting to use RTC web need a bound on the
> queuing delay.
> 
> We (the WG) have to assume some sort of bound on other traffic (delay
> or loss sensing) that might be sharing the same bottleneck queue.
> 
> If we don't assume some bound on other traffic, it is self evident
> that RTCweb can not possibly guarantee the bound on the delay.
> Period.  There is nothing complicated or subtle here.
> 
> And the user will know very clearly when the network fails to meet it.
> 
> It would help move the Internet forward for the RTCweb WG to point out
> to the rest of the community that QoS like technologies can solve the
> queue sharing problems.    However, specifying any of these details
> are clearly out of scope for RTCweb.
> 
> My earlier long message was an attempt at explicitly narrowing the
> scope to make the problem tractable.
Hi Matt,

let us consider an RTCWeb connection. It is clear that other traffic has
an influence on the RTCWeb connection and that it is hard to deal with it.
But the RTCWeb connection possibly consists on several media flows and
one non-media flow (maybe multiple). How the RTCWeb connection shares its
bandwidth between the media and non-media flows is something that might
be tractable.
To be more concrete: I think we should consider the case where on RTCWeb
connections consists of a media flow and an non-media flow. It would be
good if the non-media flow doesn't drive the media flow useless.
Do you agree on this?
In this particular example, wouldn't it make sense to consider a LEDBAT
like CC for the non-media flow if the suer agrees that the media is more
important for him than the non-media?
LEDBAT is just an example. Maybe another CC is more appropriate.

Best regards
Michael
> 
> Thanks,
> --MM--
> The best way to predict the future is to create it.  - Alan Kay
> 
> 
> 
> On Fri, Apr 6, 2012 at 1:25 AM, Michael Welzl <michawe at ifi.uio.no> wrote:
>> 
> <snip>
>> 
>> To take a short point out of my previous, maybe too long email: depending on
>> the queue length, which is not under your control, saying "I want 0 delay on
>> top of the baseline" may mean that you'd only get a very small amount of
>> bandwidth.
>> 
>> One possibility would be to make that trade-off a knob for the user. Another
>> one is to let the "at least as much as the TCP equation dictates" rule in
>> Stefan's proposal take care of that, but then you don't really know how much
>> delay you'll get... e.g., maybe users could even live with less bandwidth
>> than what the TCP equation dictates, as long as the delay is smaller? I
>> think that's not an option with the currently proposed scheme.
>> 
>> Cheers,
>> Michael
>> 
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>