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.
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.
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?
I'd really appreciate if you consider my work for apply.
TIA,
--
Daniele Lacamera
root at danielinux.net
On Tuesday 22 February 2005 15:34, Daniele Lacamera wrote:
> Hi
> This is the official patch to implement TCP Hybla congestion
avoidance.
I've post a wrong/unclean patch. Here's the right one.
Sorry.
--
Daniele Lacamera
root at danielinux.net
On Tue, 22 Feb 2005 15:34:42 +0100
Daniele Lacamera <[email protected]> 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.
On Tue, 22 Feb 2005, Stephen Hemminger wrote:
> On Tue, 22 Feb 2005 15:34:42 +0100
> Daniele Lacamera <[email protected]> wrote:
>
> > 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.
An idea I've been toying with for a while now is completely abstracting
congestion control. Then you could have congestion control loadable
modules, which would avoid this mess of experimental algorithms inside the
main-line kernel. If done right, they might be able to work seamlessly
with SCTP, too. The tricky part is making sure the interface is complete
enough.
-John
On Tue, 22 Feb 2005 13:03:11 -0500 (EST)
John Heffner <[email protected]> wrote:
> An idea I've been toying with for a while now is completely abstracting
> congestion control. Then you could have congestion control loadable
> modules, which would avoid this mess of experimental algorithms inside the
> main-line kernel. If done right, they might be able to work seamlessly
> with SCTP, too. The tricky part is making sure the interface is complete
> enough.
The symbols exported to allow this would need to be EXPORT_SYMBOL_GPL().
On Tue, 22 Feb 2005 09:42:19 -0800
Stephen Hemminger <[email protected]> wrote:
> 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
Let's take a first baby step and make the congestion control
algorithm a single enumeration instead of all of this
tp->foo_cong_ctrl_on, tp->bar_cong_ctrl_on stuff. Then make
the union to shrink the tcp_sock size, we could even use an
anonymous union to make the patch a lot smaller.
We can't just get rid of all the existing sysctls. We can
add a new one that just makes the choice as you describe.
We could therefore do something like this:
enum tcp_congctrl_alg tcp_global_congctrl_alg;
And then we use a special sysctl handler for all the individual
sysctl_tcp_bic et al. enablers that does something like:
if (tcp_global_congctrl_alg == TCP_CONGCTRL_BIC)
return 1;
return 0;
and setting just does the necessary assignment to
tcp_global_congctrl_alg. Well... I hope the sysctl framework
allows something like this :-) If not, it should not be hard to
add.
Stephen Hemminger wrote:
> On Tue, 22 Feb 2005 15:34:42 +0100
> Daniele Lacamera <[email protected]> wrote:
>>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
I'm currently working on a patch to make it a single sysctl, I've got it
working (as in, the kernel doesn't crash). I still need to validate the
actual implementation.
I'd say the next stage is to merge fields as much as possible.
I doubt the real use of selection by route/dest, all of the high-speed
protocols (except possibly for TCP-Hybla) are intended for sender-only
servers who push lots of data and should work in all cases and alongside
Reno TCP traffic without undue unfairness.
I hope to finish the clean-up and preparation of H-TCP for inclusion in
the kernel and can then help with the unionisation.
Baruch
On Tue, 22 Feb 2005 10:14:47 -0800, David S. Miller <[email protected]> wrote:
> On Tue, 22 Feb 2005 13:03:11 -0500 (EST)
> John Heffner <[email protected]> wrote:
>
> > An idea I've been toying with for a while now is completely abstracting
> > congestion control. Then you could have congestion control loadable
> > modules, which would avoid this mess of experimental algorithms inside the
> > main-line kernel. If done right, they might be able to work seamlessly
> > with SCTP, too. The tricky part is making sure the interface is complete
> > enough.
>
> The symbols exported to allow this would need to be EXPORT_SYMBOL_GPL().
Why's that?
--
[ Tobias DiPasquale ]
0x636f6465736c696e67657240676d61696c2e636f6d
On Tue, Feb 22, 2005 at 03:34:42PM +0100, Daniele Lacamera 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.
It's disappointing that this paper appears to be available only
through subscription sources. If I'm mistaken, please post a URL.
By comparison, papers on Reno, Vegas, Westwood, BicTCP, not to mention
just about every other contribution to the field of open Internet
protocols has been readily available on the net since the birth of FTP
servers.
--
Mathematics is the supreme nostalgia of our time.
> On Tue, 22 Feb 2005 10:14:47 -0800, David S. Miller <[email protected]> wrote:
>
>>> On Tue, 22 Feb 2005 13:03:11 -0500 (EST)
>>> John Heffner <[email protected]> wrote:
>>>
>>
>>>> > An idea I've been toying with for a while now is completely abstracting
>>>> > congestion control. Then you could have congestion control loadable
>>>> > modules, which would avoid this mess of experimental algorithms inside the
>>>> > main-line kernel. If done right, they might be able to work seamlessly
>>>> > with SCTP, too. The tricky part is making sure the interface is complete
>>>> > enough.
There might be a noticeable performance impact to making it truly
modular. Calling a function in a module is slower. In some tests, I see
a 5 to 10% drop in performance when Ethernet driver is a module versus
builtin.
You might want to look at how the I/O schedulers are configured as an
example.
>>>
>>> The symbols exported to allow this would need to be EXPORT_SYMBOL_GPL().
>
>
> Why's that?
Because the kernel developers who hold the collective copyright on the
existing GPL TCP code do not want some vendor producing a closed source
binary module of "enhanced TCP".
On Tue, 22 Feb 2005 09:42:19 -0800
Stephen Hemminger <[email protected]> wrote:
> Probably the best long term solution is to make the protocol choice
> be a property of the destination cache
[..]
> 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
I think it should be nice if we substitute in the struct tcp_opt all the structs
related to the congestion control algorithms with a more generic one which could
be initialized when the connection is open by reading just one sysctl which defines
the algorithm to be used. This could allow later even a user-space application to
set the congestion control it desires to use.
> 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.
I perfectly agree.
--
Angelo Dell'Aera 'buffer'
Antifork Research, Inc. http://buffer.antifork.org
Metro Olografix
On Wednesday 23 February 2005 05:00, Matt Mackall wrote:
> It's disappointing that this paper appears to be available only
> through subscription sources. If I'm mistaken, please post a URL.
>
The authors are making a webpage with info and documentation.
I suppose that article you are referring has been published, then rights
go with the editor.
--
Daniele Lacamera
root at danielinux.net