Dear Eddie,
Sure, I would document it properly and send you the link. It wont be
a problem :).
Yes that change looks fine to me :). Moreover there is another
interesting thing I noticed that may need to be looked at.
An interesting perspective can be seen on how we view an idle period.
A silent period where an application goes idle does not necessarily
indicate an idle period from TFRC's perspective, as there can be still
a backlog of packets in the buffer that needs to be sent out (Eg
streaming audio). In this case, due to the mismatch of the encoding
rate and the initial slowstart behavior of the TFRC sender, there can
be a backlog of packets in the encoding buffer queue.
Lets take an example..
Say there were 60 packets in the backlog when the application went
idle. And if the sender is allowed to send 50 packets (assuming this
is the maximum achievable rate), then the sender would send 50 packets
during the period and then it would send the remaining 10 packets
during the next RTT. Thus the last active receiver rate
(X_active_recv) is going to be 10 rather than 50. Thus in the faster
restart procedure, the sender has to faster restart to a maximum of 10
packets rather than 50 packets. I summarize this as follows:
* Faster Restart draft does not consider "edge case" scenario.
* Even if application is idle, there may be backlog of packets in the buffer.
* Sender sends these backlog of packets based on the allowed sending rate.
* This could lead to a small X_active_recv (which in turn determines
X_fast_max)during the last active period.
* Sender faster restarts only upto "that small" X_active_recv!
Possible solution: Set X_active_recv to maximum over two measured periods ?
Comments welcome :)..
Regards,
Arjuna
On 6/21/06, Eddie Kohler <kohler@xxxxxxxxxxx> wrote:
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
>
>
--
Regards,
Arjuna
Postdoctoral Researcher
Engineering Research Lab,
Department of Engineering,
University of Aberdeen
