The IP over ATM Mailing List Archive by date

[manfredi@engr05.comsys.rockwell.com (Albert E. Manfredi)]

> From:	curtis@ans.net    30-JAN-1996 13:52
> 
> To summarize your proposal: The ATM flatnet is then using "shortest
> path out" routing and essentially using default routing as well.  The
> other media is also doing "shortest path out" to the ATM flatnet LIS.
> There is no transit of non-ATM across ATM flatnets, but there can be
> transit across non-ATM media to reach disjoint ATM flatnets.

Good summary. "No transit" is not a strict requirement. It was
> 
> If there is significant traffic between the ATM flatnet and the other
> media and the traffic is near symetric (approximately equal amount of
> traffic in both directions), then there needs to be equal bandwidth
> for this on the other media as there is on the ATM media.  There is
> also no hope to transit the ATM flatnet.
> 
> Now lets look at transition.
> 
> This would mean that initially a provider hoping to become a player in
> the Internet market in some portion of the world) would have to either
> build two infrastructures, one ATM, and one not using ATM, or pay
> other providers for transit.
> 
> It would seem to me to be much more attractive to the potential user
> of ATM in this scenario (trying to make a dent in the global Internet
> market) if ATM could be used to transit non-ATM traffic.  This way
> such a user of ATM could be selling transit service rather than buying
> it.  If another provider also uses ATM, but supports routing, they can
> reach all the non-ATM places without paying all the transit fees or
> supporting the two infrastructures you have to support.
> 
> You may even need more than 90% to make this work.  If you have the
> capital to take 90% of the global Internet market overnight, then who
> can argue with you.  If not, an ATM flatnet is a very bad choice.
> 
> Curtis
> 
> ps- Even if you do have the capital, you still haven't addressed the
> issue of how the limited VC space problem gets solved for a large ATM
> flatnet (which would presumably make host to host connections that get
> concentrated into OC12 and OC48 or higher).  You also haven't solved
> the problem of connection setup overhead for all these very short
> lived host to host connections (DNS packets, short lived WWW flows,
> etc).  Carving small VPs either destroys QoS capability or brings back
> the inefficiency of TDM by fixing the VP bandwidth allocations and
> rate shaping the VPs.
> ================== RFC 822 Headers ==================
> Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.6.12/8.6.12) with ESMTP id NAA02322; Tue, 30 Jan 1996 13:49:25 -0500
> Message-Id: <199601301849.NAA02322@brookfield.ans.net>
> To: manfredi@engr05.comsys.rockwell.com (Albert E. Manfredi)
> cc: ip-atm@matmos.hpl.hp.com
> Reply-To: curtis@ans.net
> Subject: Re: Example of large IP flatnet 
> In-reply-to: Your message of "Mon, 29 Jan 1996 12:32:31 EST."
>              <96012912323065@engr05.comsys.rockwell.com> 
> Date: Tue, 30 Jan 1996 13:49:24 -0500
> From: Curtis Villamizar <curtis@ans.net>
>