Hi Arjuna,
I would LOVE LOVE LOVE LOVE to see your faster restart ns-2 implementation!!
Can you send a link to the list?
Arjuna Sathiaseelan 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.
I agree with you. The faster restart draft should be changed to calculate and
use X_recv_limit, including faster restart's X_fast_max comparison,
*regardless* of whether TFRC is in slow start or not. This will not change
the behavior of the initial slow start phase, since X_fast_max <= X there anyway.
My suggested pseudocode is as follows. The only changes are in the third phase.
To update X when you receive a feedback packet
----------------------------------------------
/* First phase. Calculate X_fast_max */
/* If idle for <= 10 minutes, end faster restart at the
full last fair rate; if idle for >= 30 minutes,
don't do faster restart; in between, interpolate. */
delta_T := now - T_active_recv,
F := (30 min - min(max(delta_T, 10 min), 30 min)) / 20 min,
X_fast_max := F*X_active_recv.
/* Second phase. Update X_active_recv */
If the feedback packet corresponds to an active period
and does not indicate a loss or mark, then
If X_recv >= X_fast_max, then
X_active_recv := X_fast_max := X_recv,
T_active_recv := current time.
Else if X_recv < X_fast_max and the feedback packet
DOES indicate a loss or mark,
X_active_recv := X_fast_max := X_recv/2,
T_active_recv := current time.
/* Third phase. Calculate X */
X_recv_limit := 2*X_recv.
If X_recv_limit < X_fast_max,
X_recv_limit := min(4*X_recv, X_fast_max).
If p > 0,
Calculate X_calc using the TCP throughput equation.
X := max(min(X_calc, X_recv_limit), s/t_mbi).
Else
If (t_now - tld >= R)
X := max(min(2*X, X_recv_limit), s/R);
tld := now.
Eddie
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
