Hi Tom, That's exactly what I found out when I implemented faster restart in ns-2 and did some tests :)..With a CBR source modelling a G.711 codec sending 50 pps - and assuming there is reasonable bottleneck bandwidth available such that there is no packet loss - then the sender never leaves slow start..It doesnt get into congestion avoidance..So when a feedback timer expires - based on the algorithm, it stays in the slow start part of the algorithm - after the silence suppression period with p = 0. So it never executes the faster restart part where p > 0. So in this typical scenario - the sender behaves as an ordinary TFRC sender.
but I'm not sure what the resulting max transmit rate would be. Normally it'd be half the rate in the last RTT, but that was zero in this case, since the app went idle
No - the maximum rate would be the last ACTIVE received rate (if there was a packet loss or ecn mark - then the received rate wuld have be reduced by half). But if there were no packet loss (p = 0) - then the maximum rate would be the last active received rate (which is the highest achievable rate). So in our case, what happens next is the question? :) does it exit slow start? If so, how is it going to execute the p > 0 part of the algorithm? Questions worth an investigation :)..Thanks for your reply :) -Arjuna On 5/5/06, Phelan, Tom <tphelan@xxxxxxxxxxxx> wrote:
Hi Arjuna, Part of the justification for faster restart is that the path has already been proven to support a higher rate (by earlier transmissions), and we're just trying to return to that. That justification doesn't exist for slow start. But let me see if I understand your scenario. An application reaches its desired throughput before first packet loss and therefore never leaves the slow start phase. I'd say that this is a fairly normal situation with media streams -- the user has chosen a codec that's likely to not congest the network in the absence of competing flows -- although the presence of any TCP flow would probably disrupt that. After some period at this rate with no packet loss the application goes idle long enough for the nofeedback timer to expire. This would seem to be a fairly likely situation for silence-suppressed voice. I'm not sure what happens then (no time to reread the spec and figure it out, sorry). I would expect the nofeedback timer to cause the connection to leave slow start, but I'm not sure what the resulting max transmit rate would be. Normally it'd be half the rate in the last RTT, but that was zero in this case, since the app went idle. Sounds worth investigating... Tom P. > -----Original Message----- > From: Arjuna Sathiaseelan [mailto:arjuna.sathiaseelan@xxxxxxxxx] > Sent: Friday, May 05, 2006 3:29 AM > To: h.balan@xxxxxxxxxxxx > Cc: gorry@xxxxxxxxxxxxxx; dccp@xxxxxxxx > Subject: Re: minimal sending rate in the case of tfrc for small > packetsand its faster restart variant > > I would like to add something here..Its a doubt.. > > I am wondering what happens where there is an idle period during slow > start where the nofeedback timer has expired - with p = 0. Faster > restart wouldnt work with the given algorithm - since it doesnt make > any changes to the existing TFRC slow start algorithm. Shouldnt faster > restart proposal modify the slowstart part of the algorithm as well? > Please do correct me if I am wrong. Thanks :) > > If p > 0, > Calculate X_calc using the TCP throughput equation. > X_recv_limit := 2*X_recv. > If X_recv_limit < X_fast_max, > X_recv_limit := min(4*X_recv, X_fast_max). > X := max(min(X_calc, X_recv_limit), s/t_mbi). > Else > If (t_now - tld >= R) > X := max(min(2*X, 2*X_recv), s/R); > tld := now. > > > -Arjuna > > On 5/2/06, h.balan@xxxxxxxxxxxx <h.balan@xxxxxxxxxxxx> wrote: > > We are sending interactive voice traffic over CCID 3(RFC4342) (also > > its variant for small packets draft-ietf-dccp-tfrc-voip-05.txt and > > the variant for small packets with with faster restart draft-ietf- > > dccp-tfrc-faster-restart-00.txt), trying to observe the impact of > > the protocol on the end-to-end quality. Since the codec uses > > silence suppresion, our traffic contains periods of data > > transmission alternating with periods of idleness, and due to the > > fact that we experience frequent slow start (we can only double our > > transmission rate during one RTT), the minimal rate of TFRC is an > > important factor affecting the transmission quality. > > We kindly ask you for some clarifications regarding the way in > > which the rate is set in the case of TFRC for small packets and its > > faster restart variant. > > > > RFC 3448, section 4.3 states: > > "If (p > 0) > > Calculate X_calc using the TCP throughput equation. > > X = max(min(X_calc, 2*X_recv), s/t_mbi); > > Else > > If (t_now - tld >= R) > > X = max(min(2*X, 2*X_recv), s/R); > > tld = t_now;" > > while draft-ietf-dccp-tfrc-voip-05.txt requires the nominal packet > > size s to 1460 bytes; > > > > Question 1) Should s=1460 bytes be used in the factors s/t_mbi and > > s/R ? If so, should they be corrected by a factor s_true / (s_true > > + H) accounting for the header size? > > The difference between the two methods is significant in the case > > of VoIP packets, reaching over an order of magnitude. > > > > draft-ietf-dccp-tfrc-faster-restart-00.txt states: > > "This document suggests a relatively simple approach to this problem. > > Some protocols using TFRC [CCID 3 PROFILE] already specify that the > > allowed sending rate is never reduced below the RFC-3390 sending > > rate of four packets per RTT during an idle period. Faster Restart > > specifies that the allowed sending rate is never reduced below eight > > packets per RTT, for small packets." > > > > Question 2) Is the rate of eight packets per RTT the minimal rate > > of the protocol even in periods of non-idleness? Relating to the > > previous question, should the averaged packet size or the nominal > > packet size of 1460 bytes be used in the calculation of the rate? > > > > In case the answer to the previous question is affirmative, should > > the rate calculation at the end of section 3. become: > > "If p > 0, > > Calculate X_calc using the TCP throughput equation. > > X_recv_limit := 2*X_recv. > > If X_recv_limit < X_fast_max, > > X_recv_limit := min(4*X_recv, X_fast_max). > > X := max(min(X_calc, X_recv_limit), 8*s/R). <= changed minimal > > rate > > Else > > If (t_now - tld >= R) > > X := max(min(2*X, 2*X_recv), 8*s/R); <= changed minimal rate > > tld := now." > > > > Changing the minimal rate from s/t_mbi to 8*s/R while in congestion > > avoidance mode shortens the time needed to reach the codec's > > nominal transmission rate by log_4(8*t_mbi/R) RTTs ~= 6 RTTs for a > > connection with 50ms round trip. > > > > Vlad Balan > > > > > > > > > -- > Regards, > Arjuna > > Postdoctoral Researcher > Engineering Research Lab, > Department of Engineering, > University of Aberdeen
-- Regards, Arjuna Postdoctoral Researcher Engineering Research Lab, Department of Engineering, University of Aberdeen
