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 -- Emmanuel Lochin http://mobqos.ee.unsw.edu.au/~lochin/ Networks and Pervasive Computing Research Program National ICT Australia Ltd Locked Bag 9013, Alexandria, NSW 1435 Australia --- "This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed"
