Subject: RE: [Diffserv] QoSSIG BOF

From: Yoram Bernet <[email-masked]>
Date: Fri, 21 Jan 2000 17:10:36 -0800

Actually, in response to the comment:

"The ISSLL WG doesn't really suit to DS", I would point out that the ISSLL
WG has been working for some time on the mapping of RSVP/Integrated services
to DS. So - this statement is somewhat inaccurate.

Nonetheless, I do think that it is appropriate ot have a forum to continue
to discuss signaled QoS and its application. In fact, in the discussions
preceeding the closing of the RSVP group, it was suggested that an RSVP
implementation group might be formed. 

I would generally oppose the creation of a wroking group to start
standardizing new layer-3 qos signaling protocols. Rather, I would encourage
continuing the work on using RSVP in a scalable manner to unify the various
disparate layer-2 QoS mechanisms in an end-to-end manner (as well as layer-3
hop by hop mechanisms such as diffserv)...

Yoram

-----Original Message-----
From: Istvan Cselenyi [mailto:[email-masked]]
Sent: Friday, January 21, 2000 11:53 AM
To: RSVP; diffserv; [email-masked]
Cc: Ping Pan
Subject: [Diffserv] QoSSIG BOF

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-o
sp-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]
--------------------------------------------------

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

---

From: Martin Karsten <[email-masked]>
Date: Sat, 22 Jan 2000 13:08:39 +0100 (MET)

[removed some mailing lists]

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?

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

Anyone any ideas (or am I asking an old question)?

Thanks,
Martin

---

From: Ping Pan <[email-masked]>
Date: Sat, 22 Jan 2000 09:58:14 -0500

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

> 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: Joakim Bergkvist <[email-masked]>
Date: Sat, 22 Jan 2000 20:30:23 +0100

Yes Yoram we know you're fond of RSVP! but still.. In the face of the
known problems with RSVP we are several people who want to discuss
alternatives. So far there have not been a forum to discuss the
posibilities of alternative signalling. Instead the people behind these
has spent their time listing problems with RSVP (this is what you could
discuss in the RSVP BOF).
  
Pm sure you can tweak RSVP into doing anything but this is not really
the point. We beleive that there are much simpler ways of solving the
same problems. If we are right there is a solution which is
fundamentally simpler both in implementation and in performance
requirements. This would bennefit small vendors with limited resources
(not just Microsoft and Cisco). Lower performance requirements would
also mean less impact on design issues and a broader fit into the
current product range.

My belief is that the IETF as well as RSVP would bennefit from efforts
being spent on concrete solutions instead of finding problems with RSVP.
If Yoram is right problems will be solved and implementations will get
good enough to make RSVP happen before anyone can show a strong
alternative. If not maby there is a reason for it.. There is only one
way to find out and I'm not afraid!

/ Joakim Bergkvist, Telia Research

---

From: Stephen Casner <[email-masked]>
Date: Sat, 22 Jan 2000 12:11:17 -0800 (Pacific Standard Time)

On Sat, 22 Jan 2000, Joakim Bergkvist wrote:

> requirements.

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

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 22 Jan 2000 17:35:15 -0800

At 04:08 AM 1/22/00 , Martin Karsten wrote:
>objects are expected to be host or multicast group IP addresses. 

Few people knew this part of the RSVP history, so I would like to share
with you: in the very early version of RSVP, the packet filter was a bit
mask over arbitrary portion of the IP header. I vaguelly recall it was when
RSVP design moved to IETF, this bit mask approach was considered "too
inefficient" for implementation, and protocol+address+port combination was
chosen to identify packets that can use the reserved resource.

>Is anyone aware of a fundamental problem of extending these to subnet
addresses as
>well in order to signal aggregate requests?

There should be no problem in terms of RSVP as a signaling protocol, which
after all simply carries a bag of bits around and gets appropriate state
set up (an maitains it) at routers.

One issue that may deserve attention, which is not exactly an RSVP problem
per se, is how to estimate or control the total amount of packet flows that
may match a coarse packet filter (for example a BGP prefix), to assure that
the qualified load does not grossly exceed the allocated amount of resource.

>haven't thought about it in detail...

Experience has shown that any kind of merging can be a tricky business:-)

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 22 Jan 2000 20:19:24 -0800

>discuss in the RSVP BOF).

There might be some people who try to find problems with RSVP solely for
the sake of finding the problems (perhaps as materials for academic papers)

