From owner-freebsd-net  Sat Nov 13  6:31:13 1999
Delivered-To: freebsd-net@freebsd.org
Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184])
	by hub.freebsd.org (Postfix) with ESMTP
	id 32508150FE; Sat, 13 Nov 1999 06:31:02 -0800 (PST)
	(envelope-from luigi@info.iet.unipi.it)
Received: (from luigi@localhost)
	by info.iet.unipi.it (8.9.2/8.9.2) id PAA12855;
	Sat, 13 Nov 1999 15:31:24 +0100 (CET)
	(envelope-from luigi)
From: Luigi Rizzo <luigi@info.iet.unipi.it>
Message-Id: <199911131431.PAA12855@info.iet.unipi.it>
Subject: Re: FreeBSD networking problems
In-Reply-To: <199911121642.KAA29642@cs.rice.edu> from Mohit Aron at "Nov 12, 1999 10:42: 7 am"
To: aron@cs.rice.edu (Mohit Aron)
Date: Sat, 13 Nov 1999 15:31:23 +0100 (CET)
Cc: freebsd-net@FreeBSD.ORG, wollman@FreeBSD.ORG, jlemon@FreeBSD.ORG,
	julian@FreeBSD.ORG, bright@wintelcom.net
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

> > i think the two of us already discussed this. I don't think this is a
> > particularly good idea, especially:
> 
> Well, 50 is too small. I needed 1000 for my WAN experiments, but the number

what you are saying is "i can blast packets to the interface faster
than it can drain them". Which means that you are causing _congestion_
on the local interface rather than somewhere in the
middle of the net (and, your burst of 1000 packets might as well go
to your next-hop router where you probably won't have as much queue
space for your flows).

You don't solve the problem by raising the queue to 1000, because
in one year your gigahertz processor will need a queue of 2000, and so
on. You solve the problem by noticing that you are pumping data too
fast (ip_output fails, so you do know) and pacing the output appropriately.

> As you said, the 833 packets need to be stored somewhere and you're also 
> right that the place is the socket buffer queue. But TCP can be bursty 
> during its operating specially when it gets big ACKs (or closely spaced ACKs

so, fix TCP, the problem is there, not elsewhere (possible fix,
not terribly complex:  on overflow don't cut the window as done
now, just schedule a call to the output loop after 1/HZ seconds).

	cheers
	luigi
-----------------------------------+-------------------------------------
  Luigi RIZZO, luigi@iet.unipi.it  . Dip. di Ing. dell'Informazione
  http://www.iet.unipi.it/~luigi/  . Universita` di Pisa
  TEL/FAX: +39-050-568.533/522     . via Diotisalvi 2, 56126 PISA (Italy)

		  http://www.iet.unipi.it/~luigi/ngc99/
====  First International Workshop on Networked Group Communication  ====
-----------------------------------+-------------------------------------


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message