RE: [Diffserv] QoSSIG BOF

[Yoram Bernet <[e-mail]>]

If you recall, I never opposed the formation of a forum to discuss signaling
issues. What I opposed was scrapping RSVP. My suggestion was that the forum
should take RSVP as its opening position and then work out how to modify it
to suit the requirements. So far, the sense I get from the bof proposal is
that the proposing folks are not familiar with the progress that has been
made in adapting rsvp. 

For the record - I am not enamored with RSVP per-se. I am enamored with the
notion of *progress*. In my opinion, the best way to progress is to pick a
protocol and stick with it, modifying it and learning from it as we go. We
are five years into this cycle with RSVP. Venodrs have the code, there are
public code bases, there is research showing which parts of it work well and
which do not. If we are ever to get an end-to-end QoS story in place, we
stand to do so by remaining focused on an evolutionary path, not by
distracting everyone with some new panacea...

Yoram

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


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/