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
