Re: [PATCH] TCP-Hybla proposal

[Stephen Hemminger]

On Tue, 22 Feb 2005 15:34:42 +0100
Daniele Lacamera <mlists@xxxxxxxxxxxxxx> wrote:

> Hi
> This is the official patch to implement TCP Hybla congestion avoidance.
> 
> - "In heterogeneous networks, TCP connections that incorporate a 
> terrestrial or satellite radio link are greatly disadvantaged with 
> respect to entirely wired connections, because of their longer round 
> trip times (RTTs). To cope with this problem, a new TCP proposal, the 
> TCP Hybla, is presented and discussed in the paper[1]. It stems from an 
> analytical evaluation of the congestion window dynamics in the TCP 
> standard versions (Tahoe, Reno, NewReno), which suggests the necessary 
> modifications to remove the performance dependence on RTT.[...]"[1]
> 
> [1]: Carlo Caini, Rosario Firrincieli, "TCP Hybla: a TCP enhancement for 
> heterogeneous networks", 
> International Journal of Satellite Communications and Networking
> Volume 22, Issue 5 , Pages 547 - 566. September 2004.

This looks interesting.

> Please note that this patch:
> - cleanly compiled against 2.6.11-rc4;
> 
> - reached very good results in terms of fairness and friendliness with 
> other TCP standards and proposals during tests;
> 
> - gives a throughput very close to maximum fair share when satellite 
> connections fight for bandwidth in a terrestrial bottleneck, and 
> improves their performance also in case of no congestion;
> 
> - acts exactly as newreno when minimum rtt estimated by the sender is 
> lower or equal to rtt0 (default=25 ms).
> 
> The protocol is obviously disabled by default and can be turned on by 
> switching its sysctl, as usual.

Probably the best long term solution is to make the protocol choice
be a property of the destination cache.

> As Mr.Yee-Ting Li pointed out in his last thread, the deployments of 
> these experimental protocols are too premature and they should be 
> switched OFF by default to prevent undesirable consequences to network 
> stability.
> 
> One last note: IMHO we really need a better way to select congestion 
> avoidance scheme between those available, instead of switching each one 
> on and off. I.e., we can't say how vegas and westwood perform when 
> switched on together, can we?

The protocol choices are mutually exclusive, if you walk through the code
(or do experiments), you find that that only one gets used.  As part of the
longer term plan, I would like to:
	- have one sysctl
	- choice by route and destination
	- union for fields in control block


Is there interest in setting up a semi official "-tcp" tree to hold these?
because it might not be of wide interest or stability to be ready for mainline
kernel.
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html