Date: Fri, 14 Feb 1997 10:05:19 +0100 (MET) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: hackers@freebsd.org Subject: Re: to 4k_start or not to 4k_start? (fwd) Message-ID: <199702140905.KAA24821@labinfo.iet.unipi.it>
next in thread | raw e-mail | index | archive | help
Another interesting suggestion from David Borman, on the end2end list, about speeding up (short) TCP connections. Maybe David or Garret want to have a look at it. Luigi Forwarded message: > From majordom@ISI.EDU Fri Feb 14 00:14:17 1997 > Date: Thu, 13 Feb 1997 15:26:38 -0700 (MST) > From: David Borman <dab@BSDI.COM> > Message-Id: <199702132226.PAA28256@forge.BSDI.COM> > To: raj@hpisrdq.cup.hp.com, rstevens@kohala.com, shep@BBN.COM > Subject: Re: to 4k_start or not to 4k_start? > Cc: end2end-interest@ISI.EDU > Sender: owner-end2end-interest@ISI.EDU > Precedence: bulk > > Yes and no. I don't think that this was a specific "feature" in BSD, > but more of an accident. When I was working on some of the TCP > performance enhancements for BSD/OS 2.1 this summer (patch K210-019), > I dealt with this. What I discovered was that after completing the > 3-way handshake, the active side had a congestion window of 2*mss, and > the passive side had a congestion window of 1*mss. So, you would get > good initial throughput if the side doing the connect was pushing data > down the pipe, but if it was connecting and sucking down the data > (like most HTTP connections), then you'd get into the problem of only > sending one data packet, and then waiting for the other side to time > out the delayed ACK. I fixed BSD/OS so that now when either the SYN|ACK > or ACK arrives, when we are through processing it the congestion window > will be at 2*mss on both sides of the connection. This allows 2 packets > of data to be sent immediatly, and we get past the delayed ACK problem. > Note that you also need to change tcp_output(), so that on idle when > it resets the congestion window, that it sets it to 2*mss instead > of just 1*mss. > > I should point out that this isn't the only area that I made changes. > My goal was to make a short TCP connection (a few K of data) run fast, > without having any artifical delays (like delayed ACKs). > > Another solution is in the client. When the server side is most > likely doing slow start, immediatly ACK the first few data packets. > I implemented this in UNICOS by adding a new variable, call it > t_fastack, in the TCP control block. It is initially set to > seq + 8*MSS (don't ask why I chose 8, 2 probably would have been > just fine) As data comes in, if SEG.SEQ < t_fastack, it is immediatly > acked. As the connections continues, t_fastack is pulled along > as new data is acked. If the connection went idle for some amount > of time, then t_fastack was pushed ahead since the other side was > probably going to do slowstart. In tcp_input(): > */ > + if (tp->t_idle > IDLE_THRESHOLD) > + tp->t_fastack = tp->t_rcv_nxt + 8*tp->t_maxseg; > tp->t_idle = 0; > Anyway, the details aren't all there, but you get the picture. > > -David Borman, dab@bsdi.com -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702140905.KAA24821>