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

"Eric W. Gray" <gray@ctron.com> Wed, 01 May 1996 16:40 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20729; 1 May 96 12:40 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa20714; 1 May 96 12:40 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 MAA05369; Wed, 1 May 1996 12:31:00 -0400 (EDT)
Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id MAA22026 for rolc-out; Wed, 1 May 1996 12:30:09 -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 MAA22017 for <rolc@nexen.com>; Wed, 1 May 1996 12:30:06 -0400 (EDT)
Received: from gatekeeper.ctron.com (ctron.com [134.141.197.25]) by guelah.nexen.com (8.7.3/8.7.3) with SMTP id MAA05360 for <rolc@nexen.com>; Wed, 1 May 1996 12:30:05 -0400 (EDT)
Received: (from news@localhost) by gatekeeper.ctron.com (8.6.12/8.6.9) id MAA11035; Wed, 1 May 1996 12:29:53 -0400
Received: from stealth.ctron.com(134.141.5.107) by gatekeeper via smap (V1.3mjr) id sma010991; Wed May 1 12:29:10 1996
Received: from olympus.ctron.com by stealth.ctron.com (4.1/SMI-4.1) id AA14658; Wed, 1 May 96 12:21:30 EDT
Received: from blarney (blarney.ctron.com [134.141.66.40]) by olympus.ctron.com (8.6.12/8.6.9) with ESMTP id MAA04438; Wed, 1 May 1996 12:29:10 -0400
Received: from blarney by blarney via SMTP (940816.SGI.8.6.9/930416.SGI) id MAA19308; Wed, 1 May 1996 12:29:19 -0400
Message-Id: <31879068.26AB@ctron.com>
Date: Wed, 01 May 1996 12:25:12 -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: Grenville Armitage <gja@bellcore.com>
Cc: rolc@nexen.com
Subject: Re: VCC cost models .... (was Re: Limits on SVCCs)
References: <199605011444.KAA18246@thumper.bellcore.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/

Grenville,

You wrote (in part):
> 
...
> Let's not get too carried away with the detail :-)
> 
> The 'service' is not TCP or UDP from this users's perspective. It's
> a web page, a RealAudio connection, an mpeg movie snippet. For
> these things I have a personal and somtimes dynamic sense of their worth.
> If you can collapse trade-offs like TCP vs UDP, or hop-by-hop vs cut-through,
> into some sort of comparative dollar figure, I can tell you which option
> I think is 'worth it'. Right at the moment, the axis along which most
> people will find cost sensitivity will be the long-vs-short distance
> ATM call. Which NHRP impacts on.
>

Do you consider yourself a typical user?

What about those cases where ATM attachment point is an edge device?  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?

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).  A very likely approach to
doing this is through policy decisions made by network nodes (whether these
are switches, routers or NHSs) and - for those instances where dialogue with
a user is desirable - the policy may be to seek confirmation from the user.

> 
> Interesting problem, no?
>

Only as an implementation detail...

> 
> cheers,
> gja
> 
> (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...