AH.
Is TCP-BIC the default in current versions of Linux? That would be a surprise.
DCCP should match SACK, which since it is standardized by the IETF I would
expect to be the default.
Eddie
Ian McDonald wrote:
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
