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.
- VCC cost models .... (was Re: Limits on SVCCs) Andrew Smith
- Re: VCC cost models .... (was Re: Limits on SVCCs) Keith McCloghrie
- Re: VCC cost models .... (was Re: Limits on SVCCs) schulter
- Re: VCC cost models .... (was Re: Limits on SVCCs) Tim Salo
- Re: VCC cost models .... (was Re: Limits on SVCCs) Curtis Villamizar
- Re: VCC cost models .... (was Re: Limits on SVCCs) Eric W. Gray
- Re: VCC cost models .... (was Re: Limits on SVCCs) schulter
- Re: VCC cost models .... (was Re: Limits on SVCCs) Eric W. Gray
- Re: VCC cost models .... (was Re: Limits on SVCCs) Grenville Armitage
- Re: VCC cost models .... (was Re: Limits on SVCCs) schulter
- Re: VCC cost models .... (was Re: Limits on SVCCs) Eric W. Gray
- Re: VCC cost models .... (was Re: Limits on SVCCs) Grenville Armitage
- Re: VCC cost models .... (was Re: Limits on SVCCs) Andrew Smith
- Re: VCC cost models .... (was Re: Limits on SVCCs) schulter
- Re: VCC cost models .... (was Re: Limits on SVCCs) schulter
- Re: VCC cost models .... (was Re: Limits on SVCCs) bgleeson
- Re: VCC cost models .... (was Re: Limits on SVCCs) Joel Halpern
- Re: VCC cost models .... (was Re: Limits on SVCCs) Grenville Armitage
- Re: VCC cost models .... (was Re: Limits on SVCCs) Eric W. Gray
- Re: VCC cost models .... (was Re: Limits on SVCCs) Eric W. Gray
- Re: Re: VCC cost models .... (was Re: Limits on S… Charles J. Ludinsky