Subject: Re: QOS Routing - high level comments (long)

From: [email-masked] (Noel Chiappa)
Date: Fri, 5 Apr 96 10:09:50 -0500

From: Juha Heinanen <[email-masked]>

    i would not like deal with the complexities that are involved once
    one starts deploying qos ruoting and resource reservation.

I won't tackle the resource reservation side of this statement, but I don't
see "QOS routing" (actually, a routing architecture that supports QOS routing
is more technically accurate) as necessarily that much more complex than
"regular" routing.

It's very *different* from the current routing architecture of the Internet,
yes, but the current model is not that simple either. There is a tremendous
amount of configuration information involved, and now we are getting into some
very high-level coordination issues to boot. The protocols themselves are not
that simple either, as a look at the OSPF spec will show you.

	Noel

---

From: [email-masked] (John Wroclawski)
Date: Fri, 5 Apr 1996 16:34:52 -0500

At 9:06 AM 4/5/96, Steve Deering wrote:
>of course he (and almost
>everyone else trying to phone the Bay Area that day) got nothing but a
>busy signal.  This seems to me like a clear case where "simply making
>everyone's service worse" is a far better option than the perfect-or-
>nothing service of a QoS reservation system.

Steve,

There's a big difference between allowing resource reservation and
requiring it. I'll suggest that one of the big strengths of the intserv
design is that reservations are an optional choice, separate from the basic
transmission of bits. Applications may use them or not on whatever basis
they want. If practical, they can continue to function with reduced service
if the full reservation is not available. Your example does not apply, I
think..

        -john

---

From: [email-masked] (John Wroclawski)
Date: Fri, 5 Apr 1996 16:34:52 -0500

Steve,

        -john

---

From: Steve Deering <[email-masked]>
Date: Fri, 5 Apr 1996 16:36:03 PST

My earthquake story was intended to be a meta-comment on the reservations
vs. no reservations debate, rather than a contribution to it.  (Jed Donnelley
is already doing a fine job of arguing a position very close to my own.)
I just found it ironic that Noel's example of a situation in which "sharing
the pain" of congestion was unacceptable was exactly the same scenario
I use to illustrate why sharing the pain might be preferable to busy
signals.

> From:	[email-masked] (Bill Zaumen)
> 
> At the risk of quibbling, this may be a bad example: the phone company
> tweaked the system so as to give more service to outgoing calls than
> incoming calls.

Yes, that's quibbling.  :-)  In fact, the same problem existed in the
outgoing direction -- it wasn't until six hours after the earthquake that
I was able to get a call through to my relatives on the outside.  During
that six hours, some small fraction of people got perfect 64kbps channels
to the outside, while the rest of us got nothing.  Many more people would
have been served with a system that allowed degraded operation.

>                   The rationale was that a person calling out would
> typically ask the person they contacted to call other friends and
> relatives to tell them that they were OK, whereas those calling in
> would make their calls independently (and approximately concurrently).

Sounds like a job for multicast!  :-)

> From:	[email-masked] (SanJeev Rampal)
> 
> Seems to me the example was more of a problem with the granularity of the 
> reservation system (64 kbps) than reservation techniques per se. For
> instance  with an ATM (:-)) telephone network, an intelligent terminal
> could progressively try lower and lower reservations until it got through.
> (Precisely  the reason that the Telcos came up with a transport network
> with  infinitesimal (!) bandwidth granularity... ). 

Oh great, fill up the bandwidth with signalling packets!

> From:	Daniel Zappala <[email-masked]>
> 
> The question is...given an application like this, how often will it just
> degrade to text form due to congestion limitations.  Only after
> earthquakes?  Every day between 9am and 5pm?

That depends on what it takes to keep the customers satisfied.  If it
degrades too often when making "conventional" local or long-distance calls,
the customers would presumably take their business to another carrier who
has provisioned their network to avoid such degradation.  (I understand that
the big US long-distance companies now size their networks so as to avoid
blocking any calls on Mothers Day -- I presume this is done either because
it is cheap to do and an easy way to avoid irritating their customers,
or because it has become necessary in order to avoid losing customers to
the competition.)  Therefore, I think competition will ensure that the
degradation occurs only in exceptional bandwidth shortages, such as
natural disasters, rock concert ticket releases, or when communicating
with submerged submarines or spaceships on their way to Mars.

>                                                Any time my neighborhood
> malcontents flood our local link?

Routers ought to prevent any source from monopolizing a link if there
are competing sources, e.g., by using RED or some approximation of Fair
Queueing.  Your household's share of the link ought to big enough to not
require your voice application to degrade to text mode.

I'll concede Lee Breslau's and John Wroclawski's point that allowing
reservations is not the same as requiring reservations, but that raises
questions about whether or not service providers would end up selling all
their bandwidth as "premium" reserved service, effectively eliminating
non-reserved service.  And that is a debate that I definitely don't
have the time or energy to take up right now.

