Subject: An apology...

From: Yoram Bernet <[email-masked]>
Date: Mon, 24 Jan 2000 08:19:22 -0800

A number of folks have pointed out that it was impolite of me to suggest
that those who are calling for a new QoS signaling protocol are calling into
question the competence of the original developers of RSVP.

I apologize.

I do believe however, that the statement which appeared in this exchange:
"We believe that there are much simpler ways of solving the same problems"
is rather arrogant and is indicative of an all too common tendency to scrap
what has been done so far and invent something new. 

I'm calling for us to have the discipline to study the work that has been
done and to clearly articulate where and why it falls short and what of it
can be salvaged, before deciding that something entirely new is necessary...

Y

---

From: "Andrew T. Campbell" <[email-masked]>
Date: Mon, 24 Jan 2000 13:52:39 -0800

> can be salvaged, before deciding that something entirely new is necessary...

Bravo!

---

From: Joakim Bergkvist <[email-masked]>
Date: Mon, 24 Jan 2000 20:34:46 +0100

> what has been done so far and invent something new.

Sure, I stand properly corrected and do apologize! 

Our assumption has been that the requirements on a resource reservation
protocol is actually simpler than what RSVP set out to solve. For
example RSVP was designed to support hetrogenous endpoints. We have no
such scenario and therefore do not have to keep per flow states in all
signalling nodes. This in turn enables us to do CAC based on measured
rate or by using the cumulative rate of the refresh messages over a time
window. 

During the work with our own prototype we have discovered other people
working with like presumtions. So far these ideas have been rejected by
the diffserv BOF who don't want to discuss signalling at all for the
moment. They have also been rejected from the RSVP BOF since it has been
dedicated for work with RSVP only. 

From our perspective a good starting point for a new BOF would be to
synchronize the diverse implementations under a common framework. We
would then have a basis on which to discuss the loss of functionallity
imposed by a simplified protocol.

My personal belief is that the RSVP group should maintain it's focus and
aim for a quick standardisation. In this case I doubt that it would be
constructive to examine scenarious which require conceptual changes to
the protocol. This does not mean that such changes could not be
implemented as a new "runmode" of RSVP!. In the meantime I propose a BOF
for the organic eolution of RSVP into full standard AND a BOF for
looking at an RSVP light mode for a simplified scenario using a
potentially different transport mechanism.

/ Jocke

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

---

From: Omar Elloumi <[email-masked]>
Date: Tue, 25 Jan 2000 11:13:21 +0100

> > can be salvaged, before deciding that something entirely new is necessary...

A good starting point for such a study is to try to identify the traffic
which needs reservation and then to quantify the number of flows
that need reservation and how many of them will go through
several diffserv domains. Then may be we'll come to the conclusion
that RSVP (with may be some aggregation schemes) is enough.

I, somewhat, disagree with the analysis done by Ping which
is a worst case study. Based on Internet traffic traces we can not
say, a priori, if RSVP will scale or not. We need instead to
determine the number of flows that need reservation which
has nothing to do with the number of flows in the Internet
(e.g. we don't, or rarely, need a RSVP
session for TCP individual flows).

One question that come in mind is: do we need resource
reservation for VoIP traffic in DiffServ networks?

--
____________________________________________________________
Omar Elloumi

Alcatel Research - Network Architecture - Traffic Technology

Francis Wellesplein 1, 2018 Antwerp, Belgium

Phone: + 32 3 240 78 33
Fax:   + 32 3 240 99 32
http://www.alcatel.com/crc/
____________________________________________________________

Opinions expressed are those of the sender and do not reflect Alcatel policy or
agreement

---

From: Ping Pan <[email-masked]>
Date: Tue, 25 Jan 2000 07:52:59 -0500

> that RSVP (with may be some aggregation schemes) is enough.

First of all, please read RFC2430 (PASTE) and check out the data in
http://www.merit.edu/ipma/reports/ and
http://www.employees.org/~tbates/cidr-report.html.

Reservation protocols distribute "flow" information in the network. The
flow can be UDP streams (such as RTP applications), TCP flows, MPLS
LSP's, optical connection info. etc. First, let's take a look at the
dimension of the network (6000+ AS, 60K routers....) with almost linear
growth. Then, let's take a look at how to maintain reservation states
efficiently within the network (soft-state, hard-state) while the route
is going up/down constantly. Now, let's discuss if a protocol is good
enough or not. In our work, we concluded one protocol won't do the job
if there is no hierarchy.

In our work, we're not trying to:
(1) Trashing RSVP: RSVP is fine for intra-domain traffic engineering.
Like it or not, it's in the process of being deployed for MPLS by
vendors already. Let's move on already.
(2) Yet another ivy-tower academic exercise: we're trying to come up
with a real solution to meet the real demands for the emerging MPLS
deployment and carrier-level resource management. Some may think the
protocol is complex. But you're somewhat familiar with BGP, this is
quite simple.
(3) End-user reservation protocol: There is bo DiffServ deployment
within the network today, so I doubt we will see end-user reservation
application very soon. Let's see how good RSVP is for VoIP some time in
the near future.

> say, a priori, if RSVP will scale or not. 

If N is the number of ASes (that is, 6000), would you think a router can
handle O(6000**2) states? ;-)

> We need instead to

Again, we're not talking about end-user reservation protocol here.

> reservation for VoIP traffic in DiffServ networks?

It's up the end users. Some people may feel fine with the existing
service, if all they want is to leave a voice mail, or making the call
3:00 in the morning. Some may want to have the best service by paying a
lot for it. Again this is end-user reservation issue.

BR

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

---

From: "Istvan Cselenyi" <[email-masked]>
Date: Tue, 25 Jan 2000 15:26:40 +0100

> session for TCP individual flows).

I agree with quantifying the scalability requirements what QoS signaling 
shall meet in the future (a good input to QoSSIG BOF).

However, you should not underestimate the amount of flows which can 
benefit from using QoS signaling. As of today, the amount of traffic over 
internet is just taking over the traffic carried in the entire telephony 
network. So imargine the situation in a few years when every telephony 
session is moved to the internet (what many of us wishes) and new kind 
of real-time applications are spreading all over...

> reservation for VoIP traffic in DiffServ networks?

Not, if you can assure the resources and do admission control in 
another way, e.g. promise the customer that she can always send and 
pray that transmission guys are quick enough in steadily increasing the 
extra net capacity what you need for overprovisioning ...

Istvan

--------------------------------------------------
                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: Carol Iturralde <[email-masked]>
Date: Tue, 25 Jan 2000 10:12:58 -0500

> can be salvaged, before deciding that something entirely new is necessary...

I agree entirely!

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 25 Jan 2000 17:30:01 +0200 (EET)

Istvan Cselenyi writes:

 > So imargine the situation in a few years when every telephony 

telephone sessions will always be so small percentage of overall
internet traffic that we don't need any signalling for that.  diffserv
bits in the packets are well enough.

-- juha