Re: VCC cost models .... (was Re: Limits on SVCCs)
"Eric W. Gray" <gray@ctron.com> Wed, 01 May 1996 14:19 UTC
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16199; 1 May 96 10:19 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa16191; 1 May 96 10:19 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 KAA04128; Wed, 1 May 1996 10:10:47 -0400 (EDT)
Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id KAA20309 for rolc-out; Wed, 1 May 1996 10:03:51 -0400 (EDT)
Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id KAA20300 for <rolc@nexen.com>; Wed, 1 May 1996 10:03:44 -0400 (EDT)
Received: from gatekeeper.ctron.com (ctron.com [134.141.197.25]) by nexen.nexen.com (8.7.3/8.7.3) with SMTP id KAA25297 for <rolc@nexen.com>; Wed, 1 May 1996 10:03:42 -0400 (EDT)
Received: (from news@localhost) by gatekeeper.ctron.com (8.6.12/8.6.9) id KAA01576; Wed, 1 May 1996 10:03:37 -0400
Received: from stealth.ctron.com(134.141.5.107) by gatekeeper via smap (V1.3mjr) id sma001532; Wed May 1 10:03:08 1996
Received: from olympus.ctron.com by stealth.ctron.com (4.1/SMI-4.1) id AA02519; Wed, 1 May 96 09:55:24 EDT
Received: from blarney (blarney.ctron.com [134.141.66.40]) by olympus.ctron.com (8.6.12/8.6.9) with ESMTP id KAA01367; Wed, 1 May 1996 10:03:03 -0400
Received: from blarney by blarney via SMTP (940816.SGI.8.6.9/930416.SGI) id KAA19037; Wed, 1 May 1996 10:03:12 -0400
Message-Id: <31876F1A.4691@ctron.com>
Date: Wed, 01 May 1996 10:03:06 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Eric W. Gray" <gray@ctron.com>
Organization: Cabletron Systems, Inc.
X-Mailer: Mozilla 2.0 (X11; I; IRIX 5.3 IP12)
Mime-Version: 1.0
To: schulter@zk3.dec.com
Cc: Keith McCloghrie <kzm@cisco.com>, Andrew Smith <fddi1-ncd@baynetworks.com>, dhc2@gte.com, gja@bellcore.com, rolc@nexen.com
Subject: Re: VCC cost models .... (was Re: Limits on SVCCs)
References: <9604302054.AA30356@dogfish.zk3.dec.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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/
schulter@zk3.dec.com wrote: > > > If the "real client" is an NBMA-attached host, > > Hmmm. Well, the "real client", as Grenville points out, is actually the user > isn't it? Regardless of what information the host/network is able to gather > about the cost of a particular call, it should be up to the user to decide if > each long-distance call should be placed (or any call that will incur any > charge over and above the local call to the default router). This decision > would be based entirely on how much a user is willing to pay to access certain > content or services. Each user will have a different cost/benifit ratio for > different content. So I would think each user would want to know how much a > call would cost, and be given the chance to decide if the cost is worth it for > the target content or service. The computer can't make this decision since > this is really a value (quite literally) judgement. There's also an issue of > call volume even if the per-call cost is low (1000 HTML links per month > resulting in long distance calls at $0.20/call is rather significant). How > do we expect users to manage this? > > Would this mean something like a pop-up dialog window for each possible > connection (like on every click on an HTML link)? Very annoying. I'm sure > other possibly less annoying ways to handle this could be developed, > but I think it would still be rather hard to manage. And of course, > cut-through of any type would have to be disabled when your 9 year-old was > using your PC ;-) > > > If the "real client" is, say, an Ethernet-attached host and there's a > > router between the Ethernet and the NBMA network, then it's not clear > > to me how the router can communicate "cost" information to the host, > > but whatever method is used would seem to be independent of NHRP. > > Well then, maybe it's the owner of the edge device that would make this > decision. I would guess that the owner of the directly connected device would > be the one that would be billed. My guess is that the owner would want to pass > these costs back to the individual users, so now the "cut-through" decision > is even more difficult to deal with (economically). Do we now want routers > and edge devices to deal with accounting? Or if not, then would the owner > of the edge device want to incur any expenses that couldn't be properly > passed on to the consumers? If there is no clean way to bill this, I > not sure if any owner of an edge device would ever allow the edge device > to do cut-through. > > Finally, all this is very different than the current Internet model. Users > don't have to worry about these things now, so why should they have to > worry about them in the future? My ISP rents bandwidth to his ISP for a flat > rate and distributes the cost of that bandwidth to his users. I pay a flat > rate every month to my ISP, a flat local call rate to NYNEX, and I don't have > to worry about how much each click on a hypertext link is going to cost me. > I can Internet to my heart's content knowing I will pay only the flat rate. > It's pretty much the same here at work. I imagine Digital pays a flat leased > line rate too. IMHO, this is exactly the model we should maintain for ATM. > I don't think cut-through maintains this model and introduces too many costs > and too much complexity for something very few people will be able to > afford to use (until the day when I can get unlimited long distance > calling from AT&T/MCI/SPRINT for $20/month). > > Now cut-through on a private (local or campus) net is a different issue. > > --- pete > > ------------------ > Peter Schulter schulter@zk3.dec.com > Digital UNIX Networking voice (603) 881-2920 > Digital Equipment Corp voice (DTN) 381-2920 > ZK3-03/U14 FAX (603) 881-2257 > 110 Spit Brook Road FAX (DTN) 381-2257 > Nashua, NH 03062 Peter, Often the "user" is not actually paying the bill. Consequently, very often a pop-up dialogue box would be neither appropriate nor appreciated. In every case, such a decision can be made by a properly "policy-instructed" computer (or other device - such as a router) and - for that less-common user who wants to make a per- instance choice - the policy might even include presenting the user with a pop-up. BTW, the "user" - sometimes referred to as the loose connection between the keyboard and the seat - is frequently and uniquely unqualified to determine benefit for a connection as well. Just ask yourself how many of your users can distinguish TCP and UDP... -- Eric Gray
- 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