Re: setting bandwidth

On 07/29/2013 12:58 AM, cowwoc wrote:
> On 28/07/2013 5:06 PM, Harald Alvestrand wrote:
>> On 07/28/2013 10:43 PM, cowwoc wrote:
>>>
>>>     Look, when I try to upload a very large file over TCP I see the
>>> upload speed peg at close to 100% of capacity seemingly immediately.
>>> Can't we take the same mechanism as TCP and layer it on top of what
>>> WebRTC uses today? I'd like to avoid drilling down into the specific
>>> implementation at this time. All, I'm asking is whether this is
>>> technically doable and if not, why.
>>>
>>>     Let's not lose track of the goal of this discussion, which is to
>>> enable users to specify the initial/minimum bandwidth usage so chat
>>> sessions don't start out with blurry/choppy video at 1080p. If you
>>> have an alternative for achieving this, I'm all ears.
>>
>> That may be YOUR goal in this discussion. It is certainly not a
>> formulation I'll sign up for as a WG goal.
>>
>> In the IETF, the first goal is the continued survival of the
>> Internet; all other desires are subordinate to that.
>>
>> We know from bitter experience (google "congestion collapse") that
>> badly designed congestion control, when deployed simultaneously by a
>> large fraction of the nodes on the Internet, brings problems that can
>> render the Net unusable, and which - mark this - do NOT show up in
>> tests done with only a few users.
>> The IETF congestion people are conservative, and have good reason to be.
>>
>> I think we can agree that there is a clear desire to start up chat
>> sessions with video that is pleasing to the user.
>>
>> I don't think we have any kind of consensus that letting the browser
>> obey any suggestion for initial bandwidth that comes from the user,
>> no matter what it knows (or knows it doesn't know) about the network
>> conditions between the sender and the recipient, is a reasonable way
>> to achieve that.
>>
>> Harald
>>
>
> Harald,
>
>      The only reason I brought up the example of HTTP upload or
> WebSockets is to ask what we can learn anything from how other
> technologies handle this problem. I'm only interested in the "what"
> (instant-on clear/smooth video chat sessions) not the "how". To that
> end, do you have any ideas?

My best idea at the moment is to start the video without showing it,
waiting for a few tenths of a second to let the congestion manager ramp
up, and then show it.

That depends on having a bandwidth manager that can ramp up in a few
RTTs rather than multiple seconds, of course, but the relevant WG is the
IETF RMCAT WG rather than this one.

This group needs to focus on how it exposes controls for things that can
live within the constraints set by the environment it has to live in.