* dynamic TCP algorithms switching
@ 2013-11-22 22:49 yan cui
2013-11-22 22:56 ` Stephen Hemminger
0 siblings, 1 reply; 6+ messages in thread
From: yan cui @ 2013-11-22 22:49 UTC (permalink / raw)
To: netdev, linux-net
Hi all:
Currently, Linux has kinds of TCP congestion algorithms, such as
reno, cubic, bic, hybla, ...., and each TCP congestion algorithm has
its target networking environment. I just wonder to know is it
possible to do dynamic TCP algorithm switching? In other words, the
system has a combined TCP congestion algorithm (say, TCP-auto), and it
behaves like one of the integrated TCP congestion algorithms according
to different detected networking environment, but can switch to a
different one. For example, TCP-auto totally uses the set of
congestion control operations in TCP-cubic by default, but when it
detects that the current OS uses wireless networking, it switches to
some wireless friendly TCP congestion algorithm. Does Linux have some
features like that, or do you (networking developers and users) care
about it?
Best Wishes!
--
Think big; Dream impossible; Make it happen.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: dynamic TCP algorithms switching
2013-11-22 22:49 dynamic TCP algorithms switching yan cui
@ 2013-11-22 22:56 ` Stephen Hemminger
2013-11-22 23:21 ` yan cui
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Hemminger @ 2013-11-22 22:56 UTC (permalink / raw)
To: yan cui; +Cc: netdev, linux-net
On Fri, 22 Nov 2013 17:49:58 -0500
yan cui <ccuiyyan@gmail.com> wrote:
> Hi all:
>
> Currently, Linux has kinds of TCP congestion algorithms, such as
> reno, cubic, bic, hybla, ...., and each TCP congestion algorithm has
> its target networking environment. I just wonder to know is it
> possible to do dynamic TCP algorithm switching? In other words, the
> system has a combined TCP congestion algorithm (say, TCP-auto), and it
> behaves like one of the integrated TCP congestion algorithms according
> to different detected networking environment, but can switch to a
> different one. For example, TCP-auto totally uses the set of
> congestion control operations in TCP-cubic by default, but when it
> detects that the current OS uses wireless networking, it switches to
> some wireless friendly TCP congestion algorithm. Does Linux have some
> features like that, or do you (networking developers and users) care
> about it?
>
> Best Wishes!
>
You overestimate the advantage of one verus the other.
It is possible to control algorithm on per-socket, and per-route
but other than benchmarking there or bulk transfer for normal net
traffic Cubic works fine for all environments.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: dynamic TCP algorithms switching
2013-11-22 22:56 ` Stephen Hemminger
@ 2013-11-22 23:21 ` yan cui
2013-11-22 23:53 ` Stephen Hemminger
0 siblings, 1 reply; 6+ messages in thread
From: yan cui @ 2013-11-22 23:21 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, linux-net
Then, why include so many (current Linux has 10+ TCP congestion algorithms)
algorithms? For users who want to deploy their application on Linux
and if the applications
are system resource intensive, they always want to tune the
configurations of the operating systems for the last piece of
performance. If they do so, maybe they are confused
about which TCP congestion algorithm to use for their environment. So,
the only way is to try each algorithm one by one. I understand the
setting of the default TCP congestion
algorithm to be Cubic means that it works well for most environments.
But if others
are seldom used, or can be replace with another implementation.
Why not just remove from the kernel?
Yan
2013/11/22 Stephen Hemminger <stephen@networkplumber.org>:
> On Fri, 22 Nov 2013 17:49:58 -0500
> yan cui <ccuiyyan@gmail.com> wrote:
>
>> Hi all:
>>
>> Currently, Linux has kinds of TCP congestion algorithms, such as
>> reno, cubic, bic, hybla, ...., and each TCP congestion algorithm has
>> its target networking environment. I just wonder to know is it
>> possible to do dynamic TCP algorithm switching? In other words, the
>> system has a combined TCP congestion algorithm (say, TCP-auto), and it
>> behaves like one of the integrated TCP congestion algorithms according
>> to different detected networking environment, but can switch to a
>> different one. For example, TCP-auto totally uses the set of
>> congestion control operations in TCP-cubic by default, but when it
>> detects that the current OS uses wireless networking, it switches to
>> some wireless friendly TCP congestion algorithm. Does Linux have some
>> features like that, or do you (networking developers and users) care
>> about it?
>>
>> Best Wishes!
>>
>
> You overestimate the advantage of one verus the other.
> It is possible to control algorithm on per-socket, and per-route
> but other than benchmarking there or bulk transfer for normal net
> traffic Cubic works fine for all environments.
--
Think big; Dream impossible; Make it happen.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: dynamic TCP algorithms switching
2013-11-22 23:21 ` yan cui
@ 2013-11-22 23:53 ` Stephen Hemminger
2013-11-23 3:56 ` yan cui
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Hemminger @ 2013-11-22 23:53 UTC (permalink / raw)
To: yan cui; +Cc: netdev, linux-net
On Fri, 22 Nov 2013 18:21:12 -0500
yan cui <ccuiyyan@gmail.com> wrote:
> Then, why include so many (current Linux has 10+ TCP congestion algorithms)
> algorithms? For users who want to deploy their application on Linux
> and if the applications
> are system resource intensive, they always want to tune the
> configurations of the operating systems for the last piece of
> performance. If they do so, maybe they are confused
> about which TCP congestion algorithm to use for their environment. So,
> the only way is to try each algorithm one by one. I understand the
> setting of the default TCP congestion
> algorithm to be Cubic means that it works well for most environments.
> But if others
> are seldom used, or can be replace with another implementation.
> Why not just remove from the kernel?
>
> Yan
Most are intended for research and testing only.
Only a few are worth considering in a production environment.
That is also why there so many qdisc algorithms as well.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: dynamic TCP algorithms switching
2013-11-22 23:53 ` Stephen Hemminger
@ 2013-11-23 3:56 ` yan cui
2013-11-24 0:42 ` Stephen Hemminger
0 siblings, 1 reply; 6+ messages in thread
From: yan cui @ 2013-11-23 3:56 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
Thanks for the quick reply!
Do you have the real-world workload results that demonstrate
that cubic has the best performance among all the available congestion
algorithms? If so, could you please post some?
Thanks, Yan
2013/11/22 Stephen Hemminger <stephen@networkplumber.org>:
> On Fri, 22 Nov 2013 18:21:12 -0500
> yan cui <ccuiyyan@gmail.com> wrote:
>
>> Then, why include so many (current Linux has 10+ TCP congestion algorithms)
>> algorithms? For users who want to deploy their application on Linux
>> and if the applications
>> are system resource intensive, they always want to tune the
>> configurations of the operating systems for the last piece of
>> performance. If they do so, maybe they are confused
>> about which TCP congestion algorithm to use for their environment. So,
>> the only way is to try each algorithm one by one. I understand the
>> setting of the default TCP congestion
>> algorithm to be Cubic means that it works well for most environments.
>> But if others
>> are seldom used, or can be replace with another implementation.
>> Why not just remove from the kernel?
>>
>> Yan
>
> Most are intended for research and testing only.
> Only a few are worth considering in a production environment.
> That is also why there so many qdisc algorithms as well.
>
--
Think big; Dream impossible; Make it happen.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: dynamic TCP algorithms switching
2013-11-23 3:56 ` yan cui
@ 2013-11-24 0:42 ` Stephen Hemminger
0 siblings, 0 replies; 6+ messages in thread
From: Stephen Hemminger @ 2013-11-24 0:42 UTC (permalink / raw)
To: yan cui; +Cc: netdev
On Fri, 22 Nov 2013 22:56:10 -0500
yan cui <ccuiyyan@gmail.com> wrote:
> Thanks for the quick reply!
> Do you have the real-world workload results that demonstrate
> that cubic has the best performance among all the available congestion
> algorithms? If so, could you please post some?
>
>
> Thanks, Yan
>
>
> 2013/11/22 Stephen Hemminger <stephen@networkplumber.org>:
> > On Fri, 22 Nov 2013 18:21:12 -0500
> > yan cui <ccuiyyan@gmail.com> wrote:
> >
> >> Then, why include so many (current Linux has 10+ TCP congestion algorithms)
> >> algorithms? For users who want to deploy their application on Linux
> >> and if the applications
> >> are system resource intensive, they always want to tune the
> >> configurations of the operating systems for the last piece of
> >> performance. If they do so, maybe they are confused
> >> about which TCP congestion algorithm to use for their environment. So,
> >> the only way is to try each algorithm one by one. I understand the
> >> setting of the default TCP congestion
> >> algorithm to be Cubic means that it works well for most environments.
> >> But if others
> >> are seldom used, or can be replace with another implementation.
> >> Why not just remove from the kernel?
> >>
> >> Yan
> >
> > Most are intended for research and testing only.
> > Only a few are worth considering in a production environment.
> > That is also why there so many qdisc algorithms as well.
> >
>
>
>
If you did a little searching around, you would find that there has been extensive
research in this area. http://netsrv.csc.ncsu.edu/wiki/index.php/TCP_Testing
is a good place to start.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-11-24 0:42 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-11-22 22:49 dynamic TCP algorithms switching yan cui
2013-11-22 22:56 ` Stephen Hemminger
2013-11-22 23:21 ` yan cui
2013-11-22 23:53 ` Stephen Hemminger
2013-11-23 3:56 ` yan cui
2013-11-24 0:42 ` Stephen Hemminger
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.