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

Curtis Villamizar <curtis@ans.net> Thu, 26 October 1995 19:44 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa22094; 26 Oct 95 15:44 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa22090; 26 Oct 95 15:44 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id PAA27620; Thu, 26 Oct 1995 15:16:09 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id PAA13590 for rolc-out; Thu, 26 Oct 1995 15:26:37 -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 PAA13580 for <rolc@nexen.com>; Thu, 26 Oct 1995 15:26:34 -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 PAA27604 for <rolc@nexen.com>; Thu, 26 Oct 1995 15:15:05 -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 PAA23783; Thu, 26 Oct 1995 15:26:34 -0400
Message-Id: <199510261926.PAA23783@brookfield.ans.net>
To: Yakov Rekhter <yakov@cisco.com>
cc: curtis@ans.net, 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 "Thu, 26 Oct 1995 10:24:15 PDT." <199510261724.KAA09905@hubbub.cisco.com>
Date: Thu, 26 Oct 1995 15:26:29 -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 <199510261724.KAA09905@hubbub.cisco.com>, Yakov Rekhter writes:
> 
> 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.

My ftp doesn't know which route it takes to get data onto my disk.  My
copy of vat doesn't know anything about how the data travelled from
the source to my speaker.  It shouldn't.  It should only know what the
traffic characteristics are and what the requirements are and provide
some parameters to aid the network in making the decision (elastic,
not delay sensitive, low minimum, moderate to high max, low cost vs
real time, prefer low delay, tolerant of delay variation, fairly low
bandwidth).  Parameterizing this belongs in int-serv, communicating it
to other nodes belongs in rsvp.  SVC management does not belong in the
application at all.  See Lixia's comments.

Curtis