From owner-freebsd-isp Mon Apr 6 14:47:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA19001 for freebsd-isp-outgoing; Mon, 6 Apr 1998 14:47:17 -0700 (PDT) (envelope-from owner-freebsd-isp@FreeBSD.ORG) Received: from biggusdiskus.flyingfox.com (biggusdiskus.flyingfox.com [205.162.1.28]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA18996 for ; Mon, 6 Apr 1998 14:47:16 -0700 (PDT) (envelope-from jas@flyingfox.com) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.5/8.8.5) id OAA02358; Mon, 6 Apr 1998 14:46:21 -0700 (PDT) Date: Mon, 6 Apr 1998 14:46:21 -0700 (PDT) From: Jim Shankland Message-Id: <199804062146.OAA02358@biggusdiskus.flyingfox.com> To: Anthony.Barlow@europe.simoco.com, chrism@keyworld.net, freebsd-isp@FreeBSD.ORG, freebsd@plinet.com Subject: Re: Bandwidth limiter for services? Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Christopher Martin at Home" writes: [Re: ET's bandwidth limiter] > I suggest that you check it out though. I think it works by dropping > packets. If it does the pipe might be filled by stuff that is already > downloaded. This might result in unaccepttable amount of retransmissions > from source. > > So you would not be really saving bandwidth... I'm sure Dennis will be heard from, and will bring his customary diplomatic balm to bear on this matter, but: note that this is no different from what happens when packets leave your 10- or 100-Megabit-connected workstation and are routed over a T-1 or slower WAN line. TCP already deals with this, using slow start, congestion avoidance, etc. to deduce the amount of bandwidth actually available to it, and throttle itself back accordingly. Your notion that a bandwidth limiter like ET's will cause increased retransmissions is unfounded. Jim Shankland Flying Fox Computer Systems, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message