Subject: Re: RSVP and ATM

From: [email-masked]
Date: Sat, 17 Aug 1996 22:34:37 -0400

In a message dated 96-08-16 15:06:42 EDT, [email-masked] (David Oran) writes:

> LAN switching does make the problem somewhat simpler since you no longer
>  have a shared single medium with an unknown number of stations using an
>  unpredictable amount of the media capacity, but the problem by no means
goes
>  away. This is because you can configure a switched LAN such that the
>  upstream bandwidth is less than the aggregate bandwidth coming into the
>  switch from downstream. If every switch is a router and is RSVP-capable,
>  then you don't have a subnet bandwidth management problem by definition
>  since all links are point-to-point and terminate in routers. On the other
>  hand, most LAN switching configurations have most of the swtches be only
>  bridges, and you still need to do something gather load information from
the
>  switches and to tell them how to detect and schedule flows.

LAN switching makes the problem simpler because LAN switches
provide more bandwidth, with higher throughput at lower cost, lossage 
and latency to individual hosts.  In general, the problem of providing
soft real-time capabilities is best addressed by building better
packet switches.  But even if the LAN switch routers (i.e. has
VLAN router capabilities and can route between virtual LANs),
the many to one data bandwidth problem still exists on the
individual VLANs supporting more than two ports.

Joachim Martillo
Inventor of the VLAN
President 
Telford Tools, Inc.
"Garage Mechanics for the I-Way"
17 Pleasant Hill Ave.
Dorchester/Mattapan, MA 02126-2813
V:  617-298-1617
F:  617-298-1745
E:  [email-masked]

---

From: Tim Bass (Underground) <[email-masked]>
Date: Sun, 18 Aug 1996 11:12:59 -0400 (EDT)

it was written:

>>  If every switch is a router and is RSVP-capable,

......

\discussion{}

Sorry, but this is not 'entirely correct'.  The very nature of media
access on a shared ethernet segment at the end user subnets, based
on the exact specifications of 802.3 (collision detection and
random back-off before retry) mathematically guarantees a stochastic
process the cannot given an upper mathematical bound.

Take the simple case of running any buffer managment level three
protocol two hosts at the end of a link with two routers, where
the hosts are on ethernet subnets with numerous devices.

Buffer management protocols at level three (and RSVP is 'the' example
in the worlds radar screen) cannot stop collisions at level two
on highly congested ethernet subnets.

Experiments have shown, however, that it is possible to 'defeat' the
random, stochastic nature of CDMA at level two by having the level
three sockets flood the LAN interface buffers; but this is far
from scalable nor mathematically a good engineering design.

Again, buffer management at level three is a great, wonderful idea,
for heterogeneous internets.   In a similar, but more dramatic
metaphor, the claws on the back of a hammer can be used to turn
screws, especially if we grind the end of the claws smaller
and smaller .......... 

IMO, the best engineering approach is to try *not* to make RSVP
the meta-solution for every possible real-time data requirment
configuration.  To do so virtually guarentees the failure of
RSVP, again IMO.  (and I'll spare the readership the metaphor
of tools and the right place to use them.... :-)

Hope everyone is having a nice weekend, 

Tim

\comment{}

(I did not see the RSVP working group in the reply list, which the
 RSVP chair vetoed, hence I hope a reply is appropriate, even
 if it is incongruent with 'the ideals of the big vendors" ...)