|
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 J 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, |
