[532] in linux-net channel archive
Re: [Project] Managing Available Bandwidth
daemon@ATHENA.MIT.EDU (Werner Almesberger)
Sat Jun 17 07:17:19 1995
From: Werner Almesberger <almesber@lrc.epfl.ch>
To: pete@I_should_put_my_domain_in_etc_NNTP_INEWS_DOMAIN.epfl.ch (Pete)
Date: Sat, 17 Jun 1995 12:10:26 +0200 (MET DST)
Cc: submit-linux-dev-net@ratatosk.yggdrasil.com
In-Reply-To: <3ri1k0$gql@vodka.intele.net> from "Pete" at Jun 12, 95 06:38:56 pm
> - All parameters configurable on an IP-address or IP-group level, for
> in-bound and/or out-bound traffic
The IETF RSVP WG is describing the concepts and defining a protocol for
doing this. You may want to have a look at
http://www.ietf.cnri.reston.va.us/html.charters/rsvp-charter.html
> - Time-sensitive parameters (for instance, CIR could be effective during
> business hours only for some customers, or CIR could be adjusted to
> different levels to allow for special events, etc)
You can handle such issues in the (user-mode) reservation agent.
> First, I've started by putting in delays in the net/inet/ip.c code, right
> before the calls to ip_fw_chk().
Hmm, that's a leaky bucket (see for instance Partridge's "Gigabit
Networking" for a short description) with bucket size (a.k.a. credit)
zero. Normally, you want to have a larger bucket, based on jitter,
available memory and delay requirements.
> However, since the reply comes back long before the appropriate amount
> of time has elapsed, it is refused. Of course, the reply will not be
> repeated, so ping will not work. So, I don't think this is the way to go.
No, you're confusing traffic shaping and traffic policing. Traffic
shaping is the process of making sure the traffic you emit conforms
to the traffic contract for that connection/flow/session. Traffic
policing is the process of handling (e.g. discarding) incoming traffic
that violates that contract.
Normally, shaping and policing are separate, i.e. you typically don't
have a total bandwidth allocation for an arbitrary bidirectional flow
on shared media. (The RSVP draft mentions multipoint-to-multipoint
scenarios, which are similar to this situation, but they simply suggest
to do statistical multiplexing in this case. (See also Partridge))
> [...] This would actually be a cleaner way to implement multiple CIR's
> and burst-rates, because other higher-CIR traffic wouldn't be held up
> by lower-CIR traffic.
You actually have to implement priority queues. At least two (for
reserved and non-reserved bandwidth). If you have traffic with a
guaranteed minimum rate and a non-reserved burst rate, fairness
becomes an issue too.
For the implementation, I'd suggest to ignore policing at the moment
and to focus on shaping. For this, you need the shaping models (e.g.
single or double leaky bucket) and later also the parameters for the
network you want to build that for.
Things might get messy here, e.g. for ATM, the cell delay variation
(CDV a.k.a. jitter) isn't standardized and it even can't be signaled,
so you have to ask the provider and configure this manually. At least
ITU-T acknowledges in I.371 (gopher://info.itu.ch/, but you may have
difficulties getting some of the documents) that you absolutely must
agree on the CDV in order to properly use a network ;-) I don't know
what the status is with Frame Relay.
Timers are certainly the second best way to implement shaping. (The
best way is to use hardware, as most ATM adapters do it, see also
http://lrcwww.epfl.ch/linux-atm/). Busy waiting or zero bucket size
won't work well in any realistic scenario.
If you need some more references for reservation concepts, I can look
up a few more focused books next week.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, DI-LRC,EPFL,CH werner.almesberger@lrc.di.epfl.ch /
/_IN_R_311__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
