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

[Patrick McHardy <kaber@trash.net>]

Glen Turner wrote:
> 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.

The difference is that TCPMSS changes packet data (also for
forwarded packets) and doesn't fiddle around with sockets.

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

It still strikes me as a bit of a hack. Lets see what Stephen
thinks.