int-serv Cspecs (was Re: Last Call for draft-ietf-rolc-apr-00.txt )

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

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17858; 26 Oct 95 13:30 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa17852; 26 Oct 95 13:30 EDT
Received: from maelstrom.nexen.com ([204.249.99.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id NAA25865; Thu, 26 Oct 1995 13:01:54 -0400
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id NAA11700 for rolc-out; Thu, 26 Oct 1995 13:12:55 -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 NAA11691 for <rolc@nexen.com>; Thu, 26 Oct 1995 13:12:52 -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 NAA25861 for <rolc@nexen.com>; Thu, 26 Oct 1995 13:01:22 -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 NAA23161; Thu, 26 Oct 1995 13:12:54 -0400
Message-Id: <199510261712.NAA23161@brookfield.ans.net>
To: Juha Heinanen <jh@lohi.dat.tele.fi>
cc: salo@msc.edu, rolc@nexen.com, int-serv@isi.edu
Reply-To: curtis@ans.net
Subject: int-serv Cspecs (was Re: Last Call for draft-ietf-rolc-apr-00.txt )
In-reply-to: Your message of "Thu, 26 Oct 1995 10:29:17 +0200." <199510260829.KAA02429@lohi.dat.tele.fi>
Date: Thu, 26 Oct 1995 13:12:49 -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 <199510260829.KAA02429@lohi.dat.tele.fi>fi>, Juha Heinanen writes:
> so there is a clear requirement to int-serv/rsvp that the user must be
> able to, in addition to qos, also specify at which cost he/she is
> willing to ask for such a qos.  is this already included?  in fact, the
> user should have capability to specify alternative sets of requirements
> and the network would pick the one it can support.
> 
> -- juha

Tspec, Rspec, and Cspec?  Where C is cost?  ;-)

I'm just a lurker on rsvp and int-serv.  I've yet to see a means of
communication cost requirements proposed.

There are clearly ommissions in the int-serv work.  If they ever
finish debating token-bucket and means or expressing and guarenteeing
delays, they'll probably move on to real issues.  :-)

You are welcome to propose a means to integrate cost into the Rspec or
porposed that rsvp adapt an additional Cspec.

Curtis

ps- maybe this thread should drop off rolc and continue on int-serv or
not at all.