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
Received on Sunday, 28 July 2013 21:07:45 UTC