On 10/27/06, David Miller <[EMAIL PROTECTED]> wrote:
From: "Ian McDonald" <[EMAIL PROTECTED]>
Date: Fri, 27 Oct 2006 12:59:30 +1300
> I don't agree with this at all. I would love Firefox, BitTorrent etc
> to implement usage of TCP-LP for example so they use "unused"
> bandwidth only.
>
> With this change applications can't do this.
>
> If we are going to restrict by capabilities then I think we should
> only restrict module loading - this way the admin of the box can
> decide what algorithms can be used.
You are using an example of a (supposedly) safe case of this
as a justification for allowing all cases.
It is bad, very bad, to allow arbitrary users to select arbitrary
congestion control algorithms. It is just as bad as allowing them to
disable congestion control completely if that were an option.
OK understand your point here but I think low priority TCP has its
use. Don't agree it is just as bad, but it is bad under the wrong
circumstances - it's still better than UDP which has no congestion
control...
Don't want to make it over complicated though.
I think the most sense would be to restrict it as shown as tcp-lp is
the exception and allow tcp-lp via another mechanism. That is a
situation where the user could specify how low priority they want the
traffic to be... If I ever get enough time I'll have a go at it but
can't see it this year :-(
It actually makes more sense to tie the congestion control algorithm
to the route/destination IP if we are going to change it but that is a
whole another exercise in itself.
If someone, for example, builds all the algorithms statically into
their kernel, for testing as root, this lets all users on the machine
do the same which is not right.
This is the state at present as I understand it. However that doesn't
make it right.
--
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
