Re: [Diffserv] QoSSIG BOF

[Joakim Bergkvist <[e-mail]>]

Im glad you agree with me that RSVP might be designed for a sligthly
more complex problem than the one we are facing. In this case it should
be natural to create a new formum for alternatives in order to find out
if a slimmer aproach with diffrent properties is better tailored to the
need.

/ Joakim, Telia Research


Yoram Bernet wrote:
> 
> 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/