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
-- 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
