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

"Eric W. Gray" <gray@ctron.com> Thu, 02 May 1996 15:16 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa03536; 2 May 96 11:16 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa03531; 2 May 96 11:16 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 LAA11388; Thu, 2 May 1996 11:09:04 -0400 (EDT)
Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id LAA03559 for rolc-out; Thu, 2 May 1996 11:07:17 -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 LAA03550 for <rolc@nexen.com>; Thu, 2 May 1996 11:07:14 -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 LAA21104 for <rolc@nexen.com>; Thu, 2 May 1996 11:07:11 -0400 (EDT)
Received: (from news@localhost) by gatekeeper.ctron.com (8.6.12/8.6.9) id LAA11842; Thu, 2 May 1996 11:07:08 -0400
Received: from stealth.ctron.com(134.141.5.107) by gatekeeper via smap (V1.3mjr) id sma011828; Thu May 2 11:06:53 1996
Received: from olympus.ctron.com by stealth.ctron.com (4.1/SMI-4.1) id AA20116; Thu, 2 May 96 10:59:11 EDT
Received: from blarney (blarney.ctron.com [134.141.66.40]) by olympus.ctron.com (8.6.12/8.6.9) with ESMTP id LAA19152; Thu, 2 May 1996 11:06:52 -0400
Received: from blarney by blarney via SMTP (940816.SGI.8.6.9/930416.SGI) id LAA20306; Thu, 2 May 1996 11:07:00 -0400
Message-Id: <3188CF8F.59E2@ctron.com>
Date: Thu, 02 May 1996 11:06:55 -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: Joel Halpern <jhalpern@us.newbridge.com>, rolc@nexen.com, gja@thumper.bellcore.com
Subject: Re: VCC cost models .... (was Re: Limits on SVCCs)
References: <199605021409.KAA21699@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 Armitage wrote:
> 
> >>The recent discussion has been suggesting that a cut-through would
> >>"cost more" than a routed path across an NBMA fabric.
> >>
> >>Maybe I am looking at this differently, but it seems to me definitional
> >>that a cut-through costs the same or less in real terms.
>         [..]
> >>There are many possible charging models for
> >>IP service, and many possible charging models for lower layer service.
> 
> There are possible models, and then there are existing models. I'm
> not aware of any ISPs serving 'the masses' who charge users for
> how many router hops their outbound traffic uses. I am aware of
> lower link providers who charge based on the topological 'distance' of
> the calls. Given such real models, minimizing router hops by
> making a long distance call comes across as less than obviously
> beneficial (financially) to the entity that was redirected to perform
> the cut-through. Sure, it saves router hops, but if I as Joe User
> can get my web pages either way, I dont care for the incremental charge
> of this cut-through.
>

"... less than obviously beneficial (financially)" - hmmm, sounds good.  Studio
audience says - BBBRRRRTT!!

Shortcuts are intended to be created to handle high volume flows.  The numbers I
have heard kicked around are the time honored 80-20 (80% of the traffic in about
20%  of the flows) which translates to a substantial reduction in the traffic level
which must be supported by the ISP.  I find it hard to believe that your ISP will
not eventually find a way to charge you for using 5 times as much bandwidth as the
other users of the ISP.

> 
> If anyone's done a deeper analysis already, and can release it,
> perhaps we can start a FAQ on cut-through. I'd be happy to see
> a more detailed argument refute this straw-man negative scenario
> constructed above (but based on existing or deployable-in-the-time-
> frame-of-NHRP charging models, of course).
> 

Please, can we be consistent about the terminology?  I believe that "cut-through"
has a completely different meaning in a related context and the term we have been
using in its place is "shortcut".

>
> cheers,
> gja

--
Eric Gray