Re: [PATCH] Add TCPCONG target to patch-o-matic

[Glen Turner <glen.turner@aarnet.edu.au>]

Patrick McHardy wrote:

> I don't think iptables is the right place to do this. It should
> be controllable through routing IMO (which can already control
> some aspects of congestion control).

I too think the choice should usually be done through routing,
with the route holding the preferred congestion control algorithm
for traffic with that prefix. Whereas now the preferred algorithm
is read from a global parameter.

But the algorithm for a particular connection should still be
able to be changed through iptables.

Firstly, not every application can be easily altered to use
setsockopt() to select a differing algorithm from the default.
This is the argument used for the TCPMSS and similar targets.
As the range of congestion control algorithms grows sysadmins
will want to choose differing algorithms for differing
applications. For example, most algorithm's Ack strategies
interact poorly with transactional and remote procedure call
traffic, so choosing an algorithm which handles this well
could make, say, NFS over TCP traffic run a lot faster.

Secondly, I want to make it easy for kernel and protocol
developers to run differing algorithms on differing port
numbers to test inter-algorithm fairness.  Some TCP algorithms
are quite unfair -- unable even to share a link 50:50 between
two identical flows started a few seconds apart.  A TCPCONG
target makes it much easier to do this testing. Now that the
kernel developers are getting good performance on long fat
pipes the fairness and other attributes of that performance
will be their next concern.

Hope this helps,
Glen

-- 
  Glen Turner         Tel: (08) 8303 3936 or +61 8 8303 3936
  Australia's Academic & Research Network  www.aarnet.edu.au