[e2e] Linux TCP

[Joe Touch]

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.

 > AND
> 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).

FWIW.

Joe (again, speaking as an individual)