Re: Few comments on TCP implementation

Re: Few comments on TCP implementation

[David S. Miller]

   From: Yogesh Swami <spy9599@yahoo.com>
   Date: Fri, 24 May 2002 14:30:11 -0700 (PDT)
   
   c) There are numerous heuristics at work with no  RFC
   counterparts (rate halving etc etc). To have the best
   performance its probably best to stick with RFCs, or
   if there is a compelling need to have these heuristics
   then they should be brought to the IETF first.
   Implementing something based on someone's random
   publications is not a good idea for an operating as
   pervasive as Linux.

Wrong.  Half of the RFCs have flaws, and if we just would "stick to
RFCs" we'd have a lot of problems.  Most of things Linux does
different are just fixes for these errors in the RFCs.

Re: Few comments on TCP implementation

[David S. Miller]

   From: "David S. Miller" <davem@redhat.com>
   Date: Fri, 24 May 2002 14:20:09 -0700 (PDT)

      Implementing something based on someone's random
      publications is not a good idea for an operating as
      pervasive as Linux.

And to make my point even more clear, most of the algorithms we have
adopted were adopted based upon real testing done in real life
environments.

Take a good hard look at any other OS you think is "pervasive" and I
guarentee you they implement things like rate halving and the various
SACK algorithms.

Few comments on TCP implementation

[Yogesh Swami]

Hi,

I have some questions and comments about the TCP
implementation: 

a) The calculation of ssthresh is wrong, it should be
max( 1/2*packets_in_flight, 2) (see RFC 2581) and not
as shown below in net/tcp.h. Unfortunately the way
packets in flight is calculated is based on
heuristics, so the only sensible thing to do would be
to set to max( 1/2*packets_out, 2*MSS). This small
change can have a big impact in some cases.

-------- include/net/tcp.h:1098

/* Recalculate snd_ssthresh, we want to set it to:
 *
 * 	one half the current congestion window, but no
 *	less than two segments
 */
static inline __u32 tcp_recalc_ssthresh(struct tcp_opt
*tp)
{
	return max(tp->snd_cwnd >> 1U, 2U);
}
-------

b) After a retransmission timeout, all the SACK
information SHOULD be forgotten (see RFC 2018).
Implementation in the kernel does not follow this but
relies on SACK reneging. This should be changed to
what the RFC has to say--again a small change to be
made.

c) There are numerous heuristics at work with no  RFC
counterparts (rate halving etc etc). To have the best
performance its probably best to stick with RFCs, or
if there is a compelling need to have these heuristics
then they should be brought to the IETF first.
Implementing something based on someone's random
publications is not a good idea for an operating as
pervasive as Linux.

c) A few new RFCs have come recently (e.g., 3042
called limited retransmit) that boost the performance
of short lived connections ( e.g., HTTP
request-response) and probably it will be a good idea
to incorporate then in the kernel (barely takes a
couple of lines to implement). If no one else is
already working on it, maybe I can assist.

Please let me know what you think.

Thanks
BR
Yogesh

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

Re: Few comments on TCP implementation

[kuznet]

Hello!

> a) The calculation of ssthresh is wrong, it should be
> max( 1/2*packets_in_flight, 2) (see RFC 2581)

The value called In_Flight in the rfc is called snd_cwnd here.
Look f.e. into rfc2861 for further details.

> b) After a retransmission timeout, all the SACK
> information SHOULD be forgotten (see RFC 2018).

If you think a little you will understand that this does not matter.
Delayed SACK invalidation is just much more stable wrt various pathologies.


> c) A few new RFCs have come recently (e.g., 3042
> called limited retransmit) that boost the performance

It is implemented. :-)

Alexey