[R-C] LEDBAT - introductions?

[Michael Welzl]

Hi,

So there are a few convoluted things here:

1) Matt wants to have a statement that says that we assume that RTCweb  
traffic is somehow isolated from other traffic. I don't think that  
this statement is useful, but I see Matt's point and I'm generally in  
favor of narrow scopes too, so I don't have a strong opinion about it  
and we can stop discussing that bit. It's fine if it stays.

2) The above assumes that the notion of "RTCweb traffic" includes  
media- and non-media traffic. If you're idea is to say that we should  
ignore non-media *RTCweb* traffic by assuming that it will somehow be  
isolated from RTCweb media traffic, then I am very strongly against  
that and would call it a very bad idea. Because we're in control of  
both, and simply don't want one to hurt the other!

Some more details in line below:


On Apr 7, 2012, at 10:40 AM, Michael Tuexen wrote:

> 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

If your goal for that "isolation" paragraph is 1) above, not 2), then  
what you and I think about delay sensing for congestion control  
probably doesn't matter much in the context of this discussion. If  
this is your argument for 2), then yes, it does! Anyway, here's my  
opinion about that statement:

1) what is the basis for saying that delay sensing does not work for  
general purpose congestion control? Do you have any evidence for that?  
(yes, there is counter-evidence; operational experience with LEDBAT in  
BitTorrent, to name but one)
2) stability => there would be a number of well done papers  
disagreeing with that.
3) fairness => I think the fairness problems (typically the "late- 
comer" problem) are known, can be overcome, and in the end, the finer  
grain feedback signal allows you to have much better control over  
fairness than what you get with e.g. TCP's horrible pseudo-fairness.
4) without relying on delay, exactly how do you plan to minimize  
queuing delay?
5) you ARE aware that draft-alvestrand-rtcweb-congestion is delay-based?


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

I'd replace "need" with "want" and change what you write below on that  
basis, but this is the part that I don't have a strong opinion about.


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

I agree with everything Michael says here.

And as an additional thought, in this example of a greedy data flow,  
if the user prioritizes the non-greedy step-function based media  
traffic, using only one congestion control for both mechanisms would  
make that only ONE greedy flow, and the bandwidth between them decided  
by scheduling. You end up having no competition for bandwidth between  
media and non-media traffic, just one flow that's greedy yet trying to  
keep the queue minimal. There are TCP's that can do that.

I just cannot see how having two separate congestion controls  
competing here could do a better job at minimizing delay.
All that could be achieved by using only one single congestion control  
mechanism for all RTCweb streams, and make that sensitive to delay,  
and (*only* for the case that there is no RTCweb data traffic) let it  
work well with non-greedy-senders.

Cheers,
Michael