Re: VCC cost models

Andrew Smith <fddi1-ncd@baynetworks.com> Thu, 02 May 1996 21:25 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14086; 2 May 96 17:25 EDT
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa14082; 2 May 96 17:25 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 RAA14428; Thu, 2 May 1996 17:15:23 -0400 (EDT)
Received: (from root@localhost) by maelstrom.nexen.com (8.7.3/8.7.3) id RAA08292 for rolc-out; Thu, 2 May 1996 17:14:44 -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 RAA08283 for <rolc@nexen.com>; Thu, 2 May 1996 17:14:40 -0400 (EDT)
Received: from lightning.synoptics.com (lightning.synoptics.com [134.177.3.18]) by guelah.nexen.com (8.7.3/8.7.3) with SMTP id RAA14415 for <rolc@nexen.com>; Thu, 2 May 1996 17:14:37 -0400 (EDT)
Received: from pobox ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA08134; Thu, 2 May 96 14:14:24 PDT
Received: from milliways-le0.engwest by pobox (4.1/SMI-4.1) id AA07245; Thu, 2 May 96 14:09:54 PDT
Received: by milliways-le0.engwest (4.1/SMI-4.1) id AA01499; Thu, 2 May 96 14:09:52 PDT
Date: Thu, 02 May 1996 14:09:52 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Andrew Smith <fddi1-ncd@baynetworks.com>
Message-Id: <9605022109.AA01499@milliways-le0.engwest>
To: jhalpern@us.newbridge.com
Subject: Re: VCC cost models
Cc: 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/

> From owner-rolc@nexen.com Thu May  2 06:45:02 1996
> Date: Thu, 2 May 1996 09:30:08 +0500
> From: jhalpern@us.Newbridge.com (Joel Halpern)
> To: gray@ctron.com, gja@bellcore.com
> Subject: Re: VCC cost models .... (was Re: Limits on SVCCs)
> Cc: rolc@nexen.com

Joel,

> The recent discussion has been suggesting that a cut-through would
> "cost more" than a routed path across an NBMA fabric.

One word, Joel: "SCALING".

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

Yes, ONE short-cut path costs approx the same as ONE hop-by-hop path.

> In the non-cut-through case, the packet enters the NBMA, and is passed
> over the NBMA, stopping to be handled and processed by several routers
> along the way.  In the cut-through case, it enters the NBMA, is passed
> at a "lower" level of proocessing across the NBMA, and exits and the
> ssame place it would have.

Agreed, in theory (and we can argue about best/worst current practice until
the cows come home) it is cheaper to process ATM VPI/VCIs than IP prefixes, 
although "lower" isn't always "cheaper".

> One can argue about whether the switches or routers are cheaper, or
> whatever.  But the packet is still entering and exiting the NBMA at the
> same point.  There certainly may be charging differentials, but I do
> not see what it is a given that a long-distance low level VC would cost
> more than a routed path.  

The real issue is that the individual legs of the hop-by-hop path can be
shared by many flows whereas the VCCs between the switches can only be
shared by those flows originating/terminating in the same place. So when
you have many flows that are going roughly in the same general direction
there are a lot of cost savings by using a hop-by-hop routed path. If you
have either no locality or total locality (many flows going between exactly 
the same ATM endpoints) then short-cuts might gain the edge.

> There are many possible charging models for
> IP service, and many possible charging models for lower layer service.
> If the pair are inconsistent, then sometimes cut-throughs will be a
> bigger win than they should, and sometimes they will be a big loser.
> Most of the time, I would expect the cut-through to be a small winner
> in terms of real resource consumption, but that is open to argumentation.

So I guess we are back to the old status quo: NHRP (the protocol) can be
used to request a short-cut NBMA address; NHRP (the internet-draft/RFC)
does not specify VCC usage policies, when to do make such a request or what 
to do when you get the answer.

Whether ROLC should also work on these other issues is a good question: I guess
that was the gist of Derya's original question. I know that MPOA's scope
involves providing some answers for one particular network deployment scenario
but that is not the Internet.


> Yours,
> Joel M. Halpern				jhalpern@newbridge.com
> Newbridge Networks Inc.

Andrew

********************************************************************************
Andrew Smith					TEL:	+1 408 764 1574
Bay Networks, Inc. 				FAX:	+1 408 988 5525
Santa Clara, CA					E-m:	asmith@baynetworks.com
********************************************************************************