Subject: Unused bandwidth policy

From: Mohan Sharma <[email-masked]>
Date: Thu, 5 Dec 1996 11:13:43 -0800 (PST)

Hello:

When a bandwidth is reserved at a router/switch for a session, it is not
clear from the specs if the reserved bandwidth should be treated exclusive
for the session. From the definition of controlled-load service, it 
appears that the scheduler could use any unused reserved bandwidth for other
flows. And the guaranteed service appears to claim exclusive access to the
reserved bandwidth.

I feel that irrespective of the type of service, it should be up to the 
users to request the BW as either exclusive or sharable when not used. 
This could be a RSVP policy info that will be used by the schedulers 
along the path. The result is two-fold. It could increase the network
utilization and I could be charged less for making my reservation
non-exclusive.

Thanks.

Mohan Sharma

---

From: [email-masked]
Date: Mon, 23 Dec 1996 02:45:40 -0500

In a message dated 96-12-21 11:46:35 EST, [email-masked] (Lixia Zhang)

>  yes that's roughly the case.
>  - just to make it clear, this is an admission control issue not the setup
>    protocol 
>  - so put it in precise terms, it is not the scheduler (which does nothing 
> but
>    s huffling pkts around), but the admission control which decides whether
>    further requests can be handled based on the current reservation/load 
> state.

Does admission control consider the actual throughput of the
packet switching device or does it blindly work from the interface
bandwidths?   

To be clear, a router has 4 155 Mbps interfaces 
and a flow through a pair of interfaces reserves 100 Mbps while 
unreserved flow through the other two interfaces consumes 155 
Mbps.  

With pairwise flows the router should be able to
support 310 Mbps, but the effective bandwidth of the
router might only be 155 Mbps (actually router
bandwidths often depend on the size of packets
traversing the router -- as the packets get
smaller the effective bandwidth can go down
because the router must execute more and
more table look-ups per second).

In such a case the unreserved traffice traversing the 
interfaces, which the flow with reserved bandwidth 
does not use, consumes the whole bandwidth
of the router.

>  Given a user can already choose between "exclusive" and "shared"
reservation
>  by choosing different service types, I wonder why why you consider it
>  desirable to have another way for doing the same thing.
  
Could he be referring to the situation above?  How is the implementer
of bandwidth reservation to deal with variable effective throughput
that depends of average packet size of the traffic that traverses
the router?  Must admission control account for such variable
effective bandwidth?  Would not admission control itself
be consuming a lot of bandwidth by increasing the number
of table look-ups?

Joachim Martillo

---

From: [email-masked]
Date: Mon, 23 Dec 96 10:28:33 PST

This discussion of integrated service models does not belong on the
rsvp mailing list.  Please remove [email-masked] from the distribution
if/when you continue this discussion.

Bob Braden

---

From: [email-masked]
Date: Tue, 24 Dec 1996 07:38:22 -0500

In a message dated 96-12-22 07:17:34 EST, [email-masked]
(Masataka Ohta) writes:

> Lixia;

reservation

>  Perhaps, some kind of people who are working on reservation-only
>  networking just do not know that there is best effort traffic
>  which can consume unused resources exclusively reserved by
>  someone else.

Joachim Martillo

---

From: [email-masked]
Date: Tue, 24 Dec 1996 20:37:27 -0500

In a message dated 96-12-23 17:36:07 EST, [email-masked] (Karl Auerbach)
writes:

> > RSVP true believers allude to video applications and
>  > maybe voice.  The statistics of such traffic is quite
>  > different from today's typical network traffic.  Once a voice
>  > or video application reserves its bandwidth, that
>  > bandwidth really is not available for sharing,

>  Here at Precept video traffic is by far the dominant part of our
>  network traffic.  We see that although video is fairly constant when
>  measured over a period of seconds, it does tend to have a lot of
>  variability when measured on a smaller scale.  Much depends on the codec,
>  the abount of variability between sucessive video frames (i.e. whether the
>  scene is high motion or talking heads), etc.

