Cell Relay Archive

[albert.e.manfredi@boeing.com]

In article <867lxr0yzt.fsf@ironbridgenetworks.com>,
  James Carlson <carlson@ironbridgenetworks.com> wrote:
> albert.e.manfredi@boeing.com writes:

> There are middle grounds -- such as using explicit mapping of TOS
> values on network boundaries to provide small numbers of QsoS where
> necessary.

Well, not much of a middle ground. Using TOS values is a short step. It
basically banks on prioritized queues at routers being all you need for QoS.
If you believe that lots of excess bandidth in the entire backbone, at all
times of day, is remotely likely, then I might agree this is good enough.

> This is better in many respects -- it avoids the signaling
> and state overhead and it avoids the complexity where undesired.

Of course it's better. If you completely ignore the problem, a solution won't
be needed. It's still to be proven that in the real world this can work,
though. There are some papers on this, but I don't think there's anything
close to consensus. One article, now somewhat dated, that seems to contradict
your hopefulness is in the Dec 97 issue of Transactions of the IEEE: "Delay
Performance Analysis of the New Internet Services with Guaranteed QoS," by
Van Der Wal, Manjes, and Bastiaansen. They determined through simulation that
to provide QoS useful for voice or interactive video, IP packet sizes must be
limited (size depends on a lot of variables) and, while it can work, the
efficiency of the network drops considerably. Point being, to me anyway, that
you can't fool mother nature. (Packet sizes were generally maxed out at <200
bytes or so, again, scenario dependent.)

And you would not have the equivalent of ATM's cranckback, either, by the way.

> Yes, I'm well aware of how VPs work.  In this case, two levels just
> aren't enough if you want to take ATM from the edge (DSL-line) all the
> way through the core.

Interesting point which I wouldn't mind researching in depth. How many levels
do you think you need?

> Except for folks who want to pay for the explicit signaling (which I
> suspect are a small minority), I doubt that RSVP will have any meaning
> in the long term.  Like UNI 4.0, it's just too damned complicated, so
> it doesn't really do any one job particularly well.

Again, a question of whether it is realistic to wish away the hard problems,
or whether they really do need to be solved. I always marvel at how some are
so eager to assume that just because IP can be used for web browsing, plain
Jane IP must therefore be usable for everything else. Maybe it indeed will
turn out that way, but it's a mystery to me how that could happen. Or why
some people seem so sure it can.

> No, of course it's not.  Insert your favorite physical layer for
> "fiber" if you like.  I used that term only because the predominant
> use of ATM today is over SONET/SDH, and that's probably because, to a
> bell-head, ATM smells a lot like SONET/SDH just with much finer
> granularity of bandwidth provisioning.

It makes perfect sense, since ATM was developed by the same people who
developed SONET, and was developed _specifically_ to provide efficient use of
SONET. It makes much less sense to use ATM over other media, in my opinion.

> The point I was making is that IP runs even better if you remove the
> SONET/SDH layer as well, since it's just yet more unnecessary
> overhead.

What a strange comment. SONET overhead was specified for a purpose: to allow
the network provider to manage and to troubleshoot huge, global networks, to
allow the network provider to partition this enormous network into different
paths, to permit isocronous operation over this global network, etc. etc. To
wish it away is, like the rest, just wishing away real problems that need real
solutions.

> The problems that WAN folks are seeing have to do with the fact that
> the large deployed ATM switches today are generally sized for voice.
> Of course, that's not true in Fore's "campus network" niche.

Okay, I can agree with the fact that buffer sizes in WAN ATM switches might
need rethinking if really useful data services are to be provided.

> > There are a lot of people who know these things asking
> > themselves this question.
>
> The implication being that I know nothing of these things?  Hmm,
> where'd *you* learn to debate?

Touchy, touchy. There are no "implications." I said what I meant. These
questions are not anywhere close to cut and dried as you have been implying. I
know there is a certain contingent among data types who like to pretend that
there are no problems, but I frankly have never understood why. The only
sensible way to "debate" this is not to boisterously assume away the problems,
but to lay them out on the table and demonstrate whether or not they can be
wished away. So far, the answer has been no. The IETF itself is looking into
different ways of using ATM-like hardware (i.e. tag switching, IP switching),
even if not all of ATM, to get the QoS services they need to take over all
global comms. So it ain't just the ATMF worrying about these things.

Bert
manfredi@arl.bna.boeing.com

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own