You are neither wrong nor stupid, but I'm not sure that your suggested
algorithm is the best possible fix.
Part of my confusion stems from the fact that I can't quite follow the
example. Where is the idle period? Exactly which packets are sent when?
Also are you measuring X in bytes per second? Because if you are, then the
quadrupled rate (=> 888 B/s) is more than 4 160-byte packets per second, even
with headers.
I share your concern about Vlad's "first adjustment algorithm", namely
ignoring the first feedback packet after an idle period might cause problems
if a feedback packet covered multiple idle periods. But we aren't quite there
yet.
So please explain the scenario in more detail.
Thanks!
Eddie
Arjuna Sathiaseelan wrote:
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@xxxxxxxxx> 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
