On 17/08/07, Ingemar Johansson S (LU/EAB) <ingemar.s.johansson@xxxxxxxxxxxx> wrote: > Hi > > And thanks for the reponse sofar. > > Regarding the RTT ws feedback issue below. > I recall that the RTT for satellite links is ~560ms, I would expect that > Wimax has a shorter RTT. > Do you have any indication (rule of thumb wise) at what levels of RTT it > may be necessary to send more than one feedback / RTT ? We are currently trying to proof an equation allowing to compute it. However, during our experiments, the satellite service used was IPSTAR plan with a nominal uplink and downlink bandwidth of 256kbit/s and 1Mbit/s. Over IPSTAR, the RTT (avg / std.dev) is 1206.3ms / 35.7ms and the PER is ranging from 0.24% to 0.42% We improve the throughput with 10 feedback (FB) messages per RTT. The results are : 1 FB : 363.5 Kbit/s 10 FB : 552.3 Kbit/s 100 FB : 572.8 Kbit/s Emmanuel > > Regards > Ingemar > > > > -----Original Message----- > > From: Emmanuel Lochin [mailto:emmanuel.lochin@xxxxxxxxx] > > Sent: den 16 augusti 2007 23:31 > > To: Arjuna Sathiaseelan > > Cc: Ingemar Johansson S (LU/EAB); 'dccp' working group; Gorry > > Fairhurst; Golam Sarwar; Roksana Boreli; Sebastien Ardon; > > Guillaume Jourjon > > Subject: Re: DCCP for VoIP > > > > 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" > > > -- 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"
