Dear Eddie,
I just managed to implement the receiver rate adjustment algorithm
(the second adjustment algorithm) mentioned in the draft. I did some
tests with bursty traffic and found that the using second algorithm is
not being able to maintain the minimum sending rate ( equal to the
initial sending rate) in certain cases. One case is this:
RTT = 600ms, packet size = 160 bytes:
One packet is sent by the application in 1.44 s, which means the
receiver reports X_recv_in = 111, and using the second adjustment
algorithm, we get X_recv = 222. So using the FR algorithm we could
quadruple to 888 which is less than the minimum rate = initial rate of
4 packets per RTT.
Now in this case its wise to use the first adjustment algorithm by
ignoring this feedback packet.
But what happens if the same thing happens again? :). Another 1 packet
in 1.44s? Do we ignore that feedback packet too?
I havFrom dccp-bounces at ietf.org Wed Sep 27 13:21:28 2006
Dear Eddie,
I just managed to implement the receiver rate adjustment algorithm
(the second adjustment algorithm) mentioned in the draft. I did some
tests with bursty traffic and found that the using second algorithm is
not being able to maintain the minimum sending rate ( equal to the
initial sending rate) in certain cases. One case is this:
RTT = 600ms, packet size = 160 bytes:
One packet is sent by the application in 1.44 s, which means the
receiver reports X_recv_in = 111, and using the second adjustment
algorithm, we get X_recv = 222. So using the FR algorithm we could
quadruple to 888 which is less than the minimum rate = initial rate of
4 packets per RTT.
Now in this case its wise to use the first adjustment algorithm by
ignoring this feedback packet.
But what happens if the same thing happens again? :). Another 1 packet
in 1.44s? Do we ignore that feedback packet too?
I have a feeling that we could have something like this:
X_recv_limit := max(2*X_recv,s/R).
or something like this:
X_recv = max(X_recv_in*(T2 - T1 + I)/(T2 - T1), s/R)
So that we make sure that the receiver reported rate doesnt go below
one packet per RTT.
My few cents and pardon me if I am wrong and stupid :)
-Arjuna
On 9/24/06, Arjuna Sathiaseelan <arjuna.sathiaseelan at gmail.com> wrote:
Dear Eddie,
Thanks for your reply :).
> I think you have got it wrong. FR is used whenever a feedback
packet is
> received -- the nofeedback timer is not relevant. I would
personally approve
> of the use of FR you describe. And I think the draft totally
encourages it.
That sounds good to me :)
> In periods of extreme congestion it is possible that a flow's fair
share is
> less than 8 pkt/RTT. The initial sending rate is NOT a minimum
sending rate.
> HOWEVER, flows should NEVER drop below the initial sending rate
EXCEPT in
> periods of extreme congestion. Idle periods, for example, should
not cause
> the sending rate to drop below 8 p/RTT. Hopefully the current FR draft
> contains sufficient mechanism to enforce this. If it doesn't let us
know!
I guess the current draft allows us to maintain the initial sending
rate. One occurrence or a possibility of the flows dropping below the
low initial sending rate is "say" when the application sends one
packet every 2 RTTs, but the Receive Rate Adjustment algorithm should
solve this issue. So I feel the algorithm holds good. :)
Thanks for your clarifications :).
Arjuna
--
Dr.Arjuna Sathiaseelan
Electronics Research Group
University of Aberdeen
Aberdeen AB24 3UE
Web: www.erg.abdn.ac.uk/users/arjuna
Phone : +44-1224-272780
Fax : +44-1224-272497