On 9/23/06, Eddie Kohler <kohler@xxxxxxxxxxx> wrote:
Hi Ian, I am cc'ing the IETF list regarding one point in your recent mail, which I found a little confusing. Ian McDonald wrote: > The calculation is based on the work Padhye et al did in this paper - > http://citeseer.ist.psu.edu/padhye98modeling.html > > As it turns out this is based on TCP Reno at that time and modern TCP > variants are more efficient when dealing with loss as can be verified > through iperf but we should implement what the RFC says. Is this really so? Sally will correct me when I no doubt misspeak, but I believe the difference between NewReno and Reno is that NewReno makes it more likely that multiple losses in a single RTT will be treated as a single loss event, through modifications to fast recovery. In DCCP CCID 3 these issues do not exactly arise. The receiver explicitly reports loss *intervals*. The receiver can, and should, use SACK/NewReno algorithms to determine those loss intervals. So it is possible that CCID 3 will send slower than TCP but I don't think this is the reason. The reason should be investigated. Eddie
Eddie, A quick response and then I might do some testing later if you want some more data. DCCP CCID3 in the Linux kernel (as of 2.6.18 but not before) has performance that matches the calculation in Padhye. I verify this by using a calculator my research group produced (http://wand.net.nz/~perry/max_download.php) Now using a standard Linux kernel for loss around 1%-20% and 100 msec rtt and using iperf the numbers for TCP were about 5 x higher throughput from memory. This was TCP-BIC. These are higher than what the website shows also of course. I haven't done recent testing for the Reno in the kernel but from memory it used to match Padhye. Ian -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand
