Subject: RE: [Diffserv] QoSSIG BOF

From: Yoram Bernet <[email-masked]>
Date: Mon, 24 Jan 2000 12:57:13 -0800

below...

> -----Original Message-----
> From: Istvan Cselenyi [mailto:[email-masked]]

> > 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. 
> 
> The danger with looking only at RSVP could be that we do not realize 
> its drawbacks.

Interesting. I would suggest that the best way to see the drawbacks of RSVP
are to look at RSVP. Perhaps you meant something else?

 I propose to start with discussing a framework which 
> outlines what functionality and scaling we will actually need 
> in the area 
> of resource reservation within a few years.
> 

OK - no objection here.

> > 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. 
> 
> I'am afraid the "adaptation work" just increased RSVP's 
> complexity 

Like I said - I am afraid that the proposing folks are not familiar with the
progress that has been made. I'm not sure what work you are talking about,
but - the work I am talking about has been to:

1. describe how rsvp is used with aggregate traffic handling instead of
per-flow (significantly less complex and more scalable).

2. desrcibe how rsvp can be used to advertise policy information to be used
by the network without requiring complex quantitative parameters. again -
seems simpler.

3. a model by which only select admission control agents listen to rsvp.

> We should really work together in a constructive way and let the good-
> old RSVP to get some blood-transfusion from new-commer light-weight 
> protocols, otherwise people will think that only a miracle 
> can make QoS 
> signaling happen :-)

I'm all for that! Let me suggest that the newcomers should acquaint
themselves well with recent RSVP work and should be able to make a clear
statement as to exactly what 'problems' in RSVP they will be fixing.
> Istvan
Yoram

> --------------------------------------------------
>                 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: Joakim Bergkvist <[email-masked]>
Date: Tue, 25 Jan 2000 13:59:09 +0100

Yoram Bernet wrote:

> OK - no objection here..

---

From: "Istvan Cselenyi" <[email-masked]>
Date: Tue, 25 Jan 2000 14:36:19 +0100

Hi all,

I think we are getting closer to an agreement on the sceleton of the 
QoSSIG BOF. 

The goal is to "give fresh blood to QoS Signaling". Thus we shall call for 
presentation of alternative protocols which are solving specific 
*problems* what RSVP is facing with today or within some years. The 
problems shall be well defined and mapped to current RSVP work. 
Moreover the proposed concepts shall be verified based on 
implementation or simulations.  

Before and after the BOF we can identify the functionality really needed 
for resource reservation, as many proposed. This result of the BOF and 
related discussions is a framework for future QoS siginaling (which can 
be used either for RSVP version 2 or for making a brandnew signaling 
protocol depending on what is the faster and more effective approach).

Do you like it?

Istvan

some comments to Yoram ....

> are to look at RSVP. Perhaps you meant something else?

Nono, I meant what I wrote (as you probably see) but let's take a 
methaphore: most parents believe that their kid is the best one in the 
universe thus you need outsiders to get real critique. It's human nature.
 
> statement as to exactly what 'problems' in RSVP they will be fixing.

(Thanks for patronizing...)

---

From: Joakim Bergkvist <[email-masked]>
Date: Tue, 25 Jan 2000 17:30:21 +0100

Yoram Bernet wrote:

> ...

Kind of cheap rethorics here I get the impression you "are calling into question
the competence" ;-) of the people wanting to discuss alternatives to RSVP.

I personally believe the issues of explicit path messages and signalling states
are to firmly integrated into RSVP to allow for a simple downgrading. This kind
of radical sidestep would not be feiable in a logic extension of the closing
RSVP work without loosing a lot of momentum and time to market. Since there are
many with me arguing that a simpler solution for a simpler scenario is
suficcient it is vital for the credibility of the IETF to sustain a forum for
these issues. At least until it is clearly shown that RSVP is up to the task
without beeing so complex so as to giv an unreasonable advantage to gigant
companies with large resources.

/ Jocke