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

Hiroshi Esaki <hiroshi@ctr.columbia.edu> Thu, 26 October 1995 17:46 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18432; 26 Oct 95 13:46 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa18428; 26 Oct 95 13:46 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id NAA26162; Thu, 26 Oct 1995 13:15:44 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id NAA11925 for rolc-out; Thu, 26 Oct 1995 13:26:50 -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 NAA11916 for <rolc@nexen.com>; Thu, 26 Oct 1995 13:26:47 -0400
Received: from sirius.ctr.columbia.edu (root@sirius.ctr.columbia.edu [128.59.64.60]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id NAA26140 for <rolc@nexen.com>; Thu, 26 Oct 1995 13:15:19 -0400
Received: from mimas.ctr.columbia.edu (hiroshi@mimas.ctr.columbia.edu [128.59.74.18]) by sirius.ctr.columbia.edu (8.7.1/8.6.4.287) with ESMTP id NAA08561; Thu, 26 Oct 1995 13:22:30 -0400 (EDT)
Received: (hiroshi@localhost) by mimas.ctr.columbia.edu (8.7.1/8.6.4.788743) id NAA12593; Thu, 26 Oct 1995 13:15:21 -0400 (EDT)
Date: Thu, 26 Oct 1995 13:15:21 -0400 (EDT)
Message-Id: <199510261715.NAA12593@mimas.ctr.columbia.edu>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Hiroshi Esaki <hiroshi@ctr.columbia.edu>
To: kandlur@watson.ibm.com
CC: curtis@ans.net, yakov@cisco.com, rolc@nexen.com
In-reply-to: <9510242102.AA30179@vindhya.watson.ibm.com> (kandlur@watson.ibm.com)
Subject: Re: Last Call for draft-ietf-rolc-apr-00.txt
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/

Hi, 


My concern on the use of NHRP for host (attached to NBMA net) with APR 
model is why we must have another procedure and API compared to the 
current procedure performed at host. 
Currently, the host decides local or remote based on address mask, by 
my understanding.  But, when we introduce APR concept, I think, host will
know APR mask and will decides whether the destination host is inside
or outside of APR domain based on address prefix information. 
For me, the use of NHRP for the host to establish direct VCC between 
the hosts sitting on the difference IP subnet seems require completely 
different procedure from the conventional IP datagram transmission 
procedure. 
  Regarding the use of native NBMA (e.g.,ATM) interface, what is the 
benefit to use native NBMA interface for the application ? 
Overhead of IP header ?  
 

   > 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.

RSVP would be one of protocols to specify QoS. 
However, why you must define another API ? 
Why you can not use RSVP over ATM for end-to-end VCC ? 


 >> 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.
Whether SVC can provide better QOS (e.g."loss") will depend on 
the capability of NBMA, I think.   If NBMA network can not provide 
better quality for long-haul SVC than the quality for short-haul VC 
for hop-by-hop channel, we will prefer to use IP hop-by-hop channel.  


  :: While it would be hard to say that the ATM SVCs are *always* more 
  :: desirable, I think it would be fair to say that there are QoS 
  :: requirements where ATM SVC would be preferred to IP hop-by-hop 
  :: resource reservations.  It all depends on the QoS requirements.
You may say to use SVC or to use IP hop-by-hop resource reservation 
is completely host's local decision.:-) 
I think, since the decision is done by end-host's decision, even when 
the SVC has poorer quality service 


Regards, 

Hiroshi Esaki