Dear All, I have been reading the FR draft, Vlad's thesis and his paper, did some simulation tests and I would like to summarise and also try to propose certain suggestions from what I have perceived. 1) Minimum Sending Rate: Vlad's thesis/paper proposes TFRC-SP+FR+MD which sorts out the problem of low receiver rate after an idle period (which has been resolved in the FR draft) and "most" importantly suggests that the sending rate is NEVER reduced below 8 packets/RTT AT ALL TIMES, which according to me is a good thing to do. But Eddie does not agree with this. I am pasting some of our comments from a previous mail on this issue: " Arjuna: So if this is the case, can we have the minimum sending rate of 8 packets/RTT enforced at all times and not only during nofeedbacktimer timeouts? I feel this would yield better performance for bursty VoIP flows. Eddie: 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!" So we got to see by tests to see if maintaining 8 pkts per RTT AT ALL TIMES is good or bad? According to me this is important to do. 2)Receiver Rate after idle periods: There are two cases here: 2a) Large Idle Period where a nofeedback timer has expired. 2b) Small Idle Period (less than 4RTTs) Now we have two receiver rate adjustment algorithms proposed in the current FR draft. But it does not say which one to use. So I would suggest something like this: For the FIRST feedback packet and the FIRST feedback packet after a nofeedback timer expiry, we use the first receiver rate adjustment algorithm i.e. we ignore the feedback packet. For small idle periods, we use the second receiver adjustment algorithm. Some questions still remain to be answered: What happens if the application say "keeps on sending 2 packets every two RTTs" and the second receiver rate adjustment algorithm along with FR algorithm does not help to maintain the minimum sending rate (I had given a sample scenario in my previous mail to the mailing list). So do we ignore this feedback packet too? 3) Vlad's paper say that TCP is better than TFRC/TFRC-SP/TFRC-SP-FR etc in most situations. But also says that TCP has this problem of retransmissions where delays could occur. So how about using CCID2 for VoIP? We have the same mechanism as TCP and we also do not have retransmissions. Would this work? These are my thoughts and I would like to know your thoughts on this. Correct me if I am wrong. Thanks Regards 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
