[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: cubic patch
On 11/15/13 12:24 AM, Greg Troxel wrote:
Matthias Scheler <tron%zhadum.org.uk@localhost> writes:
On Thu, Nov 07, 2013 at 07:55:29PM +0200, Mihai Chelaru wrote:
 - ftp://ftp.netbsd.org/pub/NetBSD/misc/kefren/cubic-current.diff
Any reason not to make CUBIC the default? It is e.g. what Linux
uses for a long time.
I had the impression that CUBIC was not a standards-track RFC, and not
the recommendation of the IETF tcpimpl group, etc. I think we should
tread very carefully in moving beyond IETF recommendations.
Specifically I don't see CUBIC at
A while ago I looked at Linux TCP, I think BIC, and it seemed that it
was exceeding the amount of transmission allowed by the current
standards. But my memory of this is too fuzzy to really go on. My
point is that Linux setting CUBIC to be the default is not adequate
Also, I have a pending fix to SACK, that I posted long ago, that I will
try to get in. (By fix I mean a code bug, where after the change we'll
follow the congestion control specs more closely.) But I will need to
page this in again.
Have you compared CUBIC and our default?
Actually, I implemented CUBIC after consulting an IETF draft (
http://tools.ietf.org/html/draft-rhee-tcpm-cubic-02 ) and other
documents like the one written by Ha, Rhee & Xu. I couldn't find any RFC
regarding CUBIC. On the other hand, NewReno is referenced in several RFCs.
All my tests resulted in total throughput difference between CUBIC and
NewReno that could fit inside margin of error.
Main Index |
Thread Index |