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
