Subject: Re: [Diffserv] QoSSIG BOF - sceleton

From: Bora Akyol <[email-masked]>
Date: Tue, 01 Feb 2000 21:49:47 -0800

Frankly, I think we should focus on reinventing UNI/PNNI for the MPLS world and
then we can reinvent it one more time for IP, just got to keep everyone busy.
Also we *must* remember to change the name since otherwise we may look like we
are not earning our keep.

As far as I am concerned, there are two types of signaling protocols, soft-state
and hard-state. RSVP without HELLO extension is a soft-state signaling protocol
that can be extended rather easily as MPLS extensions have shown. It is
well-understood. UNI/PNNI is a set of hard-state protocols that were developed
for ATM but essentially are used to establish flows and QoS contracts within a
network. Moreover, UNI essentially can be made to run over a connectionless
network akin to TCP/IP.

If you look at these protocols you will find that they meet the signaling
requirements for a variety of environments.

I think that instead of getting hung up on yet another signaling protocol, we
should focus on the information that needs to get distributed and efficient
(compact) ways of representing that information both between domains (or ASs) or
within a domain. Once, the information we need to distribute is well-understood,
the appropriate mechanisms will be easier to develop. I believe that at least the
policy WG is working on this.

Also, I worry about the network operator acceptance of automated signaling and
negotiation protocols for communication between domains since anything dynamic
exposes risk and stability issues.

Regards

Bora Akyol

Sorry, could not resist.

Bora

Istvan Cselenyi wrote:

> 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 ....
>
> > > 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?
>
> 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.
>
> >  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.
> >
> > > 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.
>
> (Thanks for patronizing...)
>
> --------------------------------------------------
>                 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: "Istvan Cselenyi" <[email-masked]>
Date: Wed, 2 Feb 2000 17:27:13 +0100

Hi Bora,

My comments are inserted below...

> are not earning our keep.

:-) You are kidding, aren't you? 

> and hard-state. 

... and stateless, such as the six DSCP bits in DiffServ, which signal 
the required treatment for each packet without forcing the routers to 
store states for the sake of signaling

> RSVP without HELLO extension is a soft-state signaling protocol

Yes, but there is a point when one shall get some fresh air before going 
further.

> policy WG is working on this.

I think QoS signaling protocols and the QoS related info they carry are 
orthogonal in most cases. Thus if the Policy WG is already defining the 
QoS info objects we could look at the enhancement of signaling 
protocols in our BOF.

> exposes risk and stability issues.

I see your point, but there are already a couple of autonomous and 
dynamic solutions in internet and operators still like it :-)

Regards
Istvan