Arjuna Sathiaseelan wrote:
Dear all, I am quite happy to see that the DCCP mailing list is currently being active with lots of interesting discussions.
Yeah I wish the issues were all about how TOTALLY AWESOMELY TFRC behaved but oh well.
So its time for me to raise an issue on Faster Restart draft (draft-ietf-dccp-tfrc-faster-restart-01). ... 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?
I think you have got it wrong. FR is used whenever a feedback packet is received -- the nofeedback timer is not relevant. I would personally approve of the use of FR you describe. And I think the draft totally encourages it.
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.
In periods of extreme congestion it is possible that a flow's fair share is less than 8 pkt/RTT. The initial sending rate is NOT a minimum sending rate. HOWEVER, flows should NEVER drop below the initial sending rate EXCEPT in periods of extreme congestion. Idle periods, for example, should not cause the sending rate to drop below 8 p/RTT. Hopefully the current FR draft contains sufficient mechanism to enforce this. If it doesn't let us know!
Eddie
