Subject: Re: [Diffserv] QoSSIG BOF

From: [email-masked]
Date: Tue, 25 Jan 2000 14:26:48 -0800

Ping,

Reading this chart, some interesting information stands out for me.  First (and
it may be too early to really judge from the limited data points given) but, it
looks like the number of networks has begun to flatten out.  While, Hosts and
Domains continue to rise to to the right at about the same slope.  In addition,
eventhough we are increasing compacity of the networks (ie., WDM, dWDM, ect.),
if the trend contineus, host will overrun the core (even at the mutligig
speeds).  This leads me to the agreement(s) I've heard here (as well as in other
forum) where the best would be a combination of protocols (ie., QoS(RSVP like)
at the edge to support host requirements and CoS (DS) in the core for use as
well as scaleability.

I would also draw another analogy as well.  LDAP was supposed to be a scalled
down version in place of X500.  If you look at LDAP v3 with extensions, most the
X.500 features deemed to complex are slowly creeping their way back into it
because they really were needed and served a purpose.  I'm not defending RSVP
but, if the QoS features are really needed,  no matter what protocol is used,
the feature will show up again if needed.

/jsb

Ping Pan <[email-masked]> on 01/23/2000 12:53:25 AM

To:   Stephen Casner <[email-masked]>
cc:   RSVP <[email-masked]>, diffserv <[email-masked]>,
      [email-masked], [email-masked] (bcc: James Binder/HQ/3Com)

Subject:  Re: [Diffserv] QoSSIG BOF

Stephen Casner wrote:
>
>
> I find this amusing from an historical perspective.  One of the
> motivations (not the only one) for the development of RSVP was that
> ST-2 was "too complex and not scalable".  The designers of RSVP saw a
> simpler and more straightforward approach.  In many ways, RSVP
> improved upon ST-2, and it did start out simpler.  But as the RSVP
> solution was completed, it was no longer simple.
>
> Now those same complaints of complexity and scalability are being
> lodged against RSVP.  Some problems are fundamentally complex.  Those
> who believe they have a simple solution may not have reached the end
> game.
>                                                         -- Steve
>

Steve,

IMHO, this is not a RSVP problem. Rather the network has grown too fast
in the past few years. Please take a look at the network growth chart at
http://www.cs.columbia.edu/~pingpan/projects/net_growth.gif.

I don't think that one single protocol can provide the resource
reservation solution to the world. RSVP may be already very good at what
it does. We can continue to enhance RSVP again and again and squeeze the
last drop of efficiency out of it, but maybe we should take one step
back and re-evaluate the whole problem once again with new knowledge and
new requirements.

Let's fact it: during the days of original RSVP, the network was
smaller. There was no MPLS (or connection-oriented IP packet-switching
network) requirements. There was not much of WEB traffic if any. Instead
people were expecting the coming of wild-spread multicast deployment to
the entire network, and expecting the hugh number of teleconferencing
applications. At the time, the Internet was a simple
dumb-network/smart-end-host model. Nowadays, the Internet has smarter
end-hosts and not-so-dumb networks. IETF's Traffic Engineering WG and
many policy related WG's are focusing on how to configure the networks
efficiently. So the original RSVP was designed with different
objectives.

I would think that we should first understand the problems involving
with resource reservation, then try to solve the problems. In the past
year, Ellen Hahne, Henning Schulzrinne and I had tried to understand the
scaling problem with RSVP. After collecting some data from the network,
we reasoned out some of the issues:

First, we need a hierarchical reservation architecture. Making
reservations on one flat network will not scale!

Second, even when we are dealing with reservations at the network domain
level, if we use signaling protocols with N**2 properties, such as RSVP,
it will still be tough to work.

Thus, our work on BGRP
(http://www.ietf.org/internet-drafts/draft-pan-bgrp-framework-00.txt) is
to propose an inter-domain reservation protocol running between BGP
border routers. End users can use RSVP within their networks. RSVP flows
can aggregate into the BGRP-reservation trunks at network edge. Thus the
whole system will scale.

This reminds me of the evolution of routing protocols. RIP was fine
(after bug fixes ;-)) at what it does at small networks. But we could
not use it to run a very large backone. With new requirements in mind,
BGP came out. So a hierarchical routing model had made the Internet what
it is today. We may adapt a similar approach to the reservation system.

Best regards,

--
Ping Pan         http://www.cs.columbia.edu/~pingpan

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 26 Jan 2000 12:21:56 +0000 (GMT)

On Tue, 25 Jan 2000 [email-masked] wrote:

> looks like the number of networks has begun to flatten out. 

Blame the address space and firewalls.

L.

removing diffserv just to be on the safe side.

> http://www.cs.columbia.edu/~pingpan/projects/net_growth.gif.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>