tech-net archive

[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:
[1] - 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
   http://datatracker.ietf.org/wg/tcpm/

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

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?


Hi,

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.


--
Mihai



Home | Main Index | Thread Index | Old Index