Subject: [Diffserv] Re: A new draft on inter-domain level resource management

From: Ping Pan <[email-masked]>
Date: Mon, 17 Jan 2000 18:03:47 -0500

Curtis Villamizar wrote:
> 
> 
> You should be clear in your discussions of BGRP what problem it is you
> are trying to solve.  BGRP is trying to solve the scalability problems
> that arrise when using MPLS for microflows.  This is what is commonly
> referred to as QoS routing.
> 

Hi, Curtis,

BGRP is not a routing protocol. It uses the information provided by BGP4
(specifically, AS_PATH and NEXT_HOP attributes) to set up reservation
trunks in the backbone. First, it involves only with BGP border routers.
Second, it further reduces the number of "flows" a border router has to
maintain.

I think QoS routing is to periodically advertise link/resource
information throughout the network, which is not really what we are
targeting here. Sorry about the confusion.

> [ aside:
> 
> This is why I have insisted that we not confuse the term "QoS routing"
> with "traffic engineering".  The two have similarities, but some very
> significant differences.  Traffic engineeering as it is currently
> practiced by ISPs is not concerned with microflows (even very large
> ones) and in a stable network would be expected to generate zero
> setups despite huge numbers (could be hundreds of thousands or
> millions) of microflows appearing and going away per second.
> 

For traffic engineering, there could be many long-lived "flows" that
established by the ISP's. The cost of setting them up in terms of
processing CPU cycles and storage space may not be a big deal, but the
cost of maintain these "flows" may be a big problem for the routers.
Soft-state is a good idea to allow the routers to adjust to route
changes. But the side-effect here is that soft-state requires the
routers to maintain a copy of all the states. If there are thousands or
millions of microflows that need to refresh, I doubt the routers can
sustain the CPU cost.

> For traffic engineered backbones, the total number of LSPs is bounded
> by the number of LSRs in the network and the number of classes of
> service offerred.  Most providers estimate the total number of LSPs
> that will be needed in their network to be on the order of 10^3 or
> 10^4.  The number going through any one LSR should be even smaller.
> The setup rate should normally be zero or very close to zero except in
> response to network failure.

Actually, as being pointed out in RFC2430 (PASTE by Tony Li and Yokov
Rekhter), the number of trunks (or LSP's, or reservations) is N * (N-1)
* C, where C is the number of service classes, N is the number of
MPLS-speaking routers. This is the N**2 problem we are talking about
here. In case of intra-domain, N is the number of border routers at
backbone edge, and is in the range of ~100. To setup a full-meshed
network to support traffic engineering, the ISP needs indeed 10^3 or
10^4 trunks. The current RSVP/LDP should have no problem for
intra-domain.

But to setup such trunks over multiple domains, we will have problem
here. As pointed out in our draft, we have thousands of AS's and routes
over the network. To provide a similar level of traffic engineering
functionality in multi-domain environment would require millions of
trunks. We proposed a new protocol here to provide trunk setup mechanism
for inter-domain only.

When routers use BGRP to setup inter-domain trunks, the border routers
will interface with intra-domain signaling protocols to set up internal
trunks. BGRP is hopping between the border routers to trigger LSP
setups.

> 
> Some of those estimating higher than 10^4 LSPs tend to be interested
> in voice and counting on doing one LSP per T1 voice trunk (not even
> aggregating to trunk group) rather than engineering IP networks.
> Those who believe that MPLS traffic engineering should be used solely
> to provide more efficient routing through provider backbones may
> consider this broken by design (though it may be essential to some
> VoMPLS approaches, not that it would be the first time something
> broken by design was proposed within or outside the IETF).
> 

IMHO, I hope the ISP's consider traffic in terms of service classes and
bandwidth only (as being defined in DiffServ), not in terms of
application. The end users at network edge can choose any service class
to carry their voice depending on how much they are willing to pay. 

>  ... end of aside]
> 
> 
> A question for the MPLS WG is "is this a problem the MPLS WG is trying
> to solve?"  Perhaps the MPLS deployment WG in the OPs area can help
> provide an answer.
> 

I have the same question. That's why I send the note to multiple lists.
;-)

> Curtis

Regards,

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

_______________________________________________
diffserv mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 18 Jan 2000 11:14:23 +0000

In message <[email-masked]>, Ping Pan typed:

hmm - interesting - thouhg i am still not sure why you can't work on
an evolutionary path with RSVP rather than a whole new protocol 

but alternatively,
what i'd like is to do a joint re-design of inter-domain routing, and
inter-domain signaling rather than just pile more and more things into
BGP and new signaling protocols...one possibility:

 to use NIMROD architecture 
http://ana-3.lcs.mit.edu/~jnc/nimrod/docs.html
 to exchange two types of thing:

