* Long-term TCP connections suffer on high-latency links.
@ 2004-07-30 5:01 Ben Greear
2004-07-30 5:28 ` Cheng Jin
0 siblings, 1 reply; 5+ messages in thread
From: Ben Greear @ 2004-07-30 5:01 UTC (permalink / raw)
To: 'netdev@oss.sgi.com'
I have been running a TCP connection over a link with 2 seconds round-trip-time.
It started off well, about 16Mbps in both directions (cwnd trained up to 2100
after a few seconds).
After several hours of running, it is now doing only about 2.2Mbps in one
direction, and 3.4Mbps in the other direction. I have watched the cwnd slowly
increasing by one every 2-5 seconds (it is at 440 on one side and 655 on the
other as I type).
Occasionally, the cwnd drops in half or maybe even goes to zero.
The un-acked packets is always == snd_cwnd.
My suspicion is that for connections needing a cwnd of 2000 or so,
the cwnd does not grow nearly fast enough after the connection
has been established for a while. My naive suggestion would be to
increase cwnd by a certain percentage instead of a fixed number (1).
But, TCP has been around a long while, and surely other people
have noticed things like this, so what am I missing?
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Long-term TCP connections suffer on high-latency links.
2004-07-30 5:01 Long-term TCP connections suffer on high-latency links Ben Greear
@ 2004-07-30 5:28 ` Cheng Jin
2004-07-30 6:25 ` Ben Greear
0 siblings, 1 reply; 5+ messages in thread
From: Cheng Jin @ 2004-07-30 5:28 UTC (permalink / raw)
To: Ben Greear; +Cc: 'netdev@oss.sgi.com'
Ben,
> But, TCP has been around a long while, and surely other people
> have noticed things like this, so what am I missing?
There are a number of research groups working on addressing the inefficiencies
of the current TCP (NewReno) at large windows in both theory and
experimental work.
The experimental work would probably be more interesting for this mailing
list. The protocols (that I know) that try to address this issue are:
Highspeed TCP: http://www.icir.org/floyd/hstcp.html
Scalable TCP: http://www-lce.eng.cam.ac.uk/~ctk21/scalable/
FAST TCP: http://netlab.caltech.edu/FAST
H-TCP: http://hamilton.ie/net/main.htm?index
BIC TCP/CUBIC: http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/
a related project for finding performance bottlenecks in the network stack
is web100: http://www.web100.org
As of 2.6.6 kernel, TCP Westwood, which mainly addresses issues in
wireless networks, BIC TCP, and TCP Vegas are all included besides TCP
NewReno, although not enabled by default. The others can be downloaded
from the given websites. There are probably others that I forgot to
mention. Apologies to them in advance.
Making the current TCP more ``efficient'' by increasing cwnd faster is not
an adequate solution, although doing that will likely produce higher
throughput in today's Internet. We also must consider issues such as
fairness to other flows, stability of the network in terms of queue
oscillation and packet loss, and how well these solutions would scale in
future networks. A lot of experiments are still needed to determine which
is the most appropriate under what circumstances.
Cheng
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Long-term TCP connections suffer on high-latency links.
2004-07-30 5:28 ` Cheng Jin
@ 2004-07-30 6:25 ` Ben Greear
2004-07-30 7:34 ` Baruch Even
2004-07-30 16:16 ` Stephen Hemminger
0 siblings, 2 replies; 5+ messages in thread
From: Ben Greear @ 2004-07-30 6:25 UTC (permalink / raw)
To: Cheng Jin; +Cc: 'netdev@oss.sgi.com'
Cheng Jin wrote:
> As of 2.6.6 kernel, TCP Westwood, which mainly addresses issues in
> wireless networks, BIC TCP, and TCP Vegas are all included besides TCP
> NewReno, although not enabled by default. The others can be downloaded
> from the given websites. There are probably others that I forgot to
> mention. Apologies to them in advance.
Any chance Westwood will get into the 2.4 kernel as well?
> Making the current TCP more ``efficient'' by increasing cwnd faster is not
> an adequate solution, although doing that will likely produce higher
> throughput in today's Internet. We also must consider issues such as
> fairness to other flows, stability of the network in terms of queue
> oscillation and packet loss, and how well these solutions would scale in
> future networks. A lot of experiments are still needed to determine which
> is the most appropriate under what circumstances.
Both of the two that I read about (Highspeed TCP and FAST tcp)
did indeed increase the cwnd faster, unless I mis-understood
the papers. Granted they do it in clever ways...
Thanks for the links.
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Long-term TCP connections suffer on high-latency links.
2004-07-30 6:25 ` Ben Greear
@ 2004-07-30 7:34 ` Baruch Even
2004-07-30 16:16 ` Stephen Hemminger
1 sibling, 0 replies; 5+ messages in thread
From: Baruch Even @ 2004-07-30 7:34 UTC (permalink / raw)
To: Ben Greear; +Cc: Cheng Jin, 'netdev@oss.sgi.com'
* Ben Greear <greearb@candelatech.com> [040730 09:25]:
> Cheng Jin wrote:
>
> >As of 2.6.6 kernel, TCP Westwood, which mainly addresses issues in
> >wireless networks, BIC TCP, and TCP Vegas are all included besides TCP
> >NewReno, although not enabled by default. The others can be downloaded
> >from the given websites. There are probably others that I forgot to
> >mention. Apologies to them in advance.
>
> Any chance Westwood will get into the 2.4 kernel as well?
>
> >Making the current TCP more ``efficient'' by increasing cwnd faster is not
> >an adequate solution, although doing that will likely produce higher
> >throughput in today's Internet. We also must consider issues such as
> >fairness to other flows, stability of the network in terms of queue
> >oscillation and packet loss, and how well these solutions would scale in
> >future networks. A lot of experiments are still needed to determine which
> >is the most appropriate under what circumstances.
>
> Both of the two that I read about (Highspeed TCP and FAST tcp)
> did indeed increase the cwnd faster, unless I mis-understood
> the papers. Granted they do it in clever ways...
At least H-TCP does increase the alpha parameter to increase the rate
of change, but it also changes the beta parameter in accordance with the
alpha, this is done to maintain fairness and the other good values we
want to promote.
You can find the patches for Linux 2.4.23 on the Hamilton website at:
http://hamilton.ie/net/main.htm?index
The parameters are changed in a mode-switch method so that H-TCP will
work together with TCP and will work also on low Bandwidth Delay Product
networks.
Baruch
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Long-term TCP connections suffer on high-latency links.
2004-07-30 6:25 ` Ben Greear
2004-07-30 7:34 ` Baruch Even
@ 2004-07-30 16:16 ` Stephen Hemminger
1 sibling, 0 replies; 5+ messages in thread
From: Stephen Hemminger @ 2004-07-30 16:16 UTC (permalink / raw)
To: Ben Greear; +Cc: Cheng Jin, 'netdev@oss.sgi.com'
On Thu, 29 Jul 2004 23:25:36 -0700
Ben Greear <greearb@candelatech.com> wrote:
> Cheng Jin wrote:
>
> > As of 2.6.6 kernel, TCP Westwood, which mainly addresses issues in
> > wireless networks, BIC TCP, and TCP Vegas are all included besides TCP
> > NewReno, although not enabled by default. The others can be downloaded
> > from the given websites. There are probably others that I forgot to
> > mention. Apologies to them in advance.
>
> Any chance Westwood will get into the 2.4 kernel as well?
Both BIC and westwood are in 2.4 now.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-07-30 16:16 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-07-30 5:01 Long-term TCP connections suffer on high-latency links Ben Greear
2004-07-30 5:28 ` Cheng Jin
2004-07-30 6:25 ` Ben Greear
2004-07-30 7:34 ` Baruch Even
2004-07-30 16:16 ` Stephen Hemminger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).