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

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

From: [email-masked] (James E. [Jed] Donnelley)

    > 1. Is there a need for QOS routing in the internet?

    I believe no. ... I basically buy his argument that the available
    bandwidth is increasing at a sufficient rate .. that QOS in the insides of
    the network is not needed. Bandwidth and performance (I expect) will soon
    become constrained by the bandwidth to and in the home/office.

This question, of whether we need resource reservation, is to my mind the
single biggest open question in networking. I've listened hard to both sides,
and both have some very good arguments; I have reached no definite conclusions.

I think we will need some sort of resource *usage* controls, otherwise people
will do dumb things like open a video connection to their friends and leave
it up all day while they work, and stuff like that. However, you don't need
resource *allocation* to do that - a simple usage metering scheme (think
water meter on your "pipe" to the network) would do that.

For resource *allocation*, sheer bandwidth is not the issue. The best arguments
that I have heard for resource reservation are as follows.

The first is support of applications with very strict delay requirements, such
as good quality voice. Load peaks (of the kind that are common in data
traffic) will trash voice, which needs low delay for human factors reasons. A
simple "priority" scheme in packets, allied with charging more for such
traffic at the network entry point (see the "water meter") to prevent people
cheating and marking all traffic "high priority", might do enough, but I'm not
sure.

That leads you to the second argument, which is dealing with load peaks in
non-elastic applications traffic. If you get enough delay-sensitive traffic,
priority won't help you meet useful delay bounds. You can overprovision to
your heart's content, and there will always be load peaks which clip; if not
on Christmas (since we seem to have enough capacity now even for that), then
when an earthquake hits, and everyone calls home. Simply making everyone's
service worse is not an option, I think; you need to be able to say "sorry,
we're too loaded".

Which leads to the third argument, which is that there are a number of users
who demand the ability to be able to preempt bandwidth in emergencies.
Civil authorities have the ability to preempt phones in an emergency, and
military communication networks have similar capabilities. If we're building
a genuinely ubiquitous network, probably this class of user will demand to
have this sort of capability available.

Finally, if it really is the ubiquitous network, there will be applications
which are life-threatening if they go wrong (e.f. remote telesurgery, for an
SF-y example), and these may demand guarantees. If our net cannot provide
them, some other comunication system will likely be used instead.

    I know this is a very high level argument. I think sometimes such high
    level arguments are appropriate. I happen to think this is one of those
    times.

It remains an open question as to whether it's more economic to provide the
sorts of capabilities mentioned above by upgrading what the data net can do,
and putting everything on top of that, or whether certain applications are so
specialized that the required enhancements would be non-cost-effective, and
those applications are best handled by a separate substrate (a tip of the
hatly hat to JTW for pointing this formulation out to me).

Since this the answer to this is an economic one, involving the sum of many
details, it's unlikely that we will find the answer until we've actually got
some experience to go with - and even then the answer may not be final, as
the economics of various approaches change over time.

	Noel

---

From: Steve Deering <[email-masked]>
Date: Fri, 5 Apr 1996 09:06:19 PST

> From:	[email-masked] (Noel Chiappa)
>

Funny you should say that.  Whenever I find myself in the reservations vs.
no reservations debate (in which I am firmly in the no reservations camp),
I recount the story of when the San Francisco Bay Area earthquake occurred
in 1989 and one of the profs at Stanford was away on a business trip.  On
TV he saw that San Francisco was burning, the freeway in Oakland had
collapsed, and damage was widespread throughout the area.  He desperately
wanted to find out if his family was OK and if his house was still standing.
That's only a few bits of information, but all the phone system had to offer
was a perfect 64kbps channel or a busy signal, and 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.

(Yes, voice service can be made adaptable to bandwidth degradation,
by progressively aggressive compression and, when that isn't enough, by
voice-to-text [voice recognition] and then text compression.  In the
earthquake example, even an internet telephone application that said:
"Insufficient bandwidth for voice -- please type your message" would have
been acceptable, and would have allowed the available bandwidth to carry
many, many more useful bits.)

