From owner-freebsd-net Wed Apr 18 7:44:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id D66A637B424 for ; Wed, 18 Apr 2001 07:44:37 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f3IEh9X09002; Wed, 18 Apr 2001 09:43:09 -0500 (CDT) (envelope-from jlemon) Date: Wed, 18 Apr 2001 09:43:09 -0500 (CDT) From: Jonathan Lemon Message-Id: <200104181443.f3IEh9X09002@prism.flugsvamp.com> To: gurtov@cs.Helsinki.FI, net@freebsd.org Subject: Re: initial congestion window X-Newsgroups: local.mail.freebsd-net In-Reply-To: References: Organization: Cc: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Actually, you could argue that both should be changed to 2-3 segments, see http://www.aciri.org/floyd/tcp_init_win.html -- Jonathan In article you write: > >If there are no strong opinions supporting this feature, should we then >ask the developers to set the default inital window to two segments when >talking to local IPs? It would help to keep the image of FreeBSD as a >'conformant system' with regard to TCP specs. > >rgds, >Andrei > >On Wed, 18 Apr 2001, Luigi Rizzo wrote: > >> Hi, >> yes, FreeBSD is blasting the full socket buffer onto the net >> when the destination is "local". >> I think it was introduced when the T/TCP changes were committed, >> it kind-of makes sense with T/TCP, but other than that >> it is a very bad idea to have it on by default. >> For one, in many nets including a 100/10 switch, or slow receivers, >> it tends to cause an immediate loss on the first window of data >> because of the overload at the switch or the receiver. >> >> cheers >> luigi >> >> > >> > Hi folks, >> > >> > At the last IETF meeting there were some debates around FreeBSD using a >> > 16-KB initial congestion window in TCP when destination IP address is from >> > the local subnet. Does anybody remember when it was introduced into the >> > code and what kind of ideas were behind? >> > >> > Some reasons were given why it may not be a good idea: >> > >> > -the benefit of not having slow start on LANs is very small, i.e. some >> > milliseconds >> > >> > -it is not a conformant TCP feature, i.e. not allowed by TCP Congestion >> > Control (RFC2581) and is explicitly given in Known TCP Implementation >> > Problems (RFC2525) "2.1 No initial slow start" and "2.3 Uninitialized >> > CWND" >> > >> > -people may have the same subnet mask also over a slow PPP link. In this >> > case the effect of the huge initial window is quite bad, see for example >> > >http://www.cs.Helsinki.FI/u/gurtov/papers/effect_of_delays_on_tcp_performance.pdf >> > >> > -in case of congestion on Ethernet, packets queues build up at the >> > network interfaces in hosts and agressive TCP start-up behaviour can >> > further increase congestion losses >> > >> > What are your thoughts on this? >> > >> > Andrei >> > >> > tcp_output.c: >> > >> > int ss_fltsz = 1; >> > SYSCTL_INT(_net_inet_tcp, OID_AUTO, slowstart_flightsize, CTLFLAG_RW, >> > &ss_fltsz, 1, "Slow start flight size"); >> > >> > int ss_fltsz_local = TCP_MAXWIN; /* something large */ >> > SYSCTL_INT(_net_inet_tcp, OID_AUTO, local_slowstart_flightsize, >> > CTLFLAG_RW, >> > &ss_fltsz_local, 1, "Slow start flight size for local networks"); >> > >> > [...] >> > if ( >> > in_localaddr(tp->t_inpcb->inp_faddr) >> > ) >> > tp->snd_cwnd = tp->t_maxseg * ss_fltsz_local; >> > else >> > tp->snd_cwnd = tp->t_maxseg * ss_fltsz; >> > >> > >> > >> > >> > To Unsubscribe: send mail to majordomo@FreeBSD.org >> > with "unsubscribe freebsd-net" in the body of the message >> > >> > >Andrei > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message