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

Grenville Armitage <gja@bellcore.com> Wed, 01 May 1996 17:15 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21921; 1 May 96 13:15 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa21917; 1 May 96 13:15 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 NAA05784; Wed, 1 May 1996 13:06:29 -0400 (EDT)
Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id NAA22483 for rolc-out; Wed, 1 May 1996 13:04:58 -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 NAA22474 for <rolc@nexen.com>; Wed, 1 May 1996 13:04:55 -0400 (EDT)
Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by guelah.nexen.com (8.7.3/8.7.3) with SMTP id NAA05744 for <rolc@nexen.com>; Wed, 1 May 1996 13:04:53 -0400 (EDT)
Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.12/8.6.11) with ESMTP id NAA04127; Wed, 1 May 1996 13:04:38 -0400
Message-Id: <199605011704.NAA04127@thumper.bellcore.com>
To: "Eric W. Gray" <gray@ctron.com>
cc: Grenville Armitage <gja@bellcore.com>, rolc@nexen.com, gja@thumper.bellcore.com
Subject: Re: VCC cost models .... (was Re: Limits on SVCCs)
In-reply-to: Your message of Wed, 01 May 1996 12:25:12 -0400. <31879068.26AB@ctron.com>
Date: Wed, 01 May 1996 13:04:37 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Grenville Armitage <gja@bellcore.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/

Eric,

	[..]
>>Do you consider yourself a typical user?

When I'm just cruisin' the web - sure I am.

>>What about those cases where ATM attachment point is an edge device?

An interesting case, certainly.

>>Do you
>>think it's a good idea to introduce user-feedback loop complexity between the
>>edge device and the non-ATM host(s) it represents?  Would you propose that a
>>pop-up window should appear on a network manager's work-station in such cases?
>>
>>Do you imagine that any user wants to be bothered with a pop-up window (or
>>other "confirmation" query) for every potential shortcut connection?

(You're mistaking me for Pete Schulter. I noted in reply to Derya's
original email that 'cost' is an issue. I haven't proposed any specific
manner of user choice. It's too easy to argue an absurd user-choice
scenario that gets us no-where.)

The network provider needs to characterize the cost of their service,
otherwise they dont know how to provision and/or bill their customers.
If the customer (whether human or computer) isn't given a billing mechanism
that is controllable or constrainable, they'll go to an ISP who gives them
one.

If 'cut-through' makes it hard to characterize the cost of doing business
(and _that_ is the "if" I'm raising here), then someone may have a problem.

>>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).

For the non-ATM attached host, and from a purely NHRP-technological standpoint,
you may well be right. However, characterizing the financial impact of edge
devices performing cut-through then becomes an issue for the owners of the
edge devices (aka the 'users' of NHRP).

Note I'm not yet willing to suggest that characterizing dynamic impact
of NHRP on call costs is impossible. Just that its something I've
rarely seen talked about, and Derya's post seemed like an awakening :)

	[..]
>>> (for the last year or so the related question of cut-through MARS
>>> has popped up a number of times. needless to say this, umm, makes
>>> for interesting back-of-the-envelope calculations as you figure
>>> out who pays when _you_ request to join a Class D group and suddenly
>>> force a number of senders to add a long-distance leaf node to their
>>> pt-mpt VCs.)
>>
>>It may be due to my somewhat faulty intuition, but I suspect that _you_
>>(whoever _you_ is) pays...

Well, yes. But what I was getting at is that you're forcing the sender(s)
to have to figure out some way of billing you back for the incremental
cost of having added you as a long-distance leaf node.

gja