The Routing Over Large Clouds Mailing List Archive by date

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



[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: Dilip Kandlur <kandlur@watson.ibm.com>
  • Date: Tue, 24 Oct 95 17:02:56 -0500
  • Cc: yakov@cisco.com, rolc@nexen.com
  • X-Orig-Sender: owner-rolc@nexen.com

Curtis,
a response to some of your comments.  (I inadvertantly sent out the
last message.)

    To exploit capabilities provided by the SVC-based Data Link
    subnetworks we propose to allow SVC management to be directly
    controlled by applications,

 This is a bad idea and runs counter to rsvp and int-serv directions.

What we mean here is QoS requirements of applications that may be
expressed through RSVP.  In keeping with the int-serv work, we should
not assume RSVP to be the only mechanism to specify QoS.  It is not
counter to rsvp or int-serv directions.

    We propose certain modifications to the existing IP model in order to
    support both the applications with QoS requirements that could
    justify a dedicated SVC, and applications that would rely on the
    router-based infrastructure.

 The implication throughout is that an SVC is needed to support QoS.

The implication is that QoS requirements would be considered as a
guide to setup SVCs.  Yes, there is also a belief that an SVC would
provide better QoS (e.g. delay) since it avoids IP level handling
costs at intermediate nodes.

-- Dilip.