From owner-freebsd-hackers  Sat Mar 28 08:37:25 1998
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id IAA06918
          for freebsd-hackers-outgoing; Sat, 28 Mar 1998 08:37:25 -0800 (PST)
          (envelope-from owner-freebsd-hackers@FreeBSD.ORG)
Received: from etinc.com (et-gw.etinc.com [207.252.1.2])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA06907
          for <freebsd-hackers@FreeBSD.ORG>; Sat, 28 Mar 1998 08:37:18 -0800 (PST)
          (envelope-from dennis@etinc.com)
Received: from dbsys (dbsys.etinc.com [207.252.1.18]) by etinc.com (8.8.7/8.6.9) with SMTP id LAA10780; Sat, 28 Mar 1998 11:44:01 -0500 (EST)
Message-Id: <3.0.32.19980328114322.00ff9ea0@etinc.com>
X-Sender: dennis@etinc.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Sat, 28 Mar 1998 11:43:25 -0500
To: Dan Janowski <danj@3skel.com>, freebsd-hackers@FreeBSD.ORG
From: dennis <dennis@etinc.com>
Subject: Re: Network throttle...
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

At 10:35 AM 3/28/98 -0500, Dan Janowski wrote:
>I am looking for a way to create a lower bandwidth restriction on an
>interface. I have an ethernet interface that I want to restrict to a
>maximum
>of T1 throughput.
>
>1. Is there a way to do this (easy or kernel hacking)

We have a commercial add-on product that does this

http://www.etinc.com/bwmgr.htm

>
>What happens, i.e. the mechanics, when there is a higher
>capacity link feeding into a lower capacity link. Where does all
>the data go? I know it is buffered to an extent, but that has limits.
>Do the packets get dropped? I seem to remember an ICMP type that
>indicates transmission of too much data and for the sender to cut back
>or something.

Our product "simulates" the functioning of IP packets when they reach a 
slower link. Data is only dumped when the hold time is greater that a 
threshold (as TCP will retransmit anyway). In normal operation (ie without
substantial overload like video feeds or flood pinging) TCP is self-throttling
by "slowing the acks". Source quenching is not necessary, unreliable and
generally creates a mess.

You can limit the entire interface, limit individual hosts by IP address, 
entire networks or limit data types (like cu-seeme traffic). 

Dennis
>
>All thanks,
>
>Dan
>
>
>--
>danj@3skel.com
>Dan Janowski
>Triskelion Systems, Inc.
>Bronx, NY
>
>
>
>
>To Unsubscribe: send mail to majordomo@FreeBSD.org
>with "unsubscribe freebsd-hackers" in the body of the message
>
>

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