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?