[e2e] Linux TCP
touch at isi.edu
Fri Aug 19 14:07:12 PDT 2011
On 8/19/2011 7:49 AM, Hagen Paul Pfeifer wrote:
> Your questions cannot answered from a technical view. Vendors (and Linux)
> act not purely driven by standards. Operating systems often differs because
> their is simple no standard, or because the standard do not fulfill the
> requirements of the customer, sometimes the standard is crap and so on.
(as an individual)
There *is* a standard for the Internet, and it is not CUBIC ;-)
> You asked why has Linux chosen to enable a non-standard CC algorithm as
> the default. Because the non-standardized - but well analyzed - CUBIC IS a
> fair and a compatible CC algorithm respecting NewReno and friends.
There are a few studies to the contrary, esp. when the bottleneck BW is
high (but still a bottleneck). Also, CUBIC is known to perform worse
than NewReno in low RTT environments, AFAICT.
If you have sufficient evidence to the contrary - please take it to the
IETF and suggest a change to the congestion control standards.
> simultaneously make some customers happy (those with larger LFN's).
> Everybody knows that CUBIC _could_ be the defacto "standard", at least with
> status experimental.
There's a mechanism for that - it's called the IETF. However,
"experimental" does not permit a protocol to be deployed as default in a
wide-scale environment; the goal of "experimental" is to do an
experiment before such a deployment.
> Operating systems must respect constraint imposed by standardization
> bodies - like TCP fairness. If a standardization body show that there are
> some real fairness issue in Linux, then Linux will hear and react to this -
> no doubt. Standardization bodies on the other hand should align their
> development with real life demands.
This is reversed. The onus of proof rests with CUBIC, to ensure that it
does no harm *before* it is deployed.
The IETF does adjust to the needs of the community, but it relies on the
community to bring the issues to the IETF. Not to do end-runs.
However, Linux is *famous* (IMO) for accepting code first and asking
questions later. It's one reason I prefer FreeBSD for my research (that,
and the fact that FreeBSD's stack has been a good decade more advanced
than Linux - speaking as one who did things with FreeBSD in 2000 that
Linux is only recently able to match).
Joe (again, speaking as an individual)
More information about the end2end-interest