Steve

---

From: Lee Breslau <[email-masked]>
Date: Fri, 5 Apr 1996 10:30:31 PST

> From: Steve Deering <[email-masked]>
>

I realize you have other arguments against resource reservations and
were only responding to Noel's earthquake example.  But the
lesson I get from your earthquake story is that networks that provide
only reservation-based all-or-nothing services are not the answer.  
The question remains whether or not networks offering *both*
reservation-based services as well as best effort services represent
an improvement over best-effort only.  In an integrated
services network, the people who run the networks will be able to
control how much resources get allocated to reservation-based services.
Therefore, I don't see resource reservations as necessarily preventing
people who only need to send a few bits of information during an 
emergency from doing so.

Lee

---

From: [email-masked] (SanJeev Rampal)
Date: Fri, 5 Apr 1996 13:20:30 -0500 (EST)

> nothing service of a QoS reservation system.

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... ). 

Sanjeev.

---

From: Daniel Zappala <[email-masked]>
Date: Fri, 5 Apr 1996 14:30:34 -0800

>>>>> Steve Deering <[email-masked]> writes:

Re: reservations versus no reservations

> many, many more useful bits.)

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?  Any time my neighborhood
malcontents flood our local link?  It seems that determining whether a
reservation protocol will be needed is intimately tied to your view on
future traffic patterns, usage, and network growth.  Although
forecasting these things is awfully difficult, the high-level debate
should probably be casted in these terms.  At least then we can make
decisions regarding what we're building for, even if in the
end the network turns out differently.

Daniel Zappala
[email-masked]

---

From: [email-masked] (Andrew T. Campbell)
Date: Fri, 5 Apr 1996 19:26:15 -0500 (EST)

Daniel:

> The question is...

Here in the COMET Group we think the question is more "how to 
build distributed systems platforms with end-to-end QoS programmability":
e.g., http://www.ctr.columbia.edu/comet/xbind/xbind.html

Can't we be inclusive - even visonary - and move on from
the stale networking arguments of:

	1 reservations versus no reservations,
	2 soft state vs hard state, and
	2 IP vs ATM 

to the higer layer problem space. 

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). As a side note the network 
will have to meet these QoS requirement no matter its technology, control or 
operational QoS policy; that is,  whether it uses ATM hard-state 
with reservation or IP soft-state with controlled load or 
without reservation, etc., etc. 

Recently, there as been  a number of enlightend proposals 
(e.g, Jon Turner's ATM-SOFT) and technology (Ipsilon's IP-switch and 
flow management protocol) which have endeavoured to "bridge the gap" (1-3)
and defuse the wars but to no avail. 

If these proposals could bridge the gap then we could focuss on
the next step: QoS-based APIs. After that comes the QoS prorammability:
http://www.ctr.columbia.edu/opensig/activities/opensig.spring.96.html

Perhaps then we can forget about the wars? But then again wars
are money making enterprises :-)

-- 
Andrew
http://www.ctr.columbia.edu/~campbell
(212)-854-3109

---

From: Daniel Zappala <[email-masked]>
Date: Fri, 5 Apr 1996 14:30:34 -0800

Daniel Zappala
[email-masked]

---

From: [email-masked] (Andrew T. Campbell)
Date: Fri, 5 Apr 1996 19:26:15 -0500 (EST)

---

From: Tony DeSimone <[email-masked]>
Date: Sat, 6 Apr 1996 12:49:33 -0500

>>>>> "Steve" == Steve Deering <[email-masked]> writes:

>> service worse is not an option, I think; you need to be able to say "sorry,

Steve> Funny you should say that.  Whenever I find myself in the
Steve> reservations vs.  no reservations debate (in which I am firmly
Steve> in the no reservations camp), I recount the story of when the
Steve> San Francisco Bay Area earthquake occurred in 1989 and one of
Steve> the profs at Stanford was away on a business trip.

