From owner-freebsd-hackers  Wed Nov  6 10:34:31 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id KAA00424
          for hackers-outgoing; Wed, 6 Nov 1996 10:34:31 -0800 (PST)
Received: from who.cdrom.com (who.cdrom.com [204.216.27.3])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA00390
          for <hackers@freebsd.org>; Wed, 6 Nov 1996 10:34:28 -0800 (PST)
Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160])
          by who.cdrom.com (8.7.5/8.6.11) with ESMTP id KAA14075
          for <hackers@FreeBSD.org>; Wed, 6 Nov 1996 10:34:04 -0800 (PST)
Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id MAA08899; Wed, 6 Nov 1996 12:31:47 -0600
From: Joe Greco <jgreco@brasil.moneng.mei.com>
Message-Id: <199611061831.MAA08899@brasil.moneng.mei.com>
Subject: Re: Limiting bandwidth on a socket? (SO_RCVBUF?)
To: rminnich@Sarnoff.COM (Ron G. Minnich)
Date: Wed, 6 Nov 1996 12:31:47 -0600 (CST)
Cc: hackers@freebsd.org
In-Reply-To: <Pine.SUN.3.91.961106095628.29356E@terra> from "Ron G. Minnich" at Nov 6, 96 10:05:50 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > int s, rval;
> > s = socket(...);
> > while ((rval = read(..., 1024)) > 0) {
> > 	sleep(1);
> 
> ooch, ouch. my brain now hurts :-)

Whazzamatta?  Don't tell me you have never executed a gross hack before!!

> Joe's method will work fine, but we may all agree we want a little more. 
> Well, we're working on that here. So I would like to judge interest from 
> this group. 
> 
> What we're looking at is putting ioctls in at the socket layer to
> implement rsvp-style reservations. I.e. you would use rsvp as now for
> reserving qualities related to flow of data, and our code would operate at
> the socket layer for enforcing those reservations. We want it to be at the
> socket layer so the user can have the controls work the same even though a
> socket may at the lower level be unix-domain, tcp, and so on. We've found 
> that this sort of control is very important for distributed computing. 

That is nice at an upper level, but I can see at least as much usefulness
at a more administrative level as well.

A particular application may certainly know that it wishes for bandwidth 
of 'X' and it can arrange that through some mechanism.  A socket level
mechanism can provide a maximum cap, certainly...

However, it would also be nice to be able to deal with this at the network
level, and while some things are already available to allow this (ET's
bandwidth manager for example), it would be something that I recommend you
at least consider and be aware of.

... JG