From owner-freebsd-stable Sun Oct 29 17:26:30 2000 Delivered-To: freebsd-stable@freebsd.org Received: from ns.itga.com.au (ns.itga.com.au [202.53.40.210]) by hub.freebsd.org (Postfix) with ESMTP id AB41037B4FE for ; Sun, 29 Oct 2000 17:26:25 -0800 (PST) Received: from lightning.itga.com.au (lightning.itga.com.au [192.168.71.20]) by ns.itga.com.au (8.9.3/8.9.3) with ESMTP id MAA88051; Mon, 30 Oct 2000 12:26:18 +1100 (EST) (envelope-from gnb@itga.com.au) Received: from itga.com.au (lightning.itga.com.au [192.168.71.20]) by lightning.itga.com.au (8.9.3/8.9.3) with ESMTP id MAA23728; Mon, 30 Oct 2000 12:26:17 +1100 (EST) Message-Id: <200010300126.MAA23728@lightning.itga.com.au> X-Mailer: exmh version 2.0.1 12/23/97 From: Gregory Bond To: "Sam Zamarripa" Cc: freebsd-stable@FreeBSD.ORG Subject: Re: PPP Nat Bandwidth Sharing In-reply-to: Your message of Fri, 27 Oct 2000 20:30:15 -0700. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Oct 2000 12:26:16 +1100 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Bandwidth sharing doesn't seem to be too efficient. For example if Machine-1 > on the LAN is doing a major download of a compressed file and getting near > full speed of 5.6K/sec, if Machine-2 starts web browsing or a download > itself..they can barely pull 1K/sec. 2 comments: The bottleneck in these situations is in the incoming stream, not the outgoing stream, so the bandwith sharing needs to be implemented at the ISP. But of course the ISP doesn't know about NAT so has no basis for doing the sharing! Secondly, with a typical loaded 56k setup, there are several seconds of data queued up already so bandwidth sharing is not likely to be effective for a new request (i.e. browsing from Machine-2) until all the queued data has drained - which is too late to be useful. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message