Hi Bryan, Thanks for the great suggestions for DCCP work :-). I'm quite interested personally in the multipath possibilities. I'd like to hear you expand a bit on how DCCP could be a control layer for multipath TCP. Flow control for apps with sending rates that are step functions is an interesting nut. As Arjuna says, TFRC (CCID3) does allow the sending rate cap to grow to twice the current sending rate without demand from the app. And CCID2 also allows the window to grow without demand (to some cap too, I believe). So as long as your app's step sizes are less than a factor of 2, it could return to the higher rate if there was some API support to indicate the higher rate was available. There are other problems with returning to a higher rate, though. If you've been transmitting at X for a while, sure, CCID3 will allow you to double that, but it has no knowledge of whether that's really possible or not (has capacity become available or are things just well-balanced as they are?). You could return to the higher rate only to be forced immediately back to the lower rate. And the psychological impression of varying quality is worse than consistently low quality. There are other mismatches as well. CCID3 adjusts allowed rate on a continuous spectrum, which can cause problems for apps that can only make step adjustments, but it also makes those adjustments at what to the app look like arbitrary moments. Many media apps can only make rate adjustments at frame boundaries. What do they do with the data that's already encoded from the last frame when CCID3 makes an allowed rate change? Note that typical frame rates and typical RTTs are rough-order-of-magnitude similar. Would it really hurt to wait until the next frame to change the rate? But of course there's no mechanism in CCID3 to support that. Some of these topics might be better for ICCRG, but the idea as I understand it is for DCCP and ICCRG to work together on these sorts of things. Tom P. ________________________________________ From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf Of Arjuna Sathiaseelan Sent: Wednesday, July 29, 2009 12:55 PM To: 'Bryan Ford'; 'Pasi Sarolahti'; dccp@xxxxxxxx Cc: gorry@xxxxxxxxxxxxxx Subject: Re: DCCP work ideas Dear Bryan, DCCP’s CCID’s do probe for capacity for e.g. CCID 3 (which follows TFRC) would allow the sender to send upto twice the receiver rate or that allowed by the throughput equation (which ever is small) and hence its upto the application to decide whether to retract back to its original higher media rate. CCID-2 would grow its cwnd like TCP would and hence probing occurs here too… The RFC-to-be draft Quickstart for DCCP – allows the use of QS with DCCP – and hence the sender could probe for additional capacity using QS – which in turn could be used by the app to decide whether to use a higher media rate.. So I believe that it’s an application/API problem rather than the transport.. Correct me if I am wrong ☺ Regards Arjuna DCCP's congestion control will not try to probe for bandwidth and the application will never know when it can move back up to 128Kbps. So solve this by developing an extension to DCCP's congestion control mechanisms an a corresopnding API allowing applications to maintain a standing "request" for more bandwidth than they're actually using at the moment, and to notify the application when the full amount of requested bandwidth appears to be available. That should allow media applications to follow DCCP's congestion control decisions without giving up the control they need in order to utilize available bandwidth dynamically. There are several alternative ways to achieve this at the congestion control level, at least one of which might even be reasonably safe and efficient; I'll try to write it up in a follow-on E-mail shortly. Thanks, Bryan
