Also would like to add - I used TFRC-SP for my simulations. -Arjuna On 5/5/06, Arjuna Sathiaseelan <arjuna.sathiaseelan@xxxxxxxxx> wrote:
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
-- Regards, Arjuna Postdoctoral Researcher Engineering Research Lab, Department of Engineering, University of Aberdeen
