Dear all, I am quite happy to see that the DCCP mailing list is currently being active with lots of interesting discussions. So its time for me to raise an issue on Faster Restart draft (draft-ietf-dccp-tfrc-faster-restart-01). We at University of Aberdeen, have been looking at this solution for quite some time now. From our experience, I would like to note an issue and I am wondering whether the draft was written with this in mind. Faster Restart is currently being showcased as a proposal that is used by a sender sending interactive traffic such as VoIP after "idle" periods. An idle period according to the draft : " A connection goes "idle" when the application has nothing to send for at least a nofeedback interval (as least four round-trip times)." which is fine. But interestingly (knowingly or unknowingly), FR solves another interesting problem! When VoIP taffic has VAD (Voice Activity Detection) on, the traffic is bursty. That means, the flow sends at a highly variable bit rate. Assume the encoder encodes packets for 4 RTTs in a bursty fashion, RTT1 RTT2 RTT3 RTT4 10 2 6 30 Now, with the traffic being so bursty, TFRC-SP sender's sending rate cannot accomodate this bursty traffic as the sender can increase upto twice the receiver rate. But FR does solve this mismatch. Assuming you increase the sending rate to the encoding rate during the call setup phase, the sending rate currently can be upto the encoding rate. So in this following scenario (assume no loss): RTT1 RTT2 RTT3 50 10 ? Here using FR, we have X_fast_max = 50, X_recv = 10, that means, using the FR algorithm, the sending rate can quadruple, which means X = 40, that means it can send upto 40 packets in the next RTT. So here you can see that the sender need not be idle (more than 4 RTTs) for FR to be invoked. FR can solve the problem of mismatch of encoding and sending rates due to bursty traffic to an extent if it has previously reached a higher rate. I am not sure whether the proposers of FR had this in mind, but the draft gives a view that FR can be used only after a nofeedbacktimer timeout which is not the case. Or have I got it wrong? 2) So if this is the case, can we have the minimum sending rate of 8 packets/RTT enforced at all times and not only during nofeedbacktimer timeouts? I feel this would yield better performance for bursty VoIP flows. Regards Arjuna -- Dr.Arjuna Sathiaseelan Electronics Research Group University of Aberdeen Aberdeen AB24 3UE Web: www.erg.abdn.ac.uk/users/arjuna Phone : +44-1224-272780 Fax : +44-1224-272497
