Subject: Re: LDP and RSVP, OSPF, BGP, etc.

From: Ajay Joseph <[email-masked]>
Date: Tue, 23 Dec 1997 11:31:45 -0500

Zheng Wang wrote:
> 
> > This approach (setting up explicitly routed LSPs first and then
> > using RSVP to allocate resources) has always seemed difficult to
> > me.
> 
> Well, RSVP in fact separates path setup and resource reservation.
> The PATH messages create "path state" while the RESV messages
> create "reservation state" by following the path set up by the PATH
> messages.
> 
The RSVP method of signaling for resource reservation sounds quite
broken as the the path message route which actually takes a Best Effort
route to the receiver is then used by the RESV message which actually
makes the reservations. The receiver has no concept on the best CoS
specific paths back to the sender using RSVP. If the goal of MPLS and or
Diff Services is to provide some minimum set of CoS guarantees (not just
waving of hands) I would argue that we need to look at IP based COS as a
combination of efforts that include 'CoS based IP routing'.
The other efforts being a signalling protocol such as RSVP or its
variant, Diff/Int Services and MPLS.
> Cheers
> Zheng

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 23 Dec 1997 23:52:49 +0000

In message <[email-masked]>, Ajay Joseph typed:

 //The RSVP method of signaling for resource reservation sounds quite
 //broken as the the path message route which actually takes a Best Effort
 //route to the receiver is then used by the RESV message which actually
 //makes the reservations. 

hunh?

it is HIGHLY likely that the path taken by best (current) effort will
after a reservation, be acpablel of providing the requested QQos, or
else there is no such path

higher level call admission considerations tells us this....

 //specific paths back to the sender using RSVP. If the goal of MPLS and or
 //Diff Services is to provide some minimum set of CoS guarantees (not just
 //waving of hands) I would argue that we need to look at IP based COS as a
 //combination of efforts that include 'CoS based IP routing'.
 //The other efforts being a signalling protocol such as RSVP or its
 //variant, Diff/Int Services and MPLS.
 
omigod - i see COSrouting appearing as a new WG......:-)

far as i'm concerned, remove the academic debate about multi-path
routing and just stick to "its a satellite or its terrestrial for now)
and don't give me LEOs - they don't have the capacity to be a serious
piece of the picture....

 cheers

   jon

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Dec 97 12:32:36 JST

Jon;

>  //makes the reservations. 

Surely, it is a broken approach. But it is not necessarily an RSVP method.

As is documented in RFC 2205,

      direction.  (In the future, some routing protocols may supply
      reverse path forwarding information directly, replacing the
      reverse-routing function of path state).

it is a problem to be solved by QoS routing.

You may be interested in my research result (see INET'97) that the
direction of determining the route by RESV and let PATH fllow, works
well with no scalability problems.

> else there is no such path

Jon, it may be a valid argument on a few hops over links with a
lot of bandwidth, but is completely wrong in the real Internet.

Approximation-by-best-effort approach does not scale that the
probability of sucessful reservation will rapidly decrease as
the network (and hop count) becomes large and network is often
100% utilized.

With 30 hops each with 95% of sucessful reservation probability,
the overall probability of end-to-end reservation success is
merely 21%.

Note that crank back approach does not work scalably. It needs
a lot of state on intermediate routers and it needs exponentially
many retries with hierarchical routing.

Note also that MPLS is not meaningful to this thread becasue all
the MPLS proposals have fundamental scalability problems with no
real performance benefit.

> higher level call admission considerations tells us this....

Experience on telephone network with simple topology and high
failure rate tells us nothing.

							Masataka Ohta

---

From: Rugelis <[email-masked]>
Date: Wed, 24 Dec 1997 11:29:34 +0200 (EET)

I THINK YOU GOT THE WRONG ADDRESS!!!!!!!!!!!!!
I DON'T KNOW YOU AND I DONT WANT TO GET YOUR EMAILS

DO NOT EVER WRITE ME ANYMORE PLEASE!!!!!!!!!!!!!!!!

---

From: Rugelis <[email-masked]>
Date: Wed, 24 Dec 1997 11:30:36 +0200 (EET)

---

From: Ajay Joseph <[email-masked]>
Date: Wed, 24 Dec 1997 09:59:20 -0500

> higher level call admission considerations tells us this....
That is a very strong statement to make. How can resources be reserved
simply based on paths which are computed based on static metrics and
hence do not relect any CAC and congestion taking place in the network.
As an ISP this is a very inefficient way of resource allocation in our
network. 

> and don't give me LEOs - they don't have the capacity to be a serious
Fine - but todays routing must some how be tied into resource allocation
in routers. The routing protocol must have the capability of indicating
its resource availability per class of service.
--Ajay--

---

From: Paul Ferguson <[email-masked]>
Date: Wed, 24 Dec 1997 10:18:27 -0500

>its resource availability per class of service.

That's a very simplistic remark to make, considering the complexity
involved.

An overview of any of the QoSR proposals will bear this out, methinks.

- paul

---

From: Ajay Joseph <[email-masked]>
Date: Wed, 24 Dec 1997 11:04:15 -0500

> That's a very simplistic remark to make, considering the complexity
Sure its simplistic given that we are at 35K ft right now.
> An overview of any of the QoSR proposals will bear this out, methinks.
Some of the scaling issues from the QoSR work stem from the fact that LS
updates are a function of the number of flows, me thinks this can be
improved significantly with aggregation based on Classes and the
classification of flows into an aggregate being done at the edges of the
network. 
--Ajay--

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 25 Dec 97 13:24:59 JST

> Some of the scaling issues from the QoSR work stem from the fact that LS

Some of the scaling issues???

What is the scaling issue of QoSR?

With a simplistic QoSR algorithm, I can see no scalability problem.

> classification of flows into an aggregate being done at the edges of the

Huuuuhhh?

Even with unicast only environment, all the attempt to aggregate flows
makes QoSR unnecessarily complex and increases the number and size
of messages without reducing the number of states.

Multicast makes it worse. 

							Masataka Ohta