Steve

---

From: [email-masked] (Noel Chiappa)
Date: Sat, 6 Apr 96 10:44:48 -0500

From: [email-masked] (Andrew T. Campbell)

    Can't we be inclusive - even visonary - and move on from the stale
    networking arguments of: 1 reservations versus no reservations ... Can't
    we agree that all of the above will possibiliy exist on a QoS continuum.
    Selection would be based on the QoS requirements of the user's flow (i.e.,
    service required)

You've just made an assumption that not all people share, which is that the
net used for data will also have reservations in it. There are people who feel
that this is complexity which is not needed to provide the services people
will want, and should be left out, and they have some pretty good arguments.

    2 soft state vs hard state

Here I agree with you. I think this whole hard-state/soft-state dichotomy is a
bogus one, one moreover which has become clouded with ill-informed dogma, in
which "soft-state" is "good" and "hard-state" is "bad". In truth, there are a
tremendous range of solutions, which differ along many axes (as I pointed out
in a message to the "big-internet" and "flows" list back in November), and to
try and label them simplistically in this way is not, to me, really very good
or useful. I.e. it's not so much a serious engineering discussion as it is a
framework for propoganda and polemics.

Now, if people want to talk about things like "how do we ensure that we aren't
setting up state that is used by very few packets" or "how do we make sure
there aren't excessive state setup and maintainence costs" and similar real
cost/benefit engineering questions, fine.

However, this simplistic "hard is bad, soft is good" mantra reminds me of
nothing so much as the slogans from "Animal Farm" - "Four legs good, two legs
bad." The world is a lot more complicated than an oversimplified and thought-
avoiding division into hard and soft state.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Sun, 7 Apr 96 00:30:29 -0500

From: Steve Deering <[email-masked]>

    In fact, the same problem existed in the outgoing direction -- it wasn't
    until six hours after the earthquake that I was able to get a call through
    to my relatives on the outside.  During that six hours, some small
    fraction of people got perfect 64kbps channels to the outside, while the
    rest of us got nothing.

Actually, now that I think about it, are you sure this latter model of what
was going on is what was really happening? I seem to recall from my study of
the No.1 ESS in the dim past of my undergrad days that phone switches had the
capability, in emergencies, of "ignoring" non-critical lines, to provide
guaranteed service to critical users (hospitals, civil defense, etc). I'm not
a phone wizard, so I don't know if this was going on in the earthquake, but
perhaps someone who is can tell us.

	Noel

---

From: [email-masked]
Date: Mon, 8 Apr 1996 08:19:10 -0500

> So I guess I should stop wasting my time debating it, eh?  :-)
> 

I think you and eveyone else involved in this debate should take this and all 
other religious debates offline now and in the future.  I for one am tired of 
listening to all the ego stroking!!  

> Steve

Ken

---

From: [email-masked] (Noel Chiappa)
Date: Mon, 8 Apr 96 11:43:45 -0400

From: Tony DeSimone <[email-masked]>

    > Do you believe that with "enough" overprovisioning, and a traffic
    > load which is reasonably consistent ..  one can make a statistical
    > guarantee of a specified level of service

    Yes. ... Did I say something that made you think otherwise?

Yes. In your original message you said:

    Every argument I've heard from the firmly no-reservations camp ultimately
    comes down to either ``over-provisioning'' or ``adaptive applications.''  I
    don't think either argument is compelling.

I was wondering what the nature of "[not] compelling" was; whether it meant
"fundamentally unworkable" or just something like "not currently economically
feasible". Here's why:

I believe the "adaptive application" argument is fundamentally unworkable in
some cases: e.g. things like interactive voice just *don't* adapt well to high
delay variance. Moreover, the root of the problem (human factors) means that
that application is fundamentally incapable of using that technique to deal
with that circumstance. The only way to do voice is with low delay variance,
and if your system doesn't provide it, you have to make it do so. So, adaption
is not a solution with global applicability. Some applications can adapt, but
we have that now.

So, when you mentioned that argument, in the same breath as "over
provisioning", I was wondering if you had some similar fundamental argument
about over provisioning that I hadn't been able to think of. I gather from
your reply that you don't: over-provisioning is technically feasible (although
it may not be economically optimal). Oh, I guess there's one small hole left:
do you think the traffic we be consistent (i.e. modellable) enough? I.e., to
make sure I'm hearing you right, cost factors aside, you think over
provisioning is technically feasible?

Of course, there may be other fundamental reasons why resource allocation is
needed: I listed what sounded like some plausible ones to me in an earlier
message.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Mon, 8 Apr 96 21:10:48 -0400

From: [email-masked] (Ross Callon)

    I think that much of the strength of the Internet comes from folks who
    quietly build the right thing while others are arguing about something
    else.

Probably the single most intelligent thing said in this whole debate! :-)

	Noel