Date: Sun, 17 May 1998 12:33:08 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: pantzer@ludd.luth.se (Mattias Pantzare) Cc: dg@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: bad behaviour in slow start Message-ID: <199805171033.MAA05381@labinfo.iet.unipi.it> In-Reply-To: <199805171027.MAA26384@zed.ludd.luth.se> from "Mattias Pantzare" at May 17, 98 12:27:18 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > * Don't force slow-start on local network. > > >I think this is in violation of good TCP practices, and should be at ... > > When sending out to a local peer, ethernet and point-to-point devices will > > buffer the initial burst of packets with the local buffers draining at the > > speed of the available link bandwidth, so I don't see why you would want to This initial burst is a whole max-size window, so with the same reasoning we could bypass the congestion control algorithms when talking with peers a local network! > > do slow start in this case. This is different than the case of a congested > > upstream circuit where you don't know about the congestion and have no > > control over the buffering. > > The problem is that you can't detect if the other computer is a local peer or > not, there may be routers in the path to it even if the netmask tells you that > it is on the same subnet. It isn't even true on the ethernet level any more, > switches create the same problems as a router. especially in case of 10/100 switches. Actually one reason on a slow (ppp) link is that you might get a false timeout soon, just because your first 16-32K of data will take 10seconds to go through. You might even have real packet losses, i don't remember how long is the queue on a ppp/tun link but hopefully it is not the 50 slots used for ethernets, and people might want to use a small MTU like 576 to improve interactive response with background bulk traffic. I suppose a lot of people using a FreeBSD-based ppp server get an address which is on the same /24 net as the ethernet of the server. My point is, this optimization came in only to serve the needs of TTCP (and even in that case, it should have been enabled only when the peer was known to support TTCP). Then it became the default behaviour, possibly by mistake (at least, so i see it). We could ask confirmation Andres Olah who (I think) is the one who wrote this piece of code, if someone knows how to reach him! (I am cc-ing this msg to olah@freebsd.org just in case...) I think it really ought to be optional and default to off, so people can choose on their own, but knowing what they do. Given the "complexity" of the fix i posted yesterday, i don't think it's such a big deal. cheers luigi -----------------------------+-------------------------------------- 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/ _____________________________|______________________________________ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805171033.MAA05381>