Subject: RE: [Diffserv] QoSSIG BOF

From: Yoram Bernet <[email-masked]>
Date: Sat, 22 Jan 2000 12:22:16 -0800

There is a draft in the ISSLL WG, that sprecifies aggregate RSVP. It is
authored by Fred Baker and others. Seems to do much of what you seem to be
interested in doing...

Y

-----Original Message-----
From: Ping Pan [mailto:[email-masked]]
Sent: Saturday, January 22, 2000 6:58 AM
To: Martin Karsten
Cc: Yoram Bernet; [email-masked]; RSVP; [email-masked]
Subject: Re: [Diffserv] QoSSIG BOF

Martin Karsten wrote:
> 
> Along this line, the following question comes to my mind.
> 
> RSVP has been designed to carry per-flow reservations, so SENDER and
SESSION
> objects are expected to be host or multicast group IP addresses. Is anyone
> aware of a fundamental problem of extending these to subnet addresses as
> well in order to signal aggregate requests?
> 

Jim Boyle had written a draft a couple of years ago. He suggested to use
CIDR blocks in the SESSION.

> I expect that potentially some kind of new "filter styles" would be needed
> to deal with a situation where a single sender address is an element of a
> subnet address. Alternatively, would a session to a single address and a
> session to a subnet be subject to any kind of merging? But then again, I
> haven't thought about it in detail...

Hmmm... curious. What are the possible rules for route prefix merging?

First of all, I think only BGP does this kind of thing. By applying
route aggregation in RSVP, your scheme may break the routing policies
and filters in the network. Second, RSVP is a signaling protocol, not
sure you want it to do routing protocol's job. ;-)

- Ping

---

From: Ping Pan <[email-masked]>
Date: Sun, 23 Jan 2000 04:17:24 -0500

> authored by Fred Baker and others. Seems to do much of what you seem to be

Hi,

In Section 3 of our BGRP draft 
(http://www.ietf.org/internet-drafts/draft-pan-bgrp-framework-00.txt),
we had listed a lot of others work. Please take a look. 

BTW, Fred Baker was one of the first to bring out real life experience
to suggest that RSVP scalability was a real problem.... Thanks!

- Ping

---

From: Fred Baker <[email-masked]>
Date: Tue, 25 Jan 2000 09:13:51 +0100

>to suggest that RSVP scalability was a real problem.... Thanks!

If by that you mean that I am one of the co-authors on the RSVP
Applicability statement in RFC 2206, guilty as charged. That said, I think
the scaling issues are highly overstated. Per-microflow reservations were
never intended to scale to OC-192 speeds, and need some form of aggregation
to do well there. But our RSVP implementation has no trouble running
upwards of ten thousand reservations given bandwidth to reserve for them
and a process or implementation appropriate to the situation. My
observation is that people have historically used the perception of scaling
limits to mean they don't have to think about RSVP, rather than trying to
address them realistically. 

The notion found in the diff-serv architecture, that we can simply assume
that in some region there is enough bandwidth that simple queuing will
resolve the issue, is also problematic. If there is a low loss low delay
core - a core which is simply swamped with bandwidth - then I assure you
that there is congestion at the edges of that core. This has to be
realistically addressed if we are going to deploy an Internet service which
is perceived as acceptable for VoIP and video on IP.

---

From: Ping Pan <[email-masked]>
Date: Tue, 25 Jan 2000 08:13:30 -0500

Fred Baker wrote:
> and a process or implementation appropriate to the situation.

True. 10K reservations, is that the max? In a full-meshed network, it
translates to 100 connectivity points. What if we are not reserving
bandwidth for one OC-192 link per se, but managing MPLS tunnels for a
couple thousand domains?

- Ping

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 26 Jan 0 10:24:50 JST

Fred;

> Per-microflow reservations were
> never intended to scale to OC-192 speeds,

You were too short sighted, then.

> and need some form of aggregation to do well there.

If the aggregation were ever possible, it could have been an option.

							Masataka Ohta

---

From: Christian Kuhtz <[email-masked]>
Date: Tue, 25 Jan 2000 22:30:10 -0500

> You were too short sighted, then.

While this sort of bashing may seem fashionable, perhaps it's be good to back
it up with some ammo.  

Instead of hurling insults around, perhaps I may suggest to consider the 
following question: Do you really _need_ to distiguish per-microflow
reservations on a very large backbone or is it perhaps true that at points of 
very high traffic aggregation you can aggregate reservations?  If so, you don't
need to maintain microreservations across very large pipes, it's sufficient
to spoof them at the edge etc.

The world isn't perfect, and quite happily so.  Why do reservations have to be
*all* the time if perhaps it is sufficient to be inside a certain bucket?  So,
if that's acceptable, you don't need to carry microreservations, you can
aggregate them into larger buckets of reserved (or allocated rather) capacity.

Case an point, some voice apps are perfectly happy at x latency. And they won't
even get close to violating the ITU-T specs or have any other perceivable 
impact even if you move up or down within a window that's perhaps as wide as
30ms.  Latency is obviously just one parameter, but this is an example to 
illustrate a point.
 
While it may be a, perhaps academically, interesting goal to have perfect
microreservations @ <insert your favorite mondo pipe>, I don't see the real
world return on investment here at the present time and for the for me 
foreseeable future.  These things have to stand a business case at some point,
unless you believe in engineering in a vacuum.  Then again, in the latter case,
it does have the advantage that noone can hear you scream.

At the present time, I consider the business case for microreservations at
very large scales a little weak to say the least.

If you disagree, please elaborate with an example to illustrate your argument.

If I misunderstood, set me straight.  I am wearing my castiron underwear and
fasionable kevlar suit, standard issue for the netheads among the bellheads.
So, roast away.  Damn cold in Atlanta right now.

Cheerios,
Chris

-- 
Christian Kuhtz                                     Architecture, BellSouth.net
<[email-masked]> -wk, <[email-masked]> -hm                       Atlanta, GA
                                                    "Speaking for myself only."

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 26 Jan 0 13:23:39 JST

Christian;

> While this sort of bashing may seem fashionable, perhaps it's be good to back

Yeah! Fred should have backed up his opinion that the aggregation were
possible. And you?

> Instead of hurling insults around,

There is no insult. It is simply short sighted not to consider
OC-192 seriously and have vague expectation on aggregation. 

> perhaps I may suggest to consider the 

There are a lot of reasons.

Can you, for example, imagine multicast with branches everywhere?

							Masataka Ohta