Linux TCP implementation

Linux TCP implementation

[Diwaker Gupta]

Maybe this question has already been burnt to death, but I wasn't able 
to find an answer on the archives or on the FAQ. So here goes:

I was just reading about the various TCP implementation -- Reno, Tahoe 
and Vegas in particular -- and I was wondering about the TCP 
implementation in Linux. AFAIK (and from looking at the source code), it 
seems current kernels are using a tweaked version of Reno. I'm also 
aware that at some point of time (2.1.x?) Vegas was introduced into the 
mainstream kernels, but then withdrawn.

I want to gather the LKML readers' thoughts on this -- to me it seems 
that TCP Vegas in superior to Reno in almost all ways, and will really 
help to bring down network congestion substantially if a large number of 
senders begin to use it (read "if introduced in the mainstream kernel"). 
The question then is, why is TCP Vegas not here yet? And are there any 
plans to incorporate it in the future?

-- 
Diwaker Gupta
Graduate Student, Computer Sc. and Engg.
University of California, San Diego
<http://www.cs.ucsd.edu/~dgupta>

Re: Linux TCP implementation

[Maciej Soltysiak]

> And are there any plans to incorporate it in the future?

There was an aproach to get vegas into 2.6.
http://lwn.net/Articles/53133/

http://developer.osdl.org/shemminger/netx/2.6/2.6.0-test7/2.6.0-test7-netx2/

I do not know the status of this.
I remember this patch on lkml but do not remember any feedback regarding
it.

Regards,
Maciej

Re: Linux TCP implementation

[Stephen Hemminger]

On Wed, 18 Feb 2004 20:12:31 +0100
"Maciej Soltysiak" <solt@dns.toxicfilms.tv> wrote:

> > And are there any plans to incorporate it in the future?
> 
> There was an aproach to get vegas into 2.6.
> http://lwn.net/Articles/53133/
> 
> http://developer.osdl.org/shemminger/netx/2.6/2.6.0-test7/2.6.0-test7-netx2/
> 
> I do not know the status of this.
> I remember this patch on lkml but do not remember any feedback regarding
> it.

The patch originated from Dave Miller.  It probably won't apply now because of
the recent TCP westwood addition (it is on my fix list).  But there was something
wrong the patch, and it never managed the expanded congestion window properly.

Linux TCP implementation

[m k]

Hello:

      I am working with 2.4.21 kernel for iSCSI performance study. I have a 
question
regarding the congestion avoidance algorithm used in the linux TCP 
implementation.
After dumping the value of the snd_cwnd, snd_ssthresh and snd_cwnd_clamp 
when
the tcp_cong_avoid function is called, I observed that the value of 
snd_ssthresh
was always set to a value of 2147483647 and the value of snd_cwnd_clamp was 
set to 65535.
If the snd_cwnd is not be more than the snd_cwnd_clamp, the else part of the
function is never executed, as snd_cwnd is never going to be more than 
snd_ssthresh.
	Also, if the snd_cwnd is maintained in terms of packets and snd_ssthresh 
and
snd_cwnd_clamp is maintained in terms of bytes, how come the comparison 
between them.


static __inline__ void tcp_cong_avoid(struct tcp_opt *tp)
{
         if (tp->snd_cwnd <= tp->snd_ssthresh) {
                 /* In "safe" area, increase. */
                 if (tp->snd_cwnd < tp->snd_cwnd_clamp)
                         tp->snd_cwnd++;
         } else {
                 /* In dangerous area, increase slowly.
                  * In theory this is tp->snd_cwnd += 1 / tp->snd_cwnd
                  */
                 if (tp->snd_cwnd_cnt >= tp->snd_cwnd) {
                         if (tp->snd_cwnd < tp->snd_cwnd_clamp)
                                 tp->snd_cwnd++;
                         tp->snd_cwnd_cnt=0;
                 } else
                         tp->snd_cwnd_cnt++;
         }
         tp->snd_cwnd_stamp = tcp_time_stamp;
}

var/log/messages:
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 2, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 3, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 4, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 5, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 6, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 7, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 8, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 9, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 10, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 11, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 12, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 13, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 14, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 15, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 16, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 17, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 18, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 19, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 20, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 21, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535
Mar 22 15:08:20 jupiter kernel: snd_cwnd: 22, snd_ssthresh: 2147483647, 
snd_cwnd_clamp: 65535


Any insight on this topic would be appreciated.

Thanks,
k

_________________________________________________________________
Get rid of annoying pop-up ads with the new MSN Toolbar – FREE! 
http://clk.atdmt.com/AVE/go/onm00200414ave/direct/01/

Re: Linux TCP implementation

[David S. Miller]

[ Post stuff like this to netdev@oss.sgi.com or linux-net@vger.kernel.org,
  most net developers do not read linux-kernel, thanks. ]

On Mon, 22 Mar 2004 20:58:46 +0000
"m k" <mk_26@hotmail.com> wrote:

> 	Also, if the snd_cwnd is maintained in terms of packets and snd_ssthresh 
> and
> snd_cwnd_clamp is maintained in terms of bytes, how come the comparison 
> between them.

All of the congestion variables are maintained in terms of packets.

The function you quote, tcp_cong_avoid(), determines if we increase
the congestion window exponentially (when snd_cwnd is less than or
equal to snd_ssthresh) or linearlly (when snd_cwnd is more than
snd_ssthresh).

This is bog-standard Van Jacobson congestion avoidance, nothing fancy.