From owner-freebsd-stable Sun Nov 5 13:18:56 2000 Delivered-To: freebsd-stable@freebsd.org Received: from alcanet.com.au (unknown [203.62.196.10]) by hub.freebsd.org (Postfix) with SMTP id 4CE2C37B4CF for ; Sun, 5 Nov 2000 13:18:50 -0800 (PST) Received: by border.alcanet.com.au id <115209>; Mon, 6 Nov 2000 09:18:08 +1100 Content-return: prohibited Date: Mon, 06 Nov 2000 08:18:40 +1100 From: Peter Jeremy Subject: Re: PPP Nat Bandwidth Sharing To: Sam Zamarripa Cc: Gregory Bond , freebsd-stable@FreeBSD.ORG Mail-followup-to: Sam Zamarripa , Gregory Bond , freebsd-stable@FreeBSD.ORG Message-Id: <00Nov6.091808est.115209@border.alcanet.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, Oct 30, 2000 at 12:26:16PM +1100, Gregory Bond wrote: >> 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. ... >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. Actually, you do have some control over this. net.inet.tcp.recvspace controls the TCP receive window size advertised by your machine. Reducing this will reduce the amount of TCP data queued between the TCP connection end-points. There are several caveats: 1) It has no effect on UDP, ICMP etc 2) It limits the queue size for each TCP connection rather than your total queue size at the ISP. This reduces its effectiveness if there are lots of TCP connections, but if you are just trying to browse in one window whilst waiting for an FTP in another, it's quite effective. 3) It has to be set in the end-point machine, not the firewall/NAT box[1] 4) It affects all network connections to the machine 5) TCP connection bandwidth is limited to (roughly) windowsize/RTT, so the value is a tradeoff between responsiveness and bandwidth to distant sites. 6) Points 3-5 mean LAN performance may be reduced slightly. [1] Actually, if you wanted to be really creative, you could probably doctor the NAT code to also reduce the advertised window size. The code to do this is left as an exercise for the reader. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message