Funny you should say that yourself.  I recall when a prof from
Stanford told that same story at a workshop I attended in 1990 (I
don't remember if his earnest young student was involved in the
discussion).  It wasn't a very good example then, and it's not any
better now.  For focussed overloads in the telephone network, traffic
controls are put in place exactly to say ``sorry, we're too loaded''
to incoming calls, to give preference to outgoing calls from the
congested area.  Given the limited flexibility of the ``hard
reservation model,'' that seems like exactly the right thing to do.  I
would think any other system would want to have the capability to
provide preferential access to a limited resource as well, particularly
in the kind of disaster scenario you're discussing.  The operation of
these controls in telephony is well-know: it shows up even in the
popular press.  Maybe you need a new story.

There may still be an interesting debate to be had around the need for
reservations, but I'm beginning to doubt it.  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.  Of course there's still an
interesting debate to be had about the *right model* for reservations
(and charging), but we're not having it now...

Tony

---

From: Steve Deering <[email-masked]>
Date: Sun, 7 Apr 1996 13:08:35 PDT

> From:	Tony DeSimone <[email-masked]>
> 
> I recall when a prof from Stanford told that same story at a workshop I
> attended in 1990 (I don't remember if his earnest young student was
> involved in the discussion).

Oh, probably.  The student does remember being involved in discussions
of this topic where an earnest young adherent of the conventions of
telephony was present.

>                It wasn't a very good example then, and it's not any
> reservation model,'' that seems like exactly the right thing to do.

Tony, the point of the story was not that the phone companies ought to
have done something different, but that we ought to avoid using the same
inflexible hard reservation model in future networks.

> Maybe you need a new story.

Given that you didn't get the point of the old story, I guess you're right.

>                                              Every argument I've
> either ``over-provisioning'' or ``adaptive applications.''

Or both.  If you rely on adaptive applications rather than resource
guarantees, application designers have the right incentive to make most
efficient use of whatever capacity is available from moment to mement, e.g.,
by developing better compression and adaptation algorithms.  And the cost of
adequately provisioning for such applications is likely to be *less* than
the cost of provisioning for wasteful, guarantee-dependent applications.
Furthermore, you end up with applications that deliver value over a much
wider range of resource availability, including the emergency scarcities.
Sound great to me!

> I don't think either argument is compelling.

Gosh, I don't think the counter arguments are compelling.

> Of course there's still an interesting debate to be had about the *right
> model* for reservations (and charging), but we're not having it now...

Yeah, it's about as interesting as the obsolete debate about what the
*right* virtual memory page-replacement algorithm is, or what the *right*
charging model is for CPU usage on a timesharing system.  Those debates
were rendered irrelevant by the availability of cheap memory and cheap
processors, and I predict that the debates about the *right model* for
reservations will be rendered equally irrelevant by cheap bandwidth.

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

Steve

---

From: Zheng Wang <[email-masked]>
Date: Mon, 08 Apr 1996 13:10:30 +0100

> nothing service of a QoS reservation system.

But if a network would not say "no", we may see another extreme where no one
can get through because everyone is trying to get through. The UK-US link
is probbaly a good example. For large part of last year, it was so congested
that it become virtually unusable. The loss rate were 50-70% and many tcp
connections didnt even make it to the 3-way handshake. It would be much better
if we could rotate the use of the link among the institutions here (one hour
for each region:-).

Cheers
Zheng

PS: The link bandwidth was more than doubled this year but the effects are
minimal - there are just two much traffic!

---

From: Juha Heinanen <[email-masked]>
Date: Mon, 08 Apr 1996 20:52:13 +0300

Zheng Wang wrote:
> connections didnt even make it to the 3-way handshake.

in order for best effort to work, you need to provision the network 
adequately and be able to isolate users from each other so that everyone 
gets an approximation of their fair share.  if you know the number 
of (paying) customers and have some kind of fair queueing support in the 
routers, the above should not be too difficult to achieve.

-- juha