The IP over ATM Mailing List Archive by date

[Earl Ferguson <earlf@ix.netcom.com>]

>   Absolutely.  Having a switch store&forward packets will just
>   re-introduce the very problems that ATM was trying to solve in the
>   first place (packet buffer delays, jitter, head-of-line blocking,
>   etc).  This sounds to me like it would make ATM switches look a lot
>   like IP routers, with all the associated problems for providing QoS.
>
>like it or not, this is how it is when talk about multi-point to point
>flows.  atm switch can't handle those without store and forward.  but so
>far atm forum or itu have not defined mp-to-p atm connections at all,
>which means that you need to use a real layer 3 device at every point
>when merging of flows takes place.
>
Doesn't this all go back to the early decisions to use AAL5 rather than
AAL3/4 or some
derivative? 

We first said VCs are cheap, so we don't need the additional demultiplexing.
And besides,
AAL3/4 uses too much overhead and hence line bandwidth and is more expensive
to implement. 
So use AAL5.

Then we found that VCs are not cheap and use resources to setup and maintain
at all points
in the network. So now we are looking for techniques to reduce VC useage.
For one we start talking about making all switches packet aware so that we
can avoid excessive VC usage. 

If we had chosen to use AAL3/4, at least we would have a mechanism to avoid
the need to 
queue packets at arbitrary points in the network where mp-to-p flows join.
And by the way we could reduce significantly the useage of VCs, since
mutliple packets could share the same 
VCC without the need to serialize the packets.

Of course if we chose to use AAL3/4 or another mecahnism to multiplex
packets on a single VCC
without needing to serialize the packets, then we make it harder for packet
discard to
be used in the center of the network.

As I recall, the original plan was that network center switches could be
inexpensive due to
the low resource requirements - no significant buffering is required if
proper management is 
used for the allocation of VCCs to links and everyone behaves themselves or
we police them
into shape to enforce the contracts. But now we find that undefined service
classes or 
available bandwidth classes are too hard to manage and avoid excessive loss
due to congestion
without making the network center switches aware of these and have them aid
the overall control
of these uncontrolled bandwidth sources so that they don't just create
excessive retransmission
bandwidth.

If we find ourselves sequencing most of our packet streams to multiplex them
on VCCs, then
haven't we just added 10+% to the bandwidth requirement without any gain for
the packet
applications?

I give up :-).

Earl Ferguson