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 ********************************************************************************
- Re: VCC cost models Andrew Smith
- Re: VCC cost models Andrew Smith
- Re: VCC cost models Keith McCloghrie