1/ tag a map for a region (aka core, or trunk area) with current traffic
load advertisement (what one wishes to export as effective available
capacity -the map based approach alows you to scale state and size of
exchanges...the use of IP or AS numbers or MPLS labels as the means of
description of flows or aggregations is, imho, doomed to fail...

2/ tag requests for class based trunk adaptive sized DELTAs in
capacity requests from routers at the edge
of such a region - delta's allow you to scale the message rate, as
well as the state - as the rate of edge device requests increases
(iptel call setup or teardown rate goes up), you just modify the
deltas to anticipate the desired trunk sizes...rsvp can be modified to
do this relatively easily (documents on aggregate reservations only
need modest changes in identifying who is requesting what of whom...)

some discussion from noel chiappa and others might ensue (pnni
too...?)

 cheers

   jon

---

From: Ping Pan <[email-masked]>
Date: Tue, 18 Jan 2000 08:08:02 -0500

> an evolutionary path with RSVP rather than a whole new protocol

We've tried very hard to address the scaling problem with RSVP in the
past year or so. Lou Berger, George Swallow, Lixia (and her students)
and us have tried to enhance RSVP soft-state properties in various
drafts. At this point, I believe RSVP (and its LSP extension) will have
no problem whatsoever to handle intra-domain requirements. But RSVP does
have the N**2 problem. When you look at the data we had gathered in
Section-2 of our draft, any signaling protocol with N**2 property would
be difficult work in inter-domain environment.

One of the issues in RSVP is the notion of "route-pinning" at PATH
processing time. This forces the routers to remember every reservation
sender. At RESV processing time, the routers need to map the RESV to the
previous PATH. This means that the routers need to maintain N**2 states.
I think this is designed to prevent reservation looping problem. (BTW,
Bob Braden told me a couple of years ago that during the RSVP design,
people had thought about not storing PATH at routers, but...)

In BGRP, we still use the two-pass reservation mechanism. But the PROBE
messages (equivalent to RSVP PATH) gather the route information, and the
receivers use the gathered routing data to construct sink-trees. At
reservation time, the routers need only to remember sink-tree
information, which is O(N).

Later,

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 18 Jan 2000 09:57:57 -0600

Please people, drop the diffserv list from this thread.

Thanks

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Attend INET 2000: http://www.isoc.org/inet2000
Non-IBM email: [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 19 Jan 0 8:37:47 JST

Ping Pan;

> be difficult work in inter-domain environment.

As I have pointed out in RSVP-related WGs and several research papers,
RSVP has no scalability problem from the begining.

So, I agree with you that it is very hard (impossible) to solve
your problem, because the problem does not exist.

> previous PATH.

No. As I pointed it out in some I-D and the INET'97 paper, the solution
is to route RESV first and let PATH follows the route.

Note that route stabilization is easy that route-pinning is not
necessary at all.

There are simple reasons why BGP like policy can not be applicable to
resource reservation. But it seems to me that the topic is to hard
for you to understand.

							Masataka Ohta

---

From: Ping Pan <[email-masked]>
Date: Wed, 19 Jan 2000 10:46:03 -0500

> RSVP has no scalability problem from the begining.

Huh? Please provide the pointers to your draft.

> your problem, because the problem does not exist.

Man. This is deep! 

> resource reservation. But it seems to me that the topic is to hard

In the past few years, sir, you have been insulting many people in
public without much technical input. It's not the topic too hard for me
to understand, rather it's your attitude that is too hard for me to
understand. Please provide meaningful technical input NICELY.

Thank you!

- Ping

---

From: Ping Pan <[email-masked]>
Date: Fri, 21 Jan 2000 15:05:10 -0500

Istvan Cselenyi wrote:
> 
> Reading Ping's and earlier threads [1-3] and works [4-11] it seems that
> there are many people who want to contribute to the future of signaled
> QoS, 

As for end-user QoS signaling protocol, here is another one. ;-)

http://www.cs.columbia.edu/~pingpan/projects/yessir.html

Since I am implementing it on FreeBSD as we speak now, and changing the
draft as I code, so no official draft for it yet. But we should have
something (draft plus working code) soon.... My previous implementation
was on IBM routers, and many things have changed since then. ;-)

- Ping

---

From: "Istvan Cselenyi" <[email-masked]>
Date: Fri, 21 Jan 2000 20:53:09 +0100

Reading Ping's and earlier threads [1-3] and works [4-11] it seems that 
there are many people who want to contribute to the future of signaled 
QoS, but there is no IETF charter for aggregating all these good (not 
best :-) efforts since  

* the DS WG excludes new signaling by (re)definition 
* the MPLS WG deals with QoS routing and TE which are different
* the ISSLL WG doesn't really suit to DS
* the RSVP WG is closing done

Shall we start with a BOF in Adelaide?

/Istvan

------------------------------
Links

[1]  http://www-nrg.ee.lbl.gov/diff-serv-arch/msg00057.html

[2]  http://www-nrg.ee.lbl.gov/diff-serv-arch/msg03288.html

[3]  http://www-nrg.ee.lbl.gov/diff-serv-arch/msg04872.html

[4]  http://icawww1.epfl.ch/srp/

[5]  http://www.it.kth.se/~gk/Tyrrhenian-ws.ps

[6]  P. White, J. Crowcroft, A Case for Dynamic Sender-Initiated 
Reservation in the Internet, Journal on High Speed Networks, Special 
Issue on QoS Routing and Signaling, Vol 7 No 2, 1998  

[7]  A. Eriksson, C. Gehrmann, "Robust and Secure Light- weight 
Resource Reservation for Unicast IP Traffic", International WS on 
QoS'98, IWQoS'98, May 18-20, 1998  

[8]  http://search.ietf.org/internet-drafts/draft-gibson-sip-qos-resv-00.txt

[9]  http://search.ietf.org/internet-drafts/draft-sinnreich-interdomain-sip-qos-osp-00.txt

[10]  http://search.ietf.org/internet-drafts/draft-ietf-manet-insignia-01.txt

[11]  http://search.ietf.org/internet-drafts/draft-bergkvist-boomerang-spec-00.txt

--------------------------------------------------
                Istvan Cselenyi                      
 Telia Research AB           Phone: +46-8-7138173
 Vitsandsgatan 9 B431          Fax: +46-8-7138199          
 S-12386 Farsta            Mobile: +46-70-3228801  
 Sweden        E-mail: [email-masked]
--------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Jan 2000 16:45:13 -0600

I agree that we need a normal standard of personal politeness, but more
to the point

  Please drop this thread from the diffserv list. It is way outside our charter.

Thanks
  
  Brian Carpenter
  diffserv co-chair