But majority of problems I have heard are from those who run into problems
with RSVP in real life (e.g. MPLS people faced problem with refresh
scalability). Identifying those problems seems a good first step in
developing viable alternatives.

>same problems. 

That sounds great.
Tell us your much simpler ways of doing the samething.  
(That would be a lot more productive use of the mailing list than bashing
RSVP)

Lixia

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 22 Jan 2000 20:09:13 -0800

At 06:58 AM 1/22/00 , Ping Pan wrote:
>and filters in the network. 

First of all, as I said earlier, merging is a tricky game, and I do not see
the need (extending that sentence would take time...)

having said that: no I do not think merging in RSVP packet filters should
break anything in routing.  As you mentioned below, RSVP is simply a
signaling protocol that sets up state following whatever paths given by the
routing protocol, and data packets check the forwarding table first before
they get into any QOS treatment. 

>Second, RSVP is a signaling protocol, not

---

From: Ping Pan <[email-masked]>
Date: Sun, 23 Jan 2000 03:53:25 -0500

> who believe they have a simple solution may not have reached the end

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: Ping Pan <[email-masked]>
Date: Sun, 23 Jan 2000 04:03:16 -0500

> developing viable alternatives.

Lixia,

Yes. Agree! I had talked to several developers last year. We all thought
that RSVP is taking a lot of CPU cycles. If a domain becomes too big and
the number of border-to-border connections increases, people will be
worried about the CPU shortage.

> (That would be a lot more productive use of the mailing list than bashing

Once again, agree. Bashing RSVP will not help. 

> Lixia

Regards,

- Ping

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 24 Jan 2000 08:33:22 +0000

>>the sake of finding the problems (perhaps as materials for academic papers)

well, in any "merely" academic conference or journal i have been
associated with, a paper that "solely found problems" would either be
finding interesting problems, or would be propsoing interesting
solutions, or both - academics are funny people (most the net was
developed by them:-)

but to be fair, there has been an increasing number of academic (and
other) people
in recent years submitting i-ds which would go in their annual researc
h report but not get into a good conference or journal - good includes:
(ACM/IEEE Transactions on Networking, ACM SIGCOMM, IEEE Infocom, ICNP,
NOSSDAV, Packet Video, and similar...)

 >>developing viable alternatives.

yes, the papers cited in this discussion mostly not only identify
problems, but also propose some viable alternatives - however  (as a
guilty party), the majority could be implemented as relatively modest
deltas (options, enhancements/configurations) to RSVP

 >>(That would be a lot more productive use of the mailing list than bashing

agree
on the topic of a BOF - i think it would be good IFF someone writes
down a good set of things that
a) would be good RSVP work items
b) would be useful (or at least are somewhat compelling) but can;'t
easily be seen to be implemted in the RSVP framework.

 cheers

   jon

---

From: JC Ferguson <[email-masked]>
Date: Mon, 24 Jan 2000 09:19:48 -0500

Ping Pan wrote:
[snip]
> worried about the CPU shortage.

Doesn't the refresh reduction draft address some of the CPU-related
issues?
jc

---

From: Ping Pan <[email-masked]>
Date: Mon, 24 Jan 2000 14:43:06 -0500

> Doesn't the refresh reduction draft address some of the CPU-related

JC,

Yes, to some degree.

The way I look at it is the following: a major contribution to the
reduction draft is to reduce the number of message on the wire. However,
no matter how much we compress the RSVP messages, we have to maintain
ALL the RSVP states at routers. That means, on receive, we still have to
walk through the flow table to update each individual RSVP flow. When
timer pops, we need to delete the time-out flows, etc. This is still
costly. BTW, I have not included the potential CPU cost on policy
look-up.

What we have proposed was to reduce the number the reservation states
altogether. I think this would be more cost-effective. Another advantage
in our proposal is to isolate inter-domain reservations at border
routers, and spare the internal routers from processing all the
reservation messages. This way, the ISP's can put the more powerful
routers at the border....

BR,

- Ping

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 22 Jan 2000 20:19:24 -0800

That sounds great.

Lixia

---

From: Stephen Casner <[email-masked]>
Date: Sat, 22 Jan 2000 12:11:17 -0800 (Pacific Standard Time)

---

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

Lixia,

Regards,

- Ping

---

From: Ping Pan <[email-masked]>
Date: Sun, 23 Jan 2000 03:53:25 -0500

Steve,

Thus, our work on BGRP

Best regards,

---

From: Joakim Bergkvist <[email-masked]>
Date: Sat, 22 Jan 2000 20:30:23 +0100