Re: VCC cost models .... (was Re: Limits on SVCCs)

bgleeson@cisco.com Thu, 02 May 1996 00:44 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa07372; 1 May 96 20:44 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa07368; 1 May 96 20:44 EDT
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id UAA08836; Wed, 1 May 1996 20:37:08 -0400 (EDT)
Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id UAA27444 for rolc-out; Wed, 1 May 1996 20:34:05 -0400 (EDT)
Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id UAA27435 for <rolc@nexen.com>; Wed, 1 May 1996 20:34:01 -0400 (EDT)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: bgleeson@cisco.com
Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.31]) by guelah.nexen.com (8.7.3/8.7.3) with SMTP id UAA08832 for <rolc@nexen.com>; Wed, 1 May 1996 20:34:00 -0400 (EDT)
Received: from bgleeson-ss20.cisco.com (bgleeson-ss20.cisco.com [171.69.193.208]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with ESMTP id RAA20004; Wed, 1 May 1996 17:34:14 -0700
Received: (bgleeson@localhost) by bgleeson-ss20.cisco.com (8.6.8+c/CISCO.WS.1.1) id RAA06234; Wed, 1 May 1996 17:31:13 -0700
Date: Wed, 01 May 1996 17:31:13 -0700
Message-Id: <199605020031.RAA06234@bgleeson-ss20.cisco.com>
To: gray@ctron.com, schulter@zk3.dec.com
Subject: Re: VCC cost models .... (was Re: Limits on SVCCs)
Cc: gja@bellcore.com, rolc@nexen.com
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: [Un]Subscribe to rolc-request@nexen.com, submissions to rolc@nexen.com
X-Info: Email archive at ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/
X-Info: Hypermail archive at http://cell-relay.indiana.edu/mail/archives/rolc/
X-Info: FTP archive at ftp://ftp.nexen.com/pub/rolc/

Pete, Eric

>
>> My point was that the right place to make the decision to allow for a short-
>> cut is most often in the network (not the host).
>
>My point is that the right place to make this decision is at the entity
>which will (ultimately) pay the bill.
>

Good point - and this might just as well be the "user" as the "network provider"
but I don't think it follows that short-cuts are a bad thing or unmanagable,
and I think they make sense in both cases.

The typical user won't know or care about TCP / UDP / NHRP / etc. Instead 
a user will have some concept of service level. Say someone is listening to
a RealAudio clip but the sound quality isn't good. Say there's a button 
which says - "HiFi quality". If the user is interested enough, and only
the user can make that decision, he might click on it knowing it will cost
more. This may result in underlying mechanisms such as RSVP reservations, 
short-cuts etc resulting in better service. The network provides mechanisms
which can be invoked - and which cost money. Even short-cuts
within administrative domains could be a big gain - it doesn't have
to be end-to-end. A typical traceroute these days seems to end up with a list of
15 - 25 routers (with maybe 6-8 in one AD) so there's lots of 
potential for short-cuts.  A network provider may also characterize the network 
into different service levels, and use short-cuts as a means to provide them. 
Flat rates could also be charged for different service levels, it doesn't have to
be per call. 

A network driven scenario may be where a network provider just uses
short-cuts within the network to provide an overall better level of
service (even if it really confuses traceroute users :-). If it becomes 
known as a "premium" provider then it can presumably charge more to cover the costs. 
You get what you pay for.

>I think it's more than just an implementation detail, it's a major shift in 
>the way that people (users or the owners of edge devices) have to deal with
>the costs of Internet usage.
>

I would guess that improved service levels etc will be offered _in_addition_to_,
and not replacing good old best effort hop-by-hop mechanisms. If you want more
you can pay for it - if you don't want it you don't pay. There is a counter
argument here which is that as more people pay for improved service levels
the best effort service level drops, and so it ends up driving up the overall
cost - but this is more an economics of scare resources issue - and I'm not
an economist. 

Bryan Gleeson
Cisco.