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

Yakov Rekhter <yakov@cisco.com> Thu, 26 October 1995 17:47 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18476; 26 Oct 95 13:47 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa18471; 26 Oct 95 13:47 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id NAA26262; Thu, 26 Oct 1995 13:17:09 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id NAA11988 for rolc-out; Thu, 26 Oct 1995 13:28:27 -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 NAA11979 for <rolc@nexen.com>; Thu, 26 Oct 1995 13:28:25 -0400
Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.32]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id NAA26254 for <rolc@nexen.com>; Thu, 26 Oct 1995 13:16:57 -0400
Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id KAA09905; Thu, 26 Oct 1995 10:24:16 -0700
Message-Id: <199510261724.KAA09905@hubbub.cisco.com>
To: curtis@ans.net
cc: rolc@nexen.com
Subject: Re: Last Call for draft-ietf-rolc-apr-00.txt
In-reply-to: Your message of "Thu, 26 Oct 95 11:43:48 EDT." <199510261543.LAA22753@brookfield.ans.net>
Date: Thu, 26 Oct 1995 10:24:15 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Yakov Rekhter <yakov@cisco.com>
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/

Curtis,

> Just like the application today should not need to know whether the
> destination is on the same subnet and do things differently, the
> application should only need to know it's requirements.  In passing
> the requirements through the API to make the reservation, the
> operating system can recognize that a direct connection is possible
> and make the decision as to whether one should be set up based on the
> characterisitics and the needs of the application.

Agreed.

> The application passes information through an API.  The information
> characterizes the expected traffic and requirements of the
> application.  The first cut-through decision occurs on the immediate
> host.  If cut-through is not chosen then the traffic and a periodic
> reservation request is forwarded to the next hop.  If the first hop
> was an uncongested ethernet, the next hop router may make a
> cut-through decision and decide to create an SVC or provide other
> special treatment for this traffic.

Agreed.

> The application should not need to know how the network service is
> being provided.

True. However, what would be the reason to make it impossible for an
application to know how the network service (e.g. direct SVC vs going
through routers) is being provided.

Yakov.