Sorry for the delay - I just noticed that I never answered this one: On 4/10/12 2:04 PM, Randell Jesup wrote:
On 4/10/2012 1:54 AM, Michael Welzl wrote:
On Apr 10, 2012, at 7:13 AM, Harald Alvestrand wrote:
I would like to have at least some idea of the benefit we're gaining from a short reaction time in order to evaluate what the cost/benefit tradeoff is.
Well okay, my statement here was handwavery. Let's put it this way, I imagine you causing problems with competing TCPs if you react slower, and I'd at least like to see this potential problem investigated (and that's how you can figure out the trade-off).
Please see my discussion elsewhere which shows that except for the huge-sudden-congestion case a delay-sensing algorithm such as this should sense and react to imminent congestion earlier than a loss-based algorithm such as TCP would. (Otherwise it wouldn't be doing a very good job at avoiding delay!) We're in agreement here.
On the other hand, as I keep saying: if you constantly receive SCTP ACKs from a parallel RTCweb data transfer, you should make use of that other feedback.
While there are use-cases for rtcweb which involve "infinite" data sources (or at least close enough), by far most uses in rtcweb of the data channel are short, bursty, or paced at relatively low bandwidth. There are a few use-cases where large background transfers are done (largish file transfer), but most of those are typically a short burst in a longer call/connection. So it's a bad idea to plan on a "constant stream of SCTP ACKs"...
No, not rely on that always being there, but make use of that when it's there - I was thinking of the scenario you get when you chat with someone and send that person some files (private pictures, ..) in the background in parallel.
If you have some SCTP traffic, then yes it would be nice if that helped your algorithm, but I think you'll find that the existing media streams will typically be far more frequent (and reliable). In a "normal" video chat, you'll have 10-30 frames/second of video (of 1 to (say) 6 packets per You're talking about RTCweb as if that would be a very common thing out there already :-) who knows how people will want to use the data channel in the future? Maybe it becomes a very popular means to send lots of files across...
frame), plus typically 50 audio packets per second - in each direction, each carrying timing information. So in normal situations, there's plenty of timing traffic to use from media streams. There are cases where there may be one-way traffic, and knowledge of the idle direction's bandwidth will degrade - but that's ok, if the traffic starts up again is should see no delay (barring TCP causing standing queues). At most the algorithm should revert back to the starting state (faster adaptation, perhaps start-point, though I'd want the restart point to be based on our last good estimate, etc).
So, does that answer your concerns? I'm not sure my concerns about what is now called RRTCC are answered, but I think that we pretty much agree design-wise anyway. I'm now just a bit confused by the mix of 1) arguments against my suggestion to use only one congestion control instance for everything (ideally by making all RTCweb flows streams of one SCTP association), 2) some statements saying "yeah, this was the plan anyway".
Maybe it's because I don't know RTCweb well enough yet, or don't understand who does what and who plans what... and maybe it's also because I proposed too many intertwined things in one go (all-over-SCTP *and* one congestion control instance for everything). Whatever. Anyway, I think it's an interesting discussion :-) Cheers, Michael