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

Curtis Villamizar <curtis@ans.net> Wed, 25 October 1995 18:26 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15239; 25 Oct 95 14:26 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa15235; 25 Oct 95 14:26 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id NAA16590; Wed, 25 Oct 1995 13:51:11 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id OAA26823 for rolc-out; Wed, 25 Oct 1995 14:00:25 -0400
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id OAA26814 for <rolc@nexen.com>; Wed, 25 Oct 1995 14:00:22 -0400
Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id NAA16550 for <rolc@nexen.com>; Wed, 25 Oct 1995 13:49:03 -0400
Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.6.12/8.6.12) with ESMTP id NAA17659; Wed, 25 Oct 1995 13:59:46 -0400
Message-Id: <199510251759.NAA17659@brookfield.ans.net>
To: kandlur@watson.ibm.com
cc: curtis@ans.net, yakov@cisco.com, rolc@nexen.com
Reply-To: curtis@ans.net
Subject: Re: Last Call for draft-ietf-rolc-apr-00.txt
In-reply-to: Your message of "Tue, 24 Oct 1995 17:02:56 CDT." <9510242102.AA30179@vindhya.watson.ibm.com>
Date: Wed, 25 Oct 1995 13:59:45 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Curtis Villamizar <curtis@ans.net>
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/

In message <9510242102.AA30179@vindhya.watson.ibm.com>om>, Dilip Kandlur writes:
> 
>     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.

I acknowlege that this belief exists.  If this delay was significant,
it would favor a direct VC.  There also exists a beleif that
predictive service not offerred by ATM SVCs will make better
utilization of available bandwidth while meeting the requirement of a
large class of applications.  This would favor shared VC.

The point I tried to make was not be try to bias the choice of
technology in an architecture document and to be fair in including all
of the architectures for providing QoS under consideration within the
IETF.  This way the architecture document will stand regardless of
which selection(s) prove to hold the most significant benefits.

Curtis