RE: [Diffserv] QoSSIG BOF

[Yoram Bernet <[e-mail]>]

OK - let me try and rephrase...

RSVP gives us a certain level of fucntionality in exchange for a certain
degree of complexity. This raises two questions:

1. Is it possible to offer the same degree of fucntionality more efficiently
(i.e. with a simpler protocol, less com-plexity)?

2. Is the degree of functionality offered by RSVP really required?

Bear with me while I address these one at a time:

In response to the first, consider that some pretty smart people spent a few
years developing and refining RSVP. If you trust that the people who
developed RSVP are reasonably good at what they do, and that they believe in
keeping things simple where possible, then - probably the protocol is about
as simple as it can be to offer the functionality it offers. Perhaps we
could spend another five years and provide the same level of functionality
with marginal improvements in efficiency/simplicity, but given that the
original developers of RSVP probably were pretty good at what they do, I
doubt that we could do much better with a new protocol *if* we want to offer
the same level of fucntionality. 

But - perhaps we don't need quite the leel of fucntionality offered by RSVP
(e.g. full receiver heterogeneity, other things). I actually believe that
there is some excess functionality built into RSVP that doesn't justify its
compelxity. So - we can claim that RSVP tried to do too much, scrap it all
and start over with another protocol that will be in development for five
years. Alternatively, we can look at RSVP, ask where it can be simplified
and how we might use a subset of it that is simpler and that achieves most
of the functionality that we need. That's really what's been happenning over
the last few years. We have been working to adopt from RSVP, those pieces
which provide the functionality we need. 

I hope that you folks that are proposing work on a new protocol are not
doing so because you think that the fucntionality of RSVP can be achieed
with a significantly lighterweight protocol. If you do - I think that you
are casting in doubt the competence of those who created it. Rahter, I
suspect that you are of the opinion that one doesn't need all the
functionality of RSVP and that thereofre, some complexity could be
eliminated. If so, then there are two options - 1) start all over. 2) adapt
existing stuff.

I tend to believe in adapting existing stuff where possible. 

Yoram 

-----Original Message-----
From: Joakim Bergkvist [mailto:[e-mail]]
Sent: Saturday, January 22, 2000 11:30 AM
To: Yoram Bernet
Cc: RSVP; diffserv; [e-mail]; [e-mail]
Subject: Re: [Diffserv] QoSSIG BOF


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

 

Yoram Bernet wrote:
> 
> 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:[e-mail]]
> Sent: Friday, January 21, 2000 11:53 AM
> To: RSVP; diffserv; [e-mail]
> 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: [phone]
>  Vitsandsgatan 9 B431          Fax: [phone]
>  S-12386 Farsta            Mobile: [phone]
>  Sweden        E-mail: [e-mail]
> --------------------------------------------------
> 
> _______________________________________________
> diffserv mailing list
> [e-mail]
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 
> _______________________________________________
> diffserv mailing list
> [e-mail]
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

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

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