The Routing Over Large Clouds Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1995-Oct> msg00088



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Last Call for draft-ietf-rolc-apr-00.txt

  • From: Yakov Rekhter <yakov@cisco.com>
  • Date: Wed, 25 Oct 95 19:31:00 PDT
  • cc: rolc@nexen.com
  • X-Orig-Sender: owner-rolc@nexen.com

Curtis,

> > 1) Whether allowing SVC management to be directly controlled by applications,
> >    and specifically by the QoS and/or traffic requirements of the application
> > s
> >    is a good idea or not
> 
> If the application specifies QoS and traffic characteristics and
> indirectly controls SVC management, then we are in agreement.  Then it
> doesn't matter if the box it is running on sets up a VC or if it sits
> on an ethernet and the next hop sets up a VC.  Are we in agreement on
> this?

You are arguing that there needs to be a level of indirection between the
application specified QoS and/or traffic characteristics and the SVC management.
I have no problem with this, but I think that always requiring this level
of indirection is too restrictive. How about if we'll say that SVC management
should be driven by the QoS and/or traffic requriements of the application.

> 
> > 2) Whether allowing SVC management to be directly controlled by applications
> >    and specifically by the QoS and/or traffic requirements of the application
> > s
> >    runs counter to rsvp and int-serv directions
> 
> Not allowing for the possibility of that information being passed to
> an adjacent box (specifically for when SVCs are not availaible on the
> box running the application) would be counter to the rsvp and int-serv
> directions.  Are we in agreement on that?

Agreed.

> 
> > So, I would suggest we'll debate these two questions separately.
> 
> OK.
> 
> > Wrt to the first question, I've yet to see any compelling technical
> > argument that would show why placing SVC management ("local/remote",
> > "dedicated/shared") under the control of QoS is a bad idea.
> 
> But I'm not arguing that the local/remote not be QoS based.  If you
> look at the quote that you responded to it says "the application
> passes QoS requirement or traffic characterisitics through RSVP
> (possible passed it within the same box) and indirectly controls SVC
> management, not directly".

And I'd like to finess the issue of whether this control is done directly
or indirectly. I think it should be sufficient if we'll just say that "SVC management
should be driven by the QoS and/or traffic requriements of the application".

Yakov.