This sounds like a very interesting idea. While the documents specify that
feedback is sent once per RTT, since this is what TFRC recommends, I think
more frequent feedback is a fine idea even for low-loss-rate/low-RTT scenarios
(twice or four times per RTT, say?), and probably mandatory for high-RTT
scenarios. My guess is Sally would agree. Perhaps someone could suggest a
change to the CCID3/4 language.
Eddie
Emmanuel Lochin wrote:
Hi Arujna,
I have a question concerning the following point:
On 16/08/07, Arjuna Sathiaseelan <arjuna@xxxxxxxxxxxxxx> wrote:
2) How often is feedback sent? (sorry for a qu estion that I should
probably answer myself by means of some RTFM) but if you could answer it I
would really appreciate it.
Usually CCIDs incorporating the TFRC or TFRC-SP protocol would send a
feedback once per RTT, unless there is a change in the loss event. If there
is a change in the loss event then the feedback would be sent immediately.
Alternatively these protocols could send multiple feedbacks per RTT (when
there is no change in the loss event) but it is not a common practice in my
opinion.
I am wondering why this is not a common practice?
We (Golam, Roksana and me, in copy of this email) are currently evaluating
GNU/Linux DCCP/CCID3 over over live satellite and long range wireless links.
As expected, DCCP/CCID3 obtains poor performance compared to TCP.
In a logical way, on such long delay networks, the feedback loop is linked
to the delay of the connection and thus, cannot update the transmitted
rate as efficiently as over a low delay network.
However, if we increase the number of feedback messages as a function
of the RTT over these long delay networks, DCCP/CCID3 performance are
really better. This has been verified in ns-2.30 and over satellite
and Wimax networks. As a result, we are currently considering a
dynamic algorithm for adjusting the amount of DCCP feedback based on
RTT.
Emmanuel