I presume you are interworking video between a circuit switched
network and a packet switched network.  You are probably
working with some sort of compressed video. 

1) Because compression tends to take longer at the 
compressor than decompression takes at the 
decompressor and 

2) because compression tends to cause variations in the
rate at which data is delivered to the packet switched
network, fine grain variations in flow might provide windows
for non-stream oriented traffic.

But one should probably not depend on the differential
decompression/compression rates and variations in
flow due to compression.  If someone is providing
a flow of video and the algorithms create periods
in the flow where no data is being transmitted, it
might make sense for the provider to put something
there (if only redundant data to compensate for
for framing slips or dropped packets),  Also there could
be a lot of variation in the amount of compression to which
a given provider subjects his traffic stream.

If the video stream is sourced and sunk in the same
packet switched environment there could well
be a good deal less compression and a good deal
more constancy in the flow down to the fine
grain.

>  We usually find that video traffic has sufficient variability that there
>  is a reasonable amount of room left over during the short periods of
>  lesser video traffic to get a lot of useful normal TCP traffic through.

Does this useful normal TCP traffic include the movement
of a lot of graphics images such as are associated with
hundreds of web browsers getting images from servers?

>  As part of my own RSVP testing, one of the problems I've had is to find
>  traffic mixes which allow me to demonstrate the impact of reservations --
>  the statistical multiplexing we are getting without reservations is
>  amazingly good.

If a packet switched network provides huge bandwidth with little 
lossage and low latency, it should be able to sustain streaming 
traffic without reservation of bandwidth.  For that tiny percentage of
traffic that truly requires the reserved flow, interworking with
a circuit switched network makes far more sense than bandwidth
reservation.

To build a network that provides huge bandwidth with little lossage
and low latency requires good packet switch and packet switched
network design.

High bandwidth LAN or WAN segments should be viewed as
the access medium to the packet switch which serves as
a network in a box.  The internal bus of the packet switch
(1-4 Gbps using off the shelf technology -- bus bridges like
LAN bridges increase the effective bandwidth) is the shared
network medium.  

With good software design, multiple routers, 
LAN switches, ATM switchs, ARP servers, X.25 switches,
FR switches can be instantiated within the packet switch as 
software constructs to serve the external hosts that access 
the internal bus network through high bandwidth access 
channels.

Of course, good hardware software codesign is required,
and designers must  use some discernment in choosing
components from which to construct the packet switches.

The IDT Orion and the Motorola QUIC (68360) generally 
serve no useful purpose in high performance packet 
switching.

The bandwidth and latency reservation services that
are being defined are completely inimical to the
concepts underlying high performance packet switching.
The procedures necessary for software implementation
of such services can make a packet switch perform 
like mud.

Just consider the guaranteed latency service
and how it might have to be coded with a typical 
modern interface component like the DC21140 or 
the Hitachi SCA.

These devices have output rings in which some
number of buffers with variable amounts of data
are loaded.  In the simple stochastic packet
switching model, this interface works great.

The transmit routine loads the packet buffers
into the ring and forgets about them.

With guaranteed latency reservation, the 
transmit routine has to make sure that 
there is never more bytes (!!!! not buffers) 
in the ring than the minimum guaranteed
latency.  When ring contents exceed
the minimum guaranteed latency,
the buffers of the next packet have
to be queued somewhere and cannot
be put into the ring until sufficient ring
contents have been transmitted.

In the quest for guaranteed latency,
a tremendous number of calculations
must be performed and the amount
of memory references has increased
dramatically.  The value of simple,
elegant yet powerful components
like the DC21140 has been completely
negated.

Guaranteed latency sends packet switch 
performance into the toilet.  Guaranteed 
bandwidth will probably do the same.  

A lot of the services for which RSVP
is proposed to be employed will probably
have a similar effect.  Using RSVP
for tags is probably less harmful,
but there are better ways to address the
tag problem, and Cisco's engineering
efforts would be better spent in
replacing the IDT Orion based designs
and in putting a more reasonable
interconnection bus onto Cisco systems.

Joachim Martillo