Re: int-serv over e.g. ATM
Noel Chiappa <jnc@ginger.lcs.mit.edu> Sat, 11 November 1995 20:09 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa11846;
11 Nov 95 15:09 EST
Received: from guelah.nexen.com by IETF.CNRI.Reston.VA.US id aa11841;
11 Nov 95 15:09 EST
Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by
guelah.nexen.com (8.6.12/8.6.12) with ESMTP id OAA22752;
Sat, 11 Nov 1995 14:39:36 -0500
Received: (from root@localhost) by maelstrom.nexen.com (8.6.12/8.6.12) id
OAA26473 for rolc-out; Sat, 11 Nov 1995 14:49:26 -0500
Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by
maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id OAA26464 for
<rolc@nexen.com>; Sat, 11 Nov 1995 14:49:23 -0500
Received: from ginger.lcs.mit.edu (ginger.lcs.mit.edu [18.26.0.82]) by
nexen.nexen.com (8.6.12/8.6.12) with SMTP id OAA08765 for <rolc@nexen.com>;
Sat, 11 Nov 1995 14:47:05 -0500
Received: by ginger.lcs.mit.edu
id AA27696; Sat, 11 Nov 95 12:14:32 -0500
Date: Sat, 11 Nov 95 12:14:32 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Noel Chiappa <jnc@ginger.lcs.mit.edu>
Message-Id: <9511111714.AA27696@ginger.lcs.mit.edu>
To: curtis@ans.net, int-serv@isi.edu, rolc@nexen.com, rsvp@isi.edu
Subject: Re: int-serv over e.g. ATM
Cc: jnc@ginger.lcs.mit.edu
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via
ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/
From: Curtis Villamizar <curtis@ans.net>
On the other hand, SVCs may cost money. ... If you can often use either a
shared VC to the router (shared with other traffic from the same router) or
use a VC to that router rather than a direct VC all the way, you might
still get the QoS you want and reduce your costs when the router is lightly
loaded, and get the QoS you want when rejected using a direct VC.
This sounds to me like a pricing anomaly, i.e. an artifact of prices that
don't correspond to the actual resources used. Carrying the packets around
should cost the same in terms of resources consumed, no matter how many layers
of mechanism you use to do it. So, I'm not sure how imporant this case is; it
might go away since the market tends to drive prices toward "real" prices.
About the only reason I can think of where it might be genuinely cheaper is if
you have saved the overhead of state/setup required for a separate VC all
through the net. If this is that big a deal, how come ATM isn't trying to
aggregate VC's? But the "do we have to aggregate flows" is a whole separate
can of worms.
Noel
- int-serv over e.g. ATM Mark W Garrett
- Re: int-serv over e.g. ATM berson
- Re: int-serv over e.g. ATM Craig Partridge
- Re: int-serv over e.g. ATM Craig Partridge
- Re: int-serv over e.g. ATM Curtis Villamizar
- Re: int-serv over e.g. ATM berson
- Re: int-serv over e.g. ATM Lixia Zhang
- Re: int-serv over e.g. ATM Steve Deering
- Re: int-serv over e.g. ATM Alagu Periyannan
- Re: int-serv over e.g. ATM Mark W Garrett
- Re: int-serv over e.g. ATM Walter Milliken
- Re: int-serv over e.g. ATM Steve Deering
- Re: int-serv over e.g. ATM Mark W Garrett
- Re: int-serv over e.g. ATM Juha Heinanen
- Re[2]: int-serv over e.g. ATM Charlie Tai
- Re: int-serv over e.g. ATM Curtis Villamizar
- Re: int-serv over e.g. ATM Juha Heinanen
- Re: int-serv over e.g. ATM Mark W Garrett
- Re: int-serv over e.g. ATM Juha Heinanen
- Re: int-serv over e.g. ATM Jon Crowcroft
- Re: int-serv over e.g. ATM Juha Heinanen
- Re: int-serv over e.g. ATM Jon Crowcroft
- Re: int-serv over e.g. ATM Curtis Villamizar
- Re: int-serv over e.g. ATM John Krawczyk
- Re: int-serv over e.g. ATM Noel Chiappa
- Re: int-serv over e.g. ATM Andrew Smith
- Re: int-serv over e.g. ATM Andrew Smith
- Re: int-serv over e.g. ATM Curtis Villamizar