On Fri, 5 Mar 1999, Michael Dillon wrote:

> On Fri, 5 Mar 1999, Jawaid Bazyar wrote:
>
> > I don't think it's clear at all that the future of the Internet is going
> > to be purely IP. Right now they're synonymous, but IP is not well suited
> > to many applications.
>
> After seeing the 1500% growth in 1995 of an ill-designed awkward protocol
> that was badly suited for everything except file retrieval, I've realized
> that technical elegance does not always win. The protocol I refer to is
> HTTP and it mushroomed because it was open. IP has the same thing going
> for it and that is why I expect that it will push aside ATM.

> For example, how many other drivers for ATM equipment for Linux/FreeBSD do
> you know of besides the one that you wrote?

FreeBSD, I dunno. Linux, about a half dozen, covering several vendors, and
the number is slowly growing. I'm not too concerned about "open" at this
point - I'm cheap, but if I were a fairly well-to-do backbone I'd be
buying Sparcs, which have all sorts of good vendor-supplied ATM drivers.

--
  Jawaid Bazyar              |   Affordable WWW & Internet Solutions
  Interlink Advertising Svcs |   for Small Business
  bazyar@...       |   910 16th Street, #1220    (303) 228-0070
  --The Future is Now!--     |   Denver, CO 80202          (303) 228-0077 fax


------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

On Fri, 5 Mar 1999, Jawaid Bazyar wrote:

> I don't think it's clear at all that the future of the Internet is going
> to be purely IP. Right now they're synonymous, but IP is not well suited
> to many applications.

After seeing the 1500% growth in 1995 of an ill-designed awkward protocol
that was badly suited for everything except file retrieval, I've realized
that technical elegance does not always win. The protocol I refer to is
HTTP and it mushroomed because it was open. IP has the same thing going
for it and that is why I expect that it will push aside ATM.

For example, how many other drivers for ATM equipment for Linux/FreeBSD do
you know of besides the one that you wrote?

--
Michael Dillon                 -               E-mail: michael@...
Check the website for my Internet World articles -  http://www.memra.com



------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

On Fri, 5 Mar 1999, Jawaid Bazyar wrote:

> So, the only argument left against IP over ATM is the overhead. And in
> that case you folks are thinking wrongly: you keep thinking bandwidth is
> expensive -- it's not. It about to become ridiculously cheap, to the point
> where "losing 155mbit on an OC-12" is irrelevant both technically and
> financially.

It may be about to happen but people building today's networks have to pay
today's prices. And none of this deals with the problem of finding and
paying for an engineering staff that is familiar with ATM, IP and the
interactions between ATM and IP.

> Arthur C. Clarke predicts the elimination of long-distance
> phone charges within the same time. I think our predictions are related.

It's nice to see a famous name saying the same thing I said 3 years ago
but be careful when you try to extrapolate the effects of cheap cheap
bandwidth. This is not always obvious. For instance, our ATM cheerleader
is claiming that you can use your bandwidth more effectively with ATM and
save money. But if bandwidth gets that cheap noone will care about that
factor so it becomes a non-issue.

The two technologies that I am betting on are IP over glass and gigabit
Ethernet.

--
Michael Dillon                 -               E-mail: michael@...
Check the website for my Internet World articles -  http://www.memra.com



------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

On Fri, 5 Mar 1999, Michael Dillon wrote:

> The future of the Internet is clearly going to be IP over glass and for
> marketing reasons alone ISPs have to move in this direction. But it so
> happens that IP over glass is a very cost effective and manageable way to
> build a unified Internet backbone. I use the term unified because instead
> of managing a SONET layer, an ATM layer and an IP layer, IP over glass
> requires you to only invest in managing the IP layer.

I don't think it's clear at all that the future of the Internet is going
to be purely IP. Right now they're synonymous, but IP is not well suited
to many applications.

--
  Jawaid Bazyar              |   Affordable WWW & Internet Solutions
  Interlink Advertising Svcs |   for Small Business
  bazyar@...       |   910 16th Street, #1220    (303) 228-0070
  --The Future is Now!--     |   Denver, CO 80202          (303) 228-0077 fax


------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

On Thu, 4 Mar 1999, Michael Dillon wrote:

> On Thu, 4 Mar 1999, Joachim Martillo wrote:
>
> > http://members.aol.com/tprovoni/book1/chapter1/Image43.gif
> > shows a picture of an ATM Cell.
> >
> > It has 5 header bytes and 48 information field octets.
> >
> > (5/53) * 100 = 9.43%
>
> This is theory not practice. Internet engineers have years of practical
> experience with IP over ATM and know the problems that combination causes.
> You are also not including the empty octets in the ATM cells caused when a
> variable length IP packet is not a multiple of 48 octets. Not to mention
> the effects that cell loss has, i.e if a single cell is lost then ATM will
> still transport all the other cells carrying the broken IP packet to its
> destination even though this is a total waste of bandwidth.

You're several years behind the technology here, Michael:

http://www.fore.com/products/swtch/dsatmnetmods.html
Look at the section titled "Frame Discard".

The nominal 10% ATM overhead buys you a lot of functionality, so let's
just talk about cell alignment & packing.

The worst case would appear to be packets less than 24 bytes, since that
results in overhead from unused capacity in excess of 50%. (The next worst
case, a 49 byte packet, is not quite 50%, and it gets better from there).

On the upper end of the scale, however, things improve. We currently run
4500 byte MTUs on our ATM-connected equipment. Assuming a transfer of a
reasonably large file, most of the file will have overhead of 12 bytes per
packet, or 12 / 4500 which is 0.2%. It varies, of course.

I'm not sure why "ATM" MTUs aren't set at multiples of 48, but that seems
an easy to way to get a little bit extra throughput (though not a lot).

So, the only argument left against IP over ATM is the overhead. And in
that case you folks are thinking wrongly: you keep thinking bandwidth is
expensive -- it's not. It about to become ridiculously cheap, to the point
where "losing 155mbit on an OC-12" is irrelevant both technically and
financially. I predict a 10x reduction in long-distance bandwidth costs
within 5 years. Arthur C. Clarke predicts the elimination of long-distance
phone charges within the same time. I think our predictions are related.

--
  Jawaid Bazyar              |   Affordable WWW & Internet Solutions
  Interlink Advertising Svcs |   for Small Business
  bazyar@...       |   910 16th Street, #1220    (303) 228-0070
  --The Future is Now!--     |   Denver, CO 80202          (303) 228-0077 fax


------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

On Fri, 5 Mar 1999, Joachim Martillo wrote:

> >> network performance over ATM networks.  How much work do you
> >> do with ATM networks?
>
> >I believe Dave already answered that, 'as little as possible' sums it
> up.
>
> Which perhaps indicates less than fluency with this technology.

It could also indicate a great familiarity with the technology and its
shortcomings for running an IP-only Internet backbone.


> >When you design your network from the ground up with your traffic
> >patterns in mind then you don't need to dynamic traffic engineering.
>
> Are you suggesting that a network designer can know for all time what
> the network traffic patterns will be before the network even goes
> on-line?

Of course not. That's why a robust IP network uses dynamic routing
protocols like OSPF and BGP.

> One could engineer the basic bandwidth infrastructure statically to
> provide all the bandwidth the business and home users need at all
> times, but if a technology is available that allows dynamic
> reassignment of bandwidth at a cost savings, it might make sense to
> make use of that technology and switch between alternate bandwidth
> allocations between 5pm and 8pm and between 1am and 8pm.

Sounds great in theory but such a technology does not exist outside of
textbooks. On the other hand some simple measurement tools combined with
burst rate pricing can provide the cost savings without the complex
technology which explains why nobody seems interested in the technology.

> The Packet Switching Technology list provides a forum for discussion

It seems to me that your only purpose here is to peddle your favorite
mailing list. You cascade us with obfuscated diatribes regarding what some
people might do in some hypothetical situtaions to solve some imagined
problems that have only the tiniest shred of relevance to ISPs.

Most ISPs do not use ATM for anything except longhaul circuits when the
pricing on the ATM circuit is less than a point-to-point leased line.
That's because the experience of many ISPs, including backbone providers,
has shown that ATM is an inferior technology for a pure IP network. ISPs
run pure IP networks. In practice a non-ATM link is easier to deal with
and less failure prone than an ATM link. Whether this is due to the ATM
switches or the people running the switches or the ATM routing or the ATM
network topology is not much relevant. In practice it doesn't work as well
as a longhaul point-to-point link for IP.

But there's more. Setting aside the technological problems with ATM in an
INternet backbone there is the marketing problem. Even ISP engineering
staff have to contend with the fact that ATM is not marketable to ISP
customers. They either don't care about ATM or they see ATM as an inferior
technology. When faced with this type of selling situation all the
engineering arguments in the world are patently useless. You either sell
the customer an ATM-free network or you try to hide the fact that you are
using ATM. If you are keeping your ATM infrastructure a secret then sooner
or later management will demand that you get rid of the ATM because it is
a marketing liability and a time-bomb if your competition finds out about
it.

The future of the Internet is clearly going to be IP over glass and for
marketing reasons alone ISPs have to move in this direction. But it so
happens that IP over glass is a very cost effective and manageable way to
build a unified Internet backbone. I use the term unified because instead
of managing a SONET layer, an ATM layer and an IP layer, IP over glass
requires you to only invest in managing the IP layer.

--
Michael Dillon                 -               E-mail: michael@...
Check the website for my Internet World articles -  http://www.memra.com



------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

[In the message entitled "Re: [NET-DESIGN] Wide Area Network Backbones" on Mar 
5, 11:43, Joachim Martillo writes:]
>
> >I believe Dave already answered that, 'as little as possible' sums it
> up.
>
> Which perhaps indicates less than fluency with this technology.

No, it indicates that I have exhaustively tried ATM.  It sucks.

There are three great lies when dealing with people selling ATM networks.

1) The QOS assurance you asked for is in the mail.  Honest.
2) The new {switch/link} needed to relieve the congestion on the
    network is {on the truck/being installed}.  Honest.
3) We *never* oversell our network.  Honest.


> >When you design your network from the ground up with your traffic
> >patterns in mind then you don't need to dynamic traffic engineering.
>
> Are you suggesting that a network designer can know for all time what
> the network traffic patterns will be before the network even goes
> on-line?

Yes.  Particularly when you know the capacities of the circuits at each
end.  It's math.  Not tricky.  The only time you run into problems is if you
try to cut costs by underprovisioning.  See excuse #3, above.

>
> Most network administrators deal with rather more dynamic network
> situations where there can be very large variations in traffic from
> day to day, between day and night or as new customers come on line.

That's called planning.  I'm planning my network 18 months out right now.  I
do that because the capacity I need isn't even in the ground yet.  I know my
historical growth rates.  I know the capabilties of the equipment.  I can
forcast my utilization (and I have done so for years) with a high degree of
accuracy.  Yes, even including new whizzy technologies.


>
> >And no, I have never done much work with ATM.  Wanna know why?  I've
> >never run a network that needs it.
>
> Again another indication of less than fluency with this technology.
>

I *have* worked a lot with ATM.  It sucks.  It's hard to find problems,
particulary when looking at more complex-than-normal issues like link
timimg, and network-wide timing.  It's hard to convince switch vendors that
dropping cell creates CRC errors at the IP frame level, and is a Bad Thing.

ATM *is* good for small volume, widely dispersed networks.  ATM *is*
good for limiting maximum bandwidth used, and preventing congestive
collapse of certain architectures.  ATM *is* good for many non-IP
applications.

But it is not a cure-all.  It wastes a *lot* of bandwidth, due to the
fixed cell size.  This is a Good Thing for some applications, but not
for IP.

In the same way that I don't try to use sc to write documents better
expressed in troff*, I don't try to use ATM where fast ethernet or SONET
links would be better.


*) for the windows crowd, please read is "I don't try to use Excell
to write documents better expressed in Word".

--
Dave Rand
dlr@...
http://www.bungi.com

------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

| Are you suggesting that a network designer can know for all time what
| the network traffic patterns will be before the network even goes
| on-line?

No, I think they are not quite finding the words to suggest that
statistical multiplexing gain is more cost-effective than the
control-oriented fine-grained TDM that ATM offers.

That ATM has evolved statmux-like modes (ABR, UBR) is evidence that
even ATM users recognize that statistical multiplexing gain is a
win.  What a pity ATM's circuit-think is poorly suited to congestion
avoidance as opposed to congestion control.

| Most network administrators deal with rather more dynamic network
| situations where there can be very large variations in traffic from
| day to day, between day and night or as new customers come on line.

Note that the work by Paxson et al. pretty nicely point out that
there are fractal traffic patterns ranging over as many as 10 base2
generations of time scales.

Why impose a controlling discipline on a network that starves
a congestion-avoiding bulk transfer just because it's a little
after 8 a.m., or because a new customer has been signed up?

| Suppose one administers a network that services a tremendous amount of
| business users from 8am -- 5pm and services a tremendous amount of
| home users from 8pm -- 1am.
|
| One could engineer the basic bandwidth infrastructure statically to
| provide all the bandwidth the business and home users need at all
| times, but if a technology is available that allows dynamic
| reassignment of bandwidth at a cost savings, it might make sense to
| make use of that technology and switch between alternate bandwidth
| allocations between 5pm and 8pm and between 1am and 8pm.

It might also make sense to toss away a rigorous frequently-reconfigured
TDM regime in favour of a statmuxing regime.

	 Sean.
-
Send 'unsubscribe' in the body to 'list-request@...' to leave.
Eat sushi frequently.   inet@... is the human contact address.

------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

| It depends on the ATM switch and the network configuration.  One
| popular ATM switch uses an internal non-blocking space division
| switch.  If the network does no dynamic circuit setup and makes no use
| of the limited ATM broadcast capabilities, an ATM network built with
| these switches never drops cells.

This is a very important if, and half is missing.

It should be noted that one cannot implement on a space-division
switch a set of PVCs such that the ingress bandwidth is greater
than the switching-plane or egress bandwidth without the risk of
short-term fractal PDU interarrival times leading to massive
cell loss or massively heavily-tailed delay distributions.

(Odds are on the former, since most space-division switches tend
to skimp a bit on buffering, since it's "not needed").

This is a serious constriction that needs to be understood by
people doing Internet things with such switches.  Unfortunately,
such understanding often proves elusive, even among fairly clever
engineers.

| To handle limited ATM broadcast and
| some amount of dynamic circuit setup, the ATM switch provides
| (potentially tremendous amounts of) input side buffering.

Input-side buffering is a neat hack but leads to HOL blocking
that is well known and loathed in the Internet operator community.
Having packets destined for an uncongested port suffering from
unpredictable delays is very bad for TCP and other congestion-
avoiding bulk-transfer protocols that rely upon timers as well
as simple loss.

Input-side buffering, in large part because of the HOL blocking,
also does not lend itself well to congestion-mitigation techniques
like RED, EPD, SPD and the like, since one has to -- virtually speaking --
groom traffic into many different queues and identify which queues
on the outbound side are filling.

Trying to do statistical multiplexing in general across such
a switch is probably a really bad idea.  Use CBR and the like, basically.
Problem is, CBR and the like in the WAN world is not exactly cheaply
tariffed, however with low-delay cheap connections (e.g. in a LAN),
the switch can be OK if one is careful.   Witness the Gigaswitches,
which did just fine for a long time, before collapsing under HOL load,
then fine for a bit more when the microcode was rewritten to do lots
of individual input side output queues (before collapsing again :) ).

| With the
| larger memory configurations, you would have to work hard to find a
| pathological set of operations to cause cell drops.

Native IP multicast.   Don't deploy this switch on your MFI, kids,
unless all your egress interfaces are empty.

| No way to say.  It depends how the ATM providers in conjunction with
| government regulators charge for this technology.

Actually, government regulators are more a problem in the reverse
direction; there is a common pathological case where a tariffed E3
is at a set price, whereas the same ATM bandwidth can be priced
much more flexibly.  The entire ATM WAN industry is hugely subsidized
by the slowness to drop into market-based pricing on the traditional
PDH/SDH front.

| An issue of negotiation skills not of technology.

Oh, exactly; it's not technology.  ATM sucks.  But you can get a great
deal on ATM capacity because someone has to pay for the switches, or
because the other option is for the tariffed carrier to see you take
business to another bearer.

	 Sean.
-
Send 'unsubscribe' in the body to 'list-request@...' to leave.
Eat sushi frequently.   inet@... is the human contact address.

In a message dated 3/4/99 9:18:55 AM Eastern Standard Time,
ahp@... writes:

>>Joachim Martillo wrote:

>> My company does not run an ATM network, but we do consult to optimize

>> network performance over ATM networks.  How much work do you
>> do with ATM networks?

>I believe Dave already answered that, 'as little as possible' sums it
up.

Which perhaps indicates less than fluency with this technology.

>> I thought network operators liked to be able to reconfigure
>> bandwidth dynamically.

>> Anyway, you would apparently prefer to load share and disorder
>> packets.

>When you design your network from the ground up with your traffic
>patterns in mind then you don't need to dynamic traffic engineering.

Are you suggesting that a network designer can know for all time what
the network traffic patterns will be before the network even goes
on-line?

Most network administrators deal with rather more dynamic network
situations where there can be very large variations in traffic from
day to day, between day and night or as new customers come on line.

>If you find yourself with a network that has traffic patterns that
>don't match the underlying infrastructure then you deserve what you
>get.

Suppose one administers a network that services a tremendous amount of
business users from 8am -- 5pm and services a tremendous amount of
home users from 8pm -- 1am.

One could engineer the basic bandwidth infrastructure statically to
provide all the bandwidth the business and home users need at all
times, but if a technology is available that allows dynamic
reassignment of bandwidth at a cost savings, it might make sense to
make use of that technology and switch between alternate bandwidth
allocations between 5pm and 8pm and between 1am and 8pm.

>And no, I have never done much work with ATM.  Wanna know why?  I've
>never run a network that needs it.

Again another indication of less than fluency with this technology.

Joachim Martillo

The Packet Switching Technology list provides a forum for discussion
of packet switching theory, technology, implementation and application
in any relevantaspect including without limitation LAPB, X.25, SDLC,
P802.1d, LLC, IP, IPv6, IPX, DECNET, APPLETALK, FR, PPP, ATM, IP
Telephony, LAN PBX systems, management protocols like SNMP, e-mail,
network transparent window systems, protocol implementation, protocol
verification, conformance testing and tools used in maintaining or
developing packet switching systems.

This mailing list is of interest to developers, implementers, users,
marketeers, sellers and managers of packet switching technology,
systems and devices including bridges, routers, LAN switches,
Unix/WindowsNT LAPB/SDLC drivers, X.25 packet switches and FR
networks.

To join, go to http://www.egroups.com/list/packet-switching
and click on subscribe.



------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

In a message dated 3/4/99 1:13:36 PM Eastern Standard Time,
patrick@... writes:

>At 06:38 AM 3/4/99 -0500, Joachim Martillo wrote:
>>>AboveNet very much believes in and uses routed networks,

>>Probably a mistake.  To build a high performance packet-switched
>>backbone, the correct procedure is to build high performance
>>packet-switched WAN communications subnets and then interconnect these

>>packet-switched WAN communications subnets with a modicum of routing.

>>In point of fact, a routed network is simply a second order
>>packet-switched communications subnet whose links between the second
>>order packet switches are packet switched networks.

>>Why start with the complexity and performance cost of second order
>>packet switching before maxing out the performance of first order
>>packet switching?

>Hrmmm....

>I used to be a consultant, and this is definitely consultant-speak.

Actually, it is basic textbook-speak that describes the architectural
model of IP over the ARPANET.

>I am wondering if you have considered the complexity of encapsulating
>a layer three protocol inside another layer three protocol before
>running both layer three protocols over a layer two bit-repeated
>network?  Why would I want to add that complexity of both diagnosis
>and configuration?

I have not a clue what is meant.  ATM is basically a slightly more
flexible circuit technology.  What is called level 3 technology in
circuit switching is orthogonal to level 3 packet technology.

>When running a single layer three protocol over a bit-repeated
>network, the two layers are easily separated, diagnosed and
>maintained.  The complexity actually drops.  Add to that the fact
>there are easily available and far more mature IP diagnostic tools and
>you end up with a maintenance cost per Mbps far below that of an IP
>over ATM network.

The benefits of building an optimal level 2 communications subnet are
fairly self-evident.  With regard to LAN technology I notice that many
who take part in this list seem to be pulling out LAN hubs and
replacing them with LAN switches.

When one builds a virtual communications subnet on top of a more or
less WAN point-to-point circuit oriented technology like ATM, one can
build into the virtual communications subnet capabilities of
broadcast, full transitivity and simple connectivity that may be
lacking in the underlying technology without having to create the
level of complexity which one finds in reading the IETF specifications
associated with running IP over non-broadcast multi-access networks.

>>>         so there in
>>>fact may be more than one hop per data center through the network.
>>>But the total latency to do it with routers vs. "virtually" with ATM
>>>adds perhaps a few ms to an around-the-world trip for a packet, and
>>>AboveNet prefers to use the bandwidth it buys, not to throw large
>>>chunks of it away to encapsulation.

>>If one needs 600 Mbps on WAN links, one uses ATM and a 10% overhead
>>penalty might be a reasonable price to pay to achieve the needed
>>bandwidth.

>I do not see why any overhead is a reasonable price to achieve the
>bandwidth desired.  The lower the overhead, the better the
>cost/throughput ratio.  Why would one *want* to add overhead?

The statement is not well-formulated.  Even if ATM only provides 450
Mbps on 600 Mbps physical links (according to some of the worse
estimates that I have seen in the e-mail), if such 450 Mbps
connectivity is less costly than other 450 Mbps connectivity that one
might buy, using ATM technology would make economic sense.

If one needed dynamic circuit setup on 450 Mbps, I am not sure there
even are alternatives available.

>>If required burst bandwidths on links are frequently required that are

>>larger than a routed non-ATM network can provide, packets will so
>>frequently be queued that average latencies will be far more than a
>>few millisecs.

>First of all, that's a bad sentence even for a consultant.  Take out
>one of the "requireds."

>Secondly, if the burst bandwidth frequently required on an ATM network
>is greater than the layer two bit-repeated bandwidth available on the
>ATM network, then cells will be queued and/or dropped and latencies
>will grow to far more than a few milliseconds.

It depends on the ATM switch and the network configuration.  One
popular ATM switch uses an internal non-blocking space division
switch.  If the network does no dynamic circuit setup and makes no use
of the limited ATM broadcast capabilities, an ATM network built with
these switches never drops cells.  To handle limited ATM broadcast and
some amount of dynamic circuit setup, the ATM switch provides
(potentially tremendous amounts of) input side buffering.  With the
larger memory configurations, you would have to work hard to find a
pathological set of operations to cause cell drops.

>In fact, the likelihood of this happening on an ATM network far
>exceeds the likelihood of it happening on a traditional routed network
>due to the added overhead of ATM.

>I am wondering why you implied ATM can some how magically push data
>through links that routed networks cannot?

I am not sure which comment of mine is meant here.  BTW, if we are
going to quibble on style, is not "somehow" a single word?

>>>Because AboveNet is not going after the business market, supporting
IP
>>>telephony, video, VLANs, etc... there is no incentive to go to ATM
for
>>>any of those things, either (the things that traditionally make
people
>>>willing to throw away hundreds of thousands per month to inefficient
>>>encapsulation on long-haul circuits).

>>Inefficient in comparison with what?  Does Freedman have an
>>alternative approach to building 600 Mbps backbones with dynamically
>>allocable bandwidth?

>First: Where is the requirement for dynamically allocable bandwidth?

It is not uncommon to find corporations that reconfigure their voice
and data networks at different times of the day.  Ford was doing so at
least back into the first half of the eighties (I will point out that
Ford Aerospace built its own private satellite-based Internet with
Arpanet technology back in the 70s).

>Secondly: Assuming such a requirement, please show how a world-wide
>ATM WAN can provide this bandwidth on a more cost-effective scale for
>IP-only traffic than a traditional routed network.

No way to say.  It depends how the ATM providers in conjunction with
government regulators charge for this technology.

>           I think you will
>find that ATM bandwidth (actual throughput, not raw bandwidth) is at
>least as costly as raw layer-two bit-repeated bandwidth on a routed
>network when the network is pushing more than a few Mbps.  (How do I
>know this?  Personal experience. :))

An issue of negotiation skills not of technology.

>In the Third Place: You have not even shown that ATM can do as you are
>claiming.  (Please note I'm not saying you can't do it, just saying
>that you are making grandiose claims without actually showing any
>evidence to back up your claim.)

We work on a functioning ATM network every day.  But more to the
point, I recommend that you monitor the TCPSAT mailing list.  If I am
not mistaken, a lot of people involved in that mailing list are
involved with NASA's IP over ATM satellite network.

>>Joachim Martillo

>TTFN,
>patrick

>P.S. Did I mention I was a member of the ATM forum and have installed
ATM
>on a nationwide as well as local area scale? :)

I am not sure what the above comment is supposed to prove.

Joachim Martillo

The Packet Switching Technology list provides a forum for discussion
of packet switching theory, technology, implementation and application
in any relevantaspect including without limitation LAPB, X.25, SDLC,
P802.1d, LLC, IP, IPv6, IPX, DECNET, APPLETALK, FR, PPP, ATM, IP
Telephony, LAN PBX systems, management protocols like SNMP, e-mail,
network transparent window systems, protocol implementation, protocol
verification, conformance testing and tools used in maintaining or
developing packet switching systems.

This mailing list is of interest to developers, implementers, users,
marketeers, sellers and managers of packet switching technology,
systems and devices including bridges, routers, LAN switches,
Unix/WindowsNT LAPB/SDLC drivers, X.25 packet switches and FR
networks.

To join, go to http://www.egroups.com/list/packet-switching
and click on subscribe.



------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

In a message dated 3/4/99 2:02:33 PM Eastern Standard Time,
patrick@... writes:

>To all, this is getting pedantic, but I needed to LART someone and
>Joachim seems to deserve it so richly.  So, you can just skip this if
>you're not interested in the finer points of Joachim's absurd
>statements.

>At 08:08 AM 3/4/99 -0500, Joachim Martillo wrote:
>>In a message dated 3/4/99 7:40:22 AM Eastern Standard Time,
>>dlr@... writes:

>>> Words from a person that has obviously never run an ATM IP network.

>>My company does not run an ATM network, but we do consult to optimize
>>network performance over ATM networks.  How much work do you
>>do with ATM networks?

>Joachim,

>I am afraid that your claims are factually incorrect.  The 5 bytes of
>ATM header information does come to just under 10% of the total
>bandwidth, but that is assuming each cell is filled with data for
>exactly 48 bytes.  Have you looked into the actual encapsulation of an
>IP datagram into ATM?  Have you calculated the AAL5[SNAP|IP|whatever]
>overhead?

You will not get any argument from me that various standard WAN
encapsulations of IP are inefficient.  It is one of the reasons
various vendors of WAN technologies provide proprietary
encapsulations.  But the existence of bad encapsulations does not
imply that there is something wrong with ATM technology but only
implies that the understanding of some of the standards experts is
deficient.

>     Have you taken into account the pad bytes for cells that
>are not full?  (There's more, but let's see if he can answer those yet
>and find a couple on his own.)

Obviously, the ATM and level 3 drivers in the packet switches and end
hosts should be optimized to avoid sending lots of cells with padding.
All technologies have their own idiosyncrasies and complexities.  None
of the idiosyncrasies and complexities of ATM are particularly
insurmountable for reasonable driver writers.

>And, as long as we are discussing experience, exactly how many IP-only
>ATM networks have you installed, maintained, debugged, or even seen?
>To quote my friend Alec - Pot, Kettle, Black.

In the development environment we use ATM all the time.  We have a lot
of experience with two networks running IP (as well as other
protocols) over ATM.  Both networks are very large with diverse types
of usage.  And as I pointed out, I believe the TCPSAT mailing list can
be a source of public information on a NASA IP over ATM over satellite
link network.

>>>For bonus points, please calculate the efficiency of the link when
>>>carrying 64 byte IP frames.  Repeat for other common sizes.  Then
>>>throw away the paper, and try it, on live data.

>>ATM is perhaps not the best medium tinygram traffic.  In one
>>environment where we are current providing consulting work,
>>typical packet size is currently 10 kilobytes and will probably
>>increase.

>Perhaps we are not discussing the same issues here.  Dave and Avi are
>talking about IP traffic on the Internet.  There are these things
>called "ACK" packets which are prevalent in this environment.  I
>suggest you study the environment before you espouse an underlying
>technology for that environment.

If traffic is bidirectional TCP ACK's are piggybacked on data traffic.
If traffic is unidirectional, the ATM circuit may be underutilized in
one direction.  So what is the problem with some wasted padding?

>Here is the deal, ATM was invented as a compromise between multiple
>technologies -- analog (e.g., voice/video) and data (e.g., IP).  As a
>compromise, ATM is incapable of being the best transport mechanism
>when you are using only one of those technologies.  An ATM network
>with only IP traffic on it is wasting bandwidth, money and management
>resources for the analog data which is not being sent.  Why should we
>pay the cost (in time, effort and money), for something we will never
>use?

Obviously, you have to negotiate better with the public providers.

In any case, the basic WAN circuit technologies were developed to
carry voice.  Subsequently, a lot of engineering went into making them
carry data efficiently.  It does not seem unreasonable that telephony
system engineers should have tried to take more account of other uses
in developing a new circuit switched technology.

Anyway, I have noticed discussion of IP telephony on this list in the
past.  Perhaps, an ISP that had an ATM infrastructure might find it
reasonable to convert IP voice data into an ATM voice call as it comes
into the ISP's ATM network and then convert it back to IP voice as it
leaves the ISP's ATM network (or interwork the ATM voice circuit with
a POTS or ISDN circuit at the egress point from the ISP's ATM network).

>Your examples are irrelevant to the topic at hand.  Please feel free
>to use ATM for your environment (although I'm not certain it's the
>best even for your environment -- but I do not have enough data to be
>certain).

What do you feel is the topic at hand?  I thought it was how most
effectively build a WAN backbone by making use of WAN technologies
that are currently available.  How is the discussion of ATM irrelevant
to that topic?

>>>120 Mbps is the maximum you get on a 155 Mbps link (and we won't even

>>>*talk* about the bandwidth that is wasted on typical ATM
>>>implementations due to fragmentation of a 1.5K frame with one cell
>>>dropped in the middle).

>>I think that ATM network has yet to experience a cell drop.

>I am sorry, but you have zero experience with "that ATM network," and
>therefore are incapable of rendering a useful opinion.  *ANY* ATM OC3
>link which is attempting to push 155 Mbps of IP traffic will
>experience significant and continual cell loss.  The laws of physics
>do not change just because you think ATM doesn't drop cells.

I have no idea what is meant here.  Typical interface chips like the
IDT SAR do not drop cells in putting them on the wire.  If one
refrains from enqueuing partial frames onto outgoing queues, cells
will not drop on transmission.  If the driver has a reasonable
discipline for managing the receive queues, the processor is
sufficient fast and there is sufficient memory, cells will not be
dropped on reception.

>To be fair, though, most modern ATM switches do implement early packet
>discard, throwing out all the cells from a packet if one is lost in
>transit.

Could it be that they have reasonable interface logic and reasonable
ATM interface chips?

>>>Sure.  Install more links.  When you can concentrate the traffic to a

>>>few points on your network, rather than have to spread it out, you
>>>don't need to have dynamic bandwidth.

>>I thought network operators liked to be able to reconfigure
>>bandwidth dynamically.

>To which network operators are you referring?  As a network operator,
>I prefer to minimize my cost/throughput ratio.  If you can show me
>that ATM will cost me less to run than POSIP, I will happily run ATM.

Exactly.  The question is not technological at all.

>I should mention that I have researched this thoroughly for a
>nationwide IP-only network, and the results were not even close.  But
>I've been wrong before, and I'll be wrong again, so feel free to
>correct me.  Just be sure you have more data points than "I think"
>behind your pronunciations.

A nationwide IP-only network may not make sense because hybrid
networks with a mix of IP and other traffic carried over mixed
technologies may have more economies and more benefits.

>>Anyway, you would apparently prefer to load share and disorder
>>packets.

>I am confused.  When did Dave mention load sharing?

He mentioned using multiple links in a redundant network to provide
aggregate bandwidths comparable to the 600 Mbps (450 Mbps) links that
an ATM network could provide.

Current best routing practice is to load-share between equal
or near equal cost routing paths.

>Add to that, since when did load sharing disorder packets?

Packet one on a TCP circuit follows one path through many hops and
queues.  Packet two on the same TCP circuit follows another path
through many hops and queues.  Because of queuing and transit delay
packet one arrives at the final destination after packet two.

>            Have you
>actually done load sharing on an IP network?

Yes.  I also implement routers, bridges, LAN switches, X.25 switches
and FR switches.  When I worked at Bell Labs, I took part
in the design of large circuit switches.

>            Can you describe the
>different algorithms for load sharing in a Cisco router?

Yes.

>          Since you
>obviously have no such experience, I invite you to take your own
>advice and speak not of that which you do not know.

>>>You can get all that you actually pay for, and your customers don't
>>>have to hear lame excuses about "ATM overhead."

>>A network provider that does not have sufficient expertise
>>in a technology should refrain from offering services
>>based on that technology or should work to obtain
>>sufficient expertise.

>Sorry, but I have to say this again:

>Pot, Kettle, Black.

>I love that line. :)

Joachim Martillo

The Packet Switching Technology list provides a forum for discussion
of packet switching theory, technology, implementation and application
in any relevantaspect including without limitation LAPB, X.25, SDLC,
P802.1d, LLC, IP, IPv6, IPX, DECNET, APPLETALK, FR, PPP, ATM, IP
Telephony, LAN PBX systems, management protocols like SNMP, e-mail,
network transparent window systems, protocol implementation, protocol
verification, conformance testing and tools used in maintaining or
developing packet switching systems.

This mailing list is of interest to developers, implementers, users,
marketeers, sellers and managers of packet switching technology,
systems and devices including bridges, routers, LAN switches,
Unix/WindowsNT LAPB/SDLC drivers, X.25 packet switches and FR
networks.

To join, go to http://www.egroups.com/list/packet-switching
and click on subscribe.



------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

On Thu, 4 Mar 1999, Joachim Martillo wrote:

> A network provider that does not have sufficient expertise
> in a technology should refrain from offering services
> based on that technology or should work to obtain
> sufficient expertise.
>
> Joachim Martillo

Sounds good. Seeing as how you have no experience running IP networks, how
about unsubscribing from this list and letting us get on with the job?

--
Michael Dillon                 -               E-mail: michael@...
Check the website for my Internet World articles -  http://www.memra.com



------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

On Thu, 4 Mar 1999, Joachim Martillo wrote:

> http://members.aol.com/tprovoni/book1/chapter1/Image43.gif
> shows a picture of an ATM Cell.
>
> It has 5 header bytes and 48 information field octets.
>
> (5/53) * 100 = 9.43%

This is theory not practice. Internet engineers have years of practical
experience with IP over ATM and know the problems that combination causes.
You are also not including the empty octets in the ATM cells caused when a
variable length IP packet is not a multiple of 48 octets. Not to mention
the effects that cell loss has, i.e if a single cell is lost then ATM will
still transport all the other cells carrying the broken IP packet to its
destination even though this is a total waste of bandwidth. This issue has
been hashed out many times at NANOG meetings and on the NANOG mailing list
http://www.nanog.org so you are not likely to win converts on this list.

At the present time it is established fact that ATM is a bad transport
layer for IP which is why there are so many initiatives to do IP over
SONET or IP over glass.

> The question remains whether there exists an alternative approach to
> build a 600 Mbps backbone with dynamically allocatable bandwidth.

It's called IP.

--
Michael Dillon                 -               E-mail: michael@...
Check the website for my Internet World articles -  http://www.memra.com



------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

At 06:38 AM 3/4/99 -0500, Joachim Martillo wrote:
>>AboveNet very much believes in and uses routed networks,
>
>Probably a mistake.  To build a high performance packet-switched
>backbone, the correct procedure is to build high performance
>packet-switched WAN communications subnets and then interconnect these
>packet-switched WAN communications subnets with a modicum of routing.
>
>In point of fact, a routed network is simply a second order
>packet-switched communications subnet whose links between the second
>order packet switches are packet switched networks.
>
>Why start with the complexity and performance cost of second order
>packet switching before maxing out the performance of first order
>packet switching?

Hrmmm....

I used to be a consultant, and this is definitely consultant-speak.

I am wondering if you have considered the complexity of encapsulating a
layer three protocol inside another layer three protocol before running
both layer three protocols over a layer two bit-repeated network?  Why
would I want to add that complexity of both diagnosis and configuration?

When running a single layer three protocol over a bit-repeated network, the
two layers are easily separated, diagnosed and maintained.  The complexity
actually drops.  Add to that the fact there are easily available and far
more mature IP diagnostic tools and you end up with a maintenance cost per
Mbps far below that of an IP over ATM network.

>>         so there in
>>fact may be more than one hop per data center through the network.
>>But the total latency to do it with routers vs. "virtually" with ATM
>>adds perhaps a few ms to an around-the-world trip for a packet, and
>>AboveNet prefers to use the bandwidth it buys, not to throw large
>>chunks of it away to encapsulation.
>
>If one needs 600 Mbps on WAN links, one uses ATM and a 10% overhead
>penalty might be a reasonable price to pay to achieve the needed
>bandwidth.

I do not see why any overhead is a reasonable price to achieve the
bandwidth desired.  The lower the overhead, the better the cost/throughput
ratio.  Why would one *want* to add overhead?

>If required burst bandwidths on links are frequently required that are
>larger than a routed non-ATM network can provide, packets will so
>frequently be queued that average latencies will be far more than a
>few millisecs.

First of all, that's a bad sentence even for a consultant.  Take out one of
the "requireds".

Secondly, if the burst bandwidth frequently required on an ATM network is
greater than the layer two bit-repeated bandwidth available on the ATM
network, then cells will be queued and/or dropped and latencies will grow
to far more than a few milliseconds.

In fact, the likelihood of this happening on an ATM network far exceeds the
likelihood of it happening on a traditional routed network due to the added
overhead of ATM.

I am wondering why you implied ATM can some how magically push data through
links that routed networks cannot?

>>Because AboveNet is not going after the business market, supporting IP
>>telephony, video, VLANs, etc... there is no incentive to go to ATM for
>>any of those things, either (the things that traditionally make people
>>willing to throw away hundreds of thousands per month to inefficient
>>encapsulation on long-haul circuits).
>
>Inefficient in comparison with what?  Does Freedman have an
>alternative approach to building 600 Mbps backbones with dynamically
>allocatable bandwidth?

First: Where is the requirement for dynamically allocatable bandwidth?

Secondly: Assuming such a requirement, please show how a world-wide ATM WAN
can provide this bandwidth on a more cost-effective scale for IP-only
traffic than a traditional routed network.  I think you will find that ATM
bandwidth (actual throughput, not raw bandwidth) is at least as costly as
raw layer-two bit-repeated bandwidth on a routed network when the network
is pushing more than a few Mbps.  (How do I know this?  Personal experience. :)

In the Third Place: You have not even shown that ATM can do as you are
claiming.  (Please note I'm not saying you can't do it, just saying that
you are making grandiose claims without actually showing any evidence to
back up your claim.)

>Joachim Martillo

TTFN,
patrick

P.S. Did I mention I was a member of the ATM forum and have installed ATM
on a nationwide as well as local area scale? :)

**************************************************************
Patrick W. Gilmore                  voice: Oh, wait, it's gone
FORMER Director of Operations         fax: Damn, this one too!
    The Backbone formerly known as PRIORI NETWORKS, INC. ;-)
                     http://www.priori.net
               "Tomorrow's Performance.... Never"
**************************************************************

------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

To all, this is getting pedantic, but I needed to LART someone and Joachim
seems to deserve it so richly.  So, you can just skip this if you're not
interested in the finer points of Joachim's absurd statements.

At 08:08 AM 3/4/99 -0500, Joachim Martillo wrote:
>In a message dated 3/4/99 7:40:22 AM Eastern Standard Time,
>dlr@... writes:
>
>> Words from a person that has obviously never run an ATM IP network.
>
>My company does not run an ATM network, but we do consult to optimize
>network performance over ATM networks.  How much work do you
>do with ATM networks?

Joachim,

I am afraid that your claims are factually incorrect.  The 5 bytes of ATM
header information does come to just under 10% of the total bandwidth, but
that is assuming each cell is filled with data for exactly 48 bytes.  Have
you looked into the actual encapsulation of an IP datagram into ATM?  Have
you calculated the AAL5[SNAP|IP|whatever] overhead?  Have you taken into
account the pad bytes for cells that are not full?  (There's more, but
let's see if he can answer those yet and find a couple on his own.)


And, as long as we are discussing experience, exactly how many IP-only ATM
networks have you installed, maintained, debugged, or even seen?  To quote
my friend Alec - Pot, Kettle, Black.


>>  For bonus points, please calculate the efficiency of the link when
>carrying
>>  64 byte IP frames.  Repeat for other common sizes.  Then throw away
>the
>>  paper, and try it, on live data.
>
>ATM is perhaps not the best medium tinygram traffic.  In one
>environment where we are current providing consulting work,
>typical packet size is currently 10 kilobytes and will probably
>increase.

Perhaps we are not discussing the same issues here.  Dave and Avi are
talking about IP traffic on the Internet.  There are these things called
"ACK" packets which are prevalent in this environment.  I suggest you study
the environment before you espouse an underlying technology for that
environment.


Here is the deal, ATM was invented as a compromise between multiple
technologies - analog (e.g. voice/video) and data (e.g. IP).  As a
compromise, ATM is incapable of being the best transport mechanism when you
are using only one of those technologies.  An ATM network with only IP
traffic on it is wasting bandwidth, money and management resources for the
analog data which is not being sent.  Why should we pay the cost (in time,
effort and money), for something we will never use?

Your examples are irrelevant to the topic at hand.  Please feel free to use
ATM for your environment (although I'm not certain it's the best even for
your environment - but I do not have enough data to be certain).


>>  120 Mbps is the maximum you get on a
>>  155 Mbps link (and we won't even *talk* about the bandwidth that is
>>  wasted on typical ATM implementations due to fragmentation of a 1.5K
>>  frame with one cell dropped in the middle).
>
>I think that ATM network has yet to experience a cell drop.

I am sorry, but you have zero experience with "that ATM network", and
therefore are incapable of rendering a useful opinion.  *ANY* ATM OC3 link
which is attempting to push 155 Mbps of IP traffic will experience
significant and continual cell loss.  The laws of physics do not change
just because you think ATM doesn't drop cells.

To be fair, though, most modern ATM switches do implement early packet
discard, throwing out all the cells from a packet if one is lost in transit.

>>  Sure.  Install more links.  When you can concentrate the traffic to a
>few
>>  points on your network, rather than have to spread it out, you don't
>need to
>>  have dynamic bandwidth.
>
>I thought network operators liked to be able to reconfigure
>bandwidth dynamically.

To which network operators are you referring?  As a network operator, I
prefer to minimize my cost/throughput ratio.  If you can show me that ATM
will cost me less to run than POSIP, I will happily run ATM.

I should mention that I have researched this thoroughly for a nationwide
IP-only network, and the results were not even close.  But I've been wrong
before, and I'll be wrong again, so feel free to correct me.  Just be sure
you have more data points than "I think" behind your pronunciations.

>Anyway, you would apparently prefer to load share and disorder
>packets.

I am confused.  When did Dave mention load sharing?

Add to that, since when did load sharing disorder packets?  Have you
actually done load sharing on an IP network?  Can you describe the
different algorithms for load sharing in a cisco router?  Since you
obviously have no such experience, I invite you to take your own advice and
speak not of that which you do not know.

>>  You can get all that you actually pay for, and your
>>  customers don't have to hear lame excuses about "ATM overhead".
>
>A network provider that does not have sufficient expertise
>in a technology should refrain from offering services
>based on that technology or should work to obtain
>sufficient expertise.

Sorry, but I have to say this again:

Pot, Kettle, Black.

I love that line. :)


>Joachim Martillo

TTFN,
patrick

I Am Not An Isp - www.ianai.net
ISPF, The Forum for ISPs by ISPs, <http://www.ispf.com>
"Think of it as evolution in action." - Niven & Pournelle

------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

In a message dated 3/4/99 7:40:22 AM Eastern Standard Time,
dlr@... writes:

> Words from a person that has obviously never run an ATM IP network.

My company does not run an ATM network, but we do consult to optimize
network performance over ATM networks.  How much work do you
do with ATM networks?

>  For bonus points, please calculate the efficiency of the link when
carrying
>  64 byte IP frames.  Repeat for other common sizes.  Then throw away
the
>  paper, and try it, on live data.

ATM is perhaps not the best medium tinygram traffic.  In one
environment where we are current providing consulting work,
typical packet size is currently 10 kilobytes and will probably
increase.

>  120 Mbps is the maximum you get on a
>  155 Mbps link (and we won't even *talk* about the bandwidth that is
>  wasted on typical ATM implementations due to fragmentation of a 1.5K
>  frame with one cell dropped in the middle).

I think that ATM network has yet to experience a cell drop.

> 34 Mbps is all you get on
>  an ATM DS3.

>  > The question remains whether there exists an alternative approach
to
>  > build a 600 Mbps backbone with dynamically allocatable bandwidth.

>  Sure.  Install more links.  When you can concentrate the traffic to a
few
>  points on your network, rather than have to spread it out, you don't
need to
>  have dynamic bandwidth.

I thought network operators liked to be able to reconfigure
bandwidth dynamically.

Anyway, you would apparently prefer to load share and disorder
packets.

>  You can get all that you actually pay for, and your
>  customers don't have to hear lame excuses about "ATM overhead".

A network provider that does not have sufficient expertise
in a technology should refrain from offering services
based on that technology or should work to obtain
sufficient expertise.

Joachim Martillo



------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

[In the message entitled "Re: [NET-DESIGN] Wide Area Network Backbones" on Mar 
4,  7:31, Joachim Martillo writes:]
> In a message dated 3/4/99 7:08:34 AM Eastern Standard Time,
> dlr@... writes:
>
> >[In the message entitled "[NET-DESIGN] Wide Area Network Backbones" on
> Mar  4,  6:38, Joachim Martillo writes:]
> >> If one needs 600 Mbps on WAN links, one uses ATM and a 10% overhead
> >> penalty might be a reasonable price to pay to achieve the needed
> >> bandwidth.
>
> >If one could show another one which planet ATM had a 10% overhead on an
>
> >IP network, I would be a happy man.
>
> >ATM has a nominal 25% overhead IMHO, and it gets *way* worse with small
>
> >(ACK) packets.  I don't want the throw away 155 Mbps on a OC12 link,
> >thanks.
>
> http://members.aol.com/tprovoni/book1/chapter1/Image43.gif
> shows a picture of an ATM Cell.
>
> It has 5 header bytes and 48 information field octets.
>
> (5/53) * 100 = 9.43%
>

Words from a person that has obviously never run an ATM IP network.

For bonus points, please calculate the efficiency of the link when carrying
64 byte IP frames.  Repeat for other common sizes.  Then throw away the
paper, and try it, on live data.  120 Mbps is the maximum you get on a
155 Mbps link (and we won't even *talk* about the bandwidth that is
wasted on typical ATM implementations due to fragmentation of a 1.5K
frame with one cell dropped in the middle).  34 Mbps is all you get on
an ATM DS3.

> The question remains whether there exists an alternative approach to
> build a 600 Mbps backbone with dynamically allocatable bandwidth.
>

Sure.  Install more links.  When you can concentrate the traffic to a few
points on your network, rather than have to spread it out, you don't need to
have dynamic bandwidth.  You can get all that you actually pay for, and your
customers don't have to hear lame excuses about "ATM overhead".


--
Dave Rand
dlr@...
http://www.bungi.com

------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

In a message dated 3/4/99 7:08:34 AM Eastern Standard Time,
dlr@... writes:

>[In the message entitled "[NET-DESIGN] Wide Area Network Backbones" on
Mar  4,  6:38, Joachim Martillo writes:]
>> If one needs 600 Mbps on WAN links, one uses ATM and a 10% overhead
>> penalty might be a reasonable price to pay to achieve the needed
>> bandwidth.

>If one could show another one which planet ATM had a 10% overhead on an

>IP network, I would be a happy man.

>ATM has a nominal 25% overhead IMHO, and it gets *way* worse with small

>(ACK) packets.  I don't want the throw away 155 Mbps on a OC12 link,
>thanks.

http://members.aol.com/tprovoni/book1/chapter1/Image43.gif
shows a picture of an ATM Cell.

It has 5 header bytes and 48 information field octets.

(5/53) * 100 = 9.43%

The question remains whether there exists an alternative approach to
build a 600 Mbps backbone with dynamically allocatable bandwidth.

Joachim Martillo



------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

>AboveNet very much believes in and uses routed networks,

Probably a mistake.  To build a high performance packet-switched
backbone, the correct procedure is to build high performance
packet-switched WAN communications subnets and then interconnect these
packet-switched WAN communications subnets with a modicum of routing.

In point of fact, a routed network is simply a second order
packet-switched communications subnet whose links between the second
order packet switches are packet switched networks.

Why start with the complexity and performance cost of second order
packet switching before maxing out the performance of first order
packet switching?

>         so there in
>fact may be more than one hop per data center through the network.
>But the total latency to do it with routers vs. "virtually" with ATM
>adds perhaps a few ms to an around-the-world trip for a packet, and
>AboveNet prefers to use the bandwidth it buys, not to throw large
>chunks of it away to encapsulation.

If one needs 600 Mbps on WAN links, one uses ATM and a 10% overhead
penalty might be a reasonable price to pay to achieve the needed
bandwidth.

If required burst bandwidths on links are frequently required that are
larger than a routed non-ATM network can provide, packets will so
frequently be queued that average latencies will be far more than a
few millisecs.

>Because AboveNet is not going after the business market, supporting IP
>telephony, video, VLANs, etc... there is no incentive to go to ATM for
>any of those things, either (the things that traditionally make people
>willing to throw away hundreds of thousands per month to inefficient
>encapsulation on long-haul circuits).

Inefficient in comparison with what?  Does Freedman have an
alternative approach to building 600 Mbps backbones with dynamically
allocatable bandwidth?

Joachim Martillo

The Packet Switching Technology list provides a forum for discussion
of packet switching theory, technology, implementation and application
in any relevantaspect including without limitation LAPB, X.25, SDLC,
P802.1d, LLC, IP, IPv6, IPX, DECNET, APPLETALK, FR, PPP, ATM, IP
Telephony, LAN PBX systems, management protocols like SNMP, e-mail,
network transparent window systems, protocol implementation, protocol
verification, conformance testing and tools used in maintaining or
developing packet switching systems.

This mailing list is of interest to developers, implementers, users,
marketeers, sellers and managers of packet switching technology,
systems and devices including bridges, routers, LAN switches,
Unix/WindowsNT LAPB/SDLC drivers, X.25 packet switches and FR
networks.

To join, go to http://www.egroups.com/list/packet-switching
and click on subscribe.



------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

[When Xylan first went public, the management made a confident
declaration that Xylan would overtake Cisco as the major bridge router
supplier.  The network interfaces of Xylan bridge routers were fully
powered bridges or LAN switches.  While such an integrated L2/L3
architecture is superior to the Cisco router architecture, which is
built around routing with the recent addition of a switching oriented
veneer, Xylan developed switching hardware with particularly high
latency and some performance problems.  In addition, because the Xylan
architects never fully generalized the integrated L2/L3 switching
techniques to backbone wide-area networks, there was no obvious reason
to prefer Xylan devices to Cisco devices in the implementation of
wide-area backbones.]

XYLAN : Alcatel to acquire Xylan

03/02/99
M2 PRESSWIRE
Copyright 1999 M2 Communications, Ltd. All Rights Reserved.

To extend its technology lead in the fast growing market for voice and
data networks, Alcatel (NYSE: ALA) today announced it has entered into
a definitive agreement to acquire Xylan Corporation (NASDAQ: XYLN) for
$37 a share. The transaction is valued at approximately $2.0 billion.

This acquisition will be made by a cash tender offer for all
outstanding shares.  The tender offer will commence by Monday, March 8
and will be scheduled to expire 20 business days
thereafter. Completion of the acquisition is subject to 90% of the
shares being tendered, the expiration or termination of applicable
waiting periods under applicable antitrust laws, and other customary
conditions. All shares not purchased in the tender offer will be
acquired by merger for cash at the same price per share. The deal is
expected to be completed in the beginning of April 1999. The Boards of
Directors of both companies have unanimously approved the acquisition,
and the Xylan Board of Directors has recommended that Xylan 's
shareholders accept Alcatel's all-cash tender offer.

"Alcatel has devised and is implementing a comprehensive strategy to
become a key worldwide player in the Internet field, capitalizing on
its leadership position in major telecommunications markets and
technologies.  This strategy encompasses the targeted acquisitions of
leading IP-focused companies, leveraging Alcatel's strengths to
leapfrog competition. A major step is the acquisition of Xylan , a
long-time partner, which I am happy to announce today", said Serge
Tchuruk, Chairman and CEO of Alcatel. "The combined Alcatel/ Xylan
strengths in voice and data networking for enterprises will constitute
a very powerful force in world corporate markets. In addition, Xylan
technologies for carriers' data networks will remarkably complement
other actions underway to build a leading Alcatel offering for
converged voice/data carriers' networks."

Xylan provides Alcatel with a superior portfolio of data switching
equipment and a fast-growing position in the enterprise data market,
where Xylan is developing well above market trends. The combined
Alcatel/ Xylan product offering will surpass competition in the
enterprise market, both in terms of performance and spread of
functionalities. Xylan 's strong inroads in the carriers' markets, in
particular, managed LAN services and the forthcoming traffic
aggregation equipment, will substantially enhance solutions developed
by Alcatel for service providers.

"In the face of industry giants, Xylan has grown beyond anyone's
expectations over the last five years because we've offered the best
technology available. The synergies from combining that technology
with Alcatel's resources will provide a dramatic boost to Xylan 's
future success," said Steve Kim, president and chief executive officer
of Xylan .

"We are very pleased to expand the partnership we began four years ago
with Xylan . Alcatel has delivered Xylan products throughout the world
and is one of Xylan 's leading partners," said Olivier Houssin,
executive vice president of Alcatel Telecom. "We are confident that we
will be able to effectively integrate Xylan into the Alcatel
organization and rapidly bring its products to an expanded market. In
particular, it is our plan to continue to sell Xylan products through
their existing distribution channels. In addition, the Xylan
acquisition gives Alcatel access to the enterprise market in the
U.S. and will allow our Group to play a leading role in the integrated
voice/data private networking market in North America."

A new center for Alcatel enterprise data networking

Xylan will become the center of competence for all of Alcatel's
enterprise data networking solutions. Xylan 's expertise will be
combined with Alcatel's leadership in enterprise voice networks to
provide converged voice/data solutions.

Alcatel recently announced its 4400 IP PCX (private communications
exchange), a full-blown IP-based communication platform, which
includes voice application servers, unified messaging, Web-enabled
call centers, IP telephones, and other applications. Combining this
with Xylan 's best-of-breed enterprise switching systems gives Alcatel
the power to deliver a complete integrated solution.

Adds depth to service provider networks

Xylan will also provide key additions to Alcatel's IP and ATM
solutions for service providers, focusing on Internet access, DSL data
services, cable modem data services, and multi-service virtual private
networks.

Xylan is currently working with more than 100 carrier customers,
including Bell South and Bell Atlantic, Teleport, and Rhythms in the
U.S., MetroNet in Canada, Telewest in the U.K., and Telia in
Sweden. Together, Xylan and Alcatel will leverage Alcatel's presence
in the carrier marketplace and Xylan 's unique intelligent edge
switches to offer unmatched service provider solutions.

About Alcatel

A world leader in telecommunications systems and equipment as well as
related cables and components activities, Alcatel operates in over 130
countries. Alcatel provides complete solutions and services to
operators, service providers, enterprises and consumers, ranging from
backbone networks to user's terminals. For more information, visit the
Alcatel web at www.alcatel.com.

About Xylan

Xylan has been the fastest growing internetworking company in the
history of the industry, acquiring more than 4,000 customers and
growing total revenues to $348 million in just five years. In each of
the last two years, the company has grown approximately 65%,
outstripping the growth of the data networking market. More
information about Xylan and its products is available at www.  xylan
.com.

This document may include forward-looking statements within the
meaning of Safe Harbor provisions of the U.S. federal securities
laws. These statements are based on current expectations, estimates
and projections about the general economy and Alcatel's and Xylan 's
lines of business and are generally identifiable by statements
containing words such as "expects," "believes," "estimates," or
similar expressions. Statements related to the future performance
involve certain assumptions, risks and uncertainties, many of which
are beyond the control of Alcatel or Xylan , and include, among
others, foreign and domestic product and price competition, cost
effectiveness, changes in governmental regulations, general economic
and market conditions in various geographic areas, interest rates and
the availability of capital. Although Alcatel and Xylan believe their
respective expectations reflected in any such forward-looking
statements are based upon reasonable assumptions, they can give no
assurance that those expectations will be achieved.

*M2 COMMUNICATIONS DISCLAIMS ALL LIABILITY FOR INFORMATION
PROVIDED WITHIN M2 PRESSWIRE. DATA SUPPLIED BY NAMED
PARTY/PARTIES.*

CONTACT: Peter Benedict Tel: +1 818 878 4693 Brian Riggs Tel: +1 818
878 4715 Heather Ritchie Tel: +1 408 474 0469 Gina Rollo Tel: +1 818
878 4835 David Rodewald Tel: +1 818 878 4976 Christophe Lachnitt Tel:
+33 (0)1 40 76 12 19 e-mail: christophe.lachnitt@... Niall
Hickey Tel: +33 (0)1 40 76 11 56 e-mail: niall.hickey@...
Claire Pedini Tel: +33 (0)1 40 76 13 93 e-mail:
Claire.pedini@... Charlotte Laurent-Ottomane Tel: +33 (0)1 40
76 13 30 e-mail: Charlotte.Laurent-Ottomane@... Stephane Mermet
Tel: +33 (0)1 40 76 16 04 e-mail: Stephane.mermet@... Michael
Haase (US) Tel: +1 972 519 68 55 e-mail: mhaase@... David
Rodewald, Xylan Tel: +1 818 878 49 76 e-mail: drodewald@ xylan .com
Contact: CONTACT: Peter Benedict Tel: +1 818 878 4693 Brian Riggs Tel:
+1 818 878 4715 Heather Ritchie Tel: +1 408 474 0469 Gina Rollo Tel:
+1 818 878 4835 David Rodewald Tel: +1 818 878 4976 Christophe
Lachnitt Tel: +33 (0)1 40 76 12 19 e-mail:
christophe.lachnitt@... Niall Hickey Tel: +33 (0)1 40 76 11 56
e-mail: niall.hickey@... Claire Pedini Tel: +33 (0)1 40 76 13
93 e-mail: Claire.pedini@... Charlotte Laurent-Ottomane Tel:
+33 (0)1 40 76 13 30 e-mail: Charlotte.Laurent-Ottomane@...
Stephane Mermet Tel: +33 (0)1 40 76 16 04 e-mail:
Stephane.mermet@... Michael Haase (US) Tel: +1 972 519 68 55
e-mail: mhaase@... David Rodewald, Xylan Tel: +1 818 878
49 76 e-mail: drodewald@ xylan .com



------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

In a message dated 3/2/99 2:34:15 PM Pacific Standard Time, jlewis@...
writes:

> On Tue, 2 Mar 1999, Rahul Dhesi wrote:

> > Offhand I can't think of any other advantage that NT has in a pure
> > server role.  However, for the small business, NT is convenient in that
> > you can use the same machine as both your workstation and your web
> > server.

> Of course, we used to do this with X on Linux.

The combination of X with Linux as workstation is superior to using
the WindowsNT server as a workstation, for the X windows system
provides network transparent window service, which means that the
virtual high resolution raster graphics devices may be used for output
by any running program in exactly the same way if the program is
running on the same machine as the X server or even if the program is
not running on the same machine as the X server.  The underlying
architecture and model of computation used by the X Window System is
very different from that of Microsoft Windows.

Joachim Martillo

The packet switching technology mailing list provides a forum for
discussion of packet switching theory, technology, implementation and
application in any relevant aspect including without limitation LAPB,
X.25, SDLC, P802.1d, LLC, IP, IPv6, IPX, DECNET, AppleTalk, FR, PPP,
IP Telephony, LAN PBX systems, management protocols like SNMP, e-mail,
network transparent window systems, protocol implementation, protocol
verification, conformance testing and tools used in maintaining or
developing packet switching systems.

This mailing list is of interest to developers, implementers, users,
marketeers, sellers and managers of packet switching technology,
systems and devices including bridges, routers, LAN switches,
Unix/WindowsNT LAPB/SDLC drivers, X.25 packet switches and FR
networks.

To join go to http://www.egroups.com/list/packet-switching, and click
join.



------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

Microsoft provides a source control management system called Visual
Source Safe (VSS).  The system looks like a combination of a modified
version of RCS, a database system and a visual interface.  We use it
for maintaining the sources for

1) the VLAN Router (a multiprotocol WAN LAN switch router) that runs
on standard PCI bus Intel Architecture platforms,

2) LAPB, SDLC and X.25 drivers for Solaris,

3) a windows lpr program (for printing from Gnu Emacs on PCs) and

4) several other utilities and drivers.

Aspects of VSS are not bad.  Others are extremely annoying.  I have a
top level project called $/VLAN Router in my workspace.  Under the
$/VLAN Router are several subproject directories that correspond to
subdirectories of a default working directory to which $/VLAN Router
might be assigned, e.g.

$/VLAN Router/X.25,
$/VLAN Router/L2CORE,
$/VLAN Router/INCLUDE,
$/VLAN Router/DRIVERS,
$/VLAN Router/L2UTIL

etc.

As long as no default directory has been assigned to a subproject
directory, a subproject directory inherents the default directory of
its parent as a relative starting point.

Thus

1) if $/VLAN Router has a default directory of c:\vrouter and

2) if $/VLAN Router/DRIVERS has no default directory of its own,
$/VLAN Router/DRIVERS receives a default directory c:\vrouter\DRIVERS.

Unfortunately, if one at some point accidentally or purposefully
assigns a default directory to a subproject directory, that subproject
directory can no longer inherent default directory relative starting
points from its parent.

Thus,

1) if $/VLAN Router/X.25 has been assigned a default directory
d:\vrouter/X.25 while $/VLAN Router/L2CORE has not been assigned a
default directory and

2) if $/VLAN Router is assigned a new default directory
c:\vrouter.new, the resulting default directory assignments are the
following.

$/VLAN Router -> c:\vrouter.new
$/VLAN Router/L2CORE -> c:\vrouter.new\L2CORE
$/VLAN Router/X.25 -> d:\vrouter\X.25

We have not found a way to remove subproject directory assignments
from the visual interface, and the manual, which Microsoft provides is
unhelpful.  In a typical non-network setup, default directory
assignments are found on a per user basis at the file

c:/Program Files/DevStudio/Vss/users/username/ss.ini

in a format something like the following.

[$/VLAN Router]
Dir (ISJFVKLH) = C:\vrouter

[$/VLAN Router/X.25]
Dir (ISJFVKLH) = d:\vrouter\X.25

[$/VLAN Router/INCLUDE]
Dir (ISJFVKLH) = d:\vrouter\INCLUDE

Removing the subproject directory default directory assignements (the
last two entries above) restores normal default directory inheritance.
If anyone knows a way to restore normal inheritance from the visual
interface, I would be interested to learn about it.

Joachim Martillo



------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

[Providing technical support is an important part of the packet
switching business.  Because of the complexity of systems and
protocols, more technical support is often required in the packet
switching business than in other areas of hi-tech.  The following
describes some interesting incidents in tech support.]

Just in case you think you are TC (technologically challenged).  The
following is an excerpt taken from a Wall Street Journal article:

1. Compaq is considering changing the command "Press Any Key" to
"Press Return Key" because of the flood of calls asking where the
"Any" key is.

2. AST technical support had a caller complaining that her mouse was
hard to control with the dust cover on.  The cover turned out to be
the plastic bag the mouse was packaged in.

3. Another Compaq technician received a call from a man complaining
that the system wouldn't read word processing files from his old
diskettes. After trouble-shooting for magnets and heat failed to
diagnose the problem, it was found that the customer had labeled the
diskettes, then rolled them into the typewriter to type the labels.

4. Another AST customer was asked to send a copy of her defective
diskettes.  A few days later a letter arrived from the customer along
with photocopies of the floppies.

5. A Dell technician advised his customer to put his troubled floppy
back in the drive and close the door.  The customer asked the tech to
hold on, and was heard putting the phone down, getting up and crossing
the room to close the door to his room.

6. Another Dell customer called to say he couldn't get his computer to
fax anything.  After 40 minutes of trouble-shooting, the technician
discovered the man was trying to fax a piece of paper by holding it in
front of the monitor screen and hitting the "send" key.

7. Yet another Dell customer called to complain that his keyboard no
longer worked.  He had cleaned it by filling up his tub with soap and
water and soaking board for a day, then removing all the keys and
washing them individually.

8. A Dell technician received a call from a customer who was enraged
because his computer had told him he was "bad and an invalid". The
tech explained that the computer's "bad command" and "invalid"
responses shouldn't be taken personally.

9. A confused caller to IBM was having troubles printing documents. He
told the technician that the computer had said it "couldn't find
printer". The user had also tried turning the computer screen to face
the printer - but that his computer still couldn't "see" the printer.

10. An exasperated caller to Dell Computer Tech Support couldn't get
her new Dell Computer to turn on. After ensuring the computer was
plugged in, the technician asked her what happened when she pushed the
power button. Her response, "I pushed and pushed on this foot pedal
and nothing happens." The "foot pedal" turned out to be the computer's
mouse.

11. Another customer called Compaq tech support to say her brand-new
computer wouldn't work.  She said she unpacked the unit, plugged it in
and sat there for 20 minutes waiting for something to happen. When
asked what happened when she pressed the power switch, she asked "What
power switch?"

12. True story from a Novell NetWire SysOp:

Caller: "Hello, is this Tech Support?"

Tech: "Yes, it is. How may I help you?"

Caller: "The cup holder on my PC is broken and I am within my warranty

period.  How do I go about getting that fixed?"

Tech: "I'm sorry, but did you say a cup holder?"

Caller: "Yes, it's attached to the front of my computer."

Tech: "Please excuse me if I seem a bit stumped, It's because I am.
Did you receive this as part of a promotional, at a trade show? How
did you get this cup holder? Does it have any trademark on it?"

Caller: "It came with my computer, I don't know anything about a
promotional.  It just has '4X' on it.

At this point the Tech Rep had to mute the caller, because he couldn't
stand it. He was laughing too hard.  The caller had been using the
load drawer of the CD-ROM drive as a cup holder, and snapped it off
the drive!

13. Another IBM customer had troubles installing software and rang for
support. "I put in the first disk, and that was OK.  It said to put in
the second disk, and had some problems with the disk.  When it said to
put in the third disk - I couldn't even fit it in..."  The user hadn't
realized that "Insert Disk 2" meant to remove Disk 1 first.

14. In a similar incident, a customer had followed the instructions
for installing software. The instructions said to remove the disk from
it's cover and insert into the drive. The user had physically removed
the casing of the disk and wondered why there were problems.

------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

Internet Long-distance Calling

CNN stated that the Government would in two weeks time decide to allow or
not allow a charge to your phone bill equal to a long distance call each
time you access the internet.

The House of Representatives has a web page showing how to contact your
congressman. The address is http://www.house.gov/writerep/ Please visit the
address above and fill out the necessary form! This is not a joke....but
REAL. We all were aware that our government has been pressured by the
telephone companies to consider such a charge, and now it's reality.

If EACH one of us forwards this message on to others in a hurry, we may be
able to prevent this injustice from happening. Please take the time and
visit the url address and follow the instructions. Your vote may make a BIG
difference. None of us should be charged a long distance call each time we
access the Internet.

In addition, please forward this to all your friends and relatives that also
access the Internet.

Joe

----------------------------------------------------------------------------

				 From: JayEffUU <oldace65@...>
				 Date: Saturday, February 27, 1999 10:46 PM
				 Subject: Internet Long-distance Calling



------------------------------------------------------------------------

------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

[Stockholm, SWEDEN] Swedish utility company Sydkraft recently began
using its power lines to feed end users with high-speed Internet
connections, providing a permanent connection at a flat rate.

The company is using Digital PowerLine technology from NOR.WEB, a
joint venture between Nortel and British company United
Utilities. PowerLine allows users to connect to a permanent connection
without using a phone line.

Electric Internet access marks the latest trend in European
connectivity.  Italy began testing a similar service in Rome recently.

To provide the service, Sydkraft has teamed up with leading Swedish
Internet service provider Tele2. Under the agreement, Sydkraft will
use Tele2's infrastructure to connect customers to the Internet.

"This is broadband technology that goes directly into the users'
homes," said Pelle Hjortblad at Tele2.

The service currently has 100 subscribers, but the company said if all
goes well, it will sign on more users.

"We think the potential in this type of market is great. This is an
investment in developing new services to our customers," said Jonas
Svantesson responsible for marketing at Sydkraft. He added the program
could potentially serve one million customers.

Sydkraft said it thinks that small enterprises and home office, along
with regular homes, will be the main market for its new service.

The company plans to charge a flat rate of around $45 per month, which
gives users up to 1 Mbps in both directions. A special modem-type box
is also needed, which costs around $300.

The price structure for connecting the Net via the power lines is
about the same as the cable operators are charging in Sweden. But not
everyone has cable connection, which gives connection through power
lines a big advantage, because this is available to every house.

Flat rate offers are sparking a lot of interest at the moment, because
with all dial-in connections, users have to pay a charge per minute to
the phone operator in the Swedish market.

------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

BEIJING (AP) -- China will slash long-distance telephone and Internet
fees, the government announced today. Chinese have faced high costs
for making international phone calls and surfing the Internet. While
these costs will drop beginning tomorrow, postal fees will go up 20
percent to 60 percent, the Ministry of Information Industry
announced. Using the Internet in China was 30 times more expensive
than in the United States, according to news reports. China Telecom
said the high prices hurt demand.

------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

Anyone involved with packet switching systems becomes aware of the
innumerable official and unofficial specifications that are used as
inputs into the development of these systems.  Often, the implementer
or user has to wonder how a relevant specification came to be.

The article below, which has circulated on the Web for a long time, is
not true.  The USA had at least two railroad gauges before the Civil
War.  I am not sure there was only one gauge for British tramways -- a
manufacturer had no interest in making it easier for a competitor to
take his business.  The British gauge and continental European gauges,
which have at least as much if not more reason to follow Roman
specifications, differ.

Still, one almost wishes the premise of this article were true at
least in some area of engineering specification if only to provide a
sort of coherence where a general rational is lacking.

Joachim Martillo

How Specs Live Forever

The US Standard railroad gauge (distance between the rails) is 4 feet,
8.5 inches.  That's an exceedingly odd number.  Why was that gauge
used?

Because that's the way they built them in England, and the US
railroads were built by English expatriates.

Why did the English people build them like that?  Because the first
rail lines were built by the same people who built the pre-railroad
tramways, and that's the gauge they used.

Why did "they" use that gauge then?  Because the people who built the
tramways used the same jigs and tools that they used for building
wagons, which used that wheel spacing.  Okay!

Why did the wagons use that odd wheel spacing?  Well, if they tried to
use any other spacing, the wagons would break on some of the old, long
distance roads, because that's the spacing of the old wheel ruts.

So who built these old rutted roads? The first long-distance roads in
Europe were built by Imperial Rome for the benefit of their
legions. The roads have been used ever since.

And the ruts?  The initial ruts, which everyone else had to match for
fear of destroying their wagons, were first made by Roman war
chariots. Since the chariots were made for or by Imperial Rome, they
were all alike in the matter of wheel spacing. Thus, we have the
answer to the original question.

The United States standard railroad gauge of 4 feet, 8.5 inches
derives from the original specification for an Imperial Roman army war
chariot.

Specs and Bureaucracies live forever.  So, the next time you are
handed a specification and wonder what *** came up with it, you may be
exactly right. Because the Imperial Roman chariots were made to be
just wide enough to accommodate the back-ends of two war horses.


------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

>SNMP v3 people:

> I am trying to learn ASN.1.  More specifically, I am trying to
>put a training plan together to teach SNMP.  Every time I mention
>SNMP, or show someone the SMI, I get thousands of questions about the
>macros and syntax and what this means and that inside of the SMI.
> SO...  That said.  I already tried getting a copy of the
>December 1987 version of ASN.1, and that it is proving difficult (I
>already tried ANSI and ISO).  Where can I get a copy of this?  Anybody
>out there know?  Are there textbooks out there on ASN.1?

As has been pointed out, you will need the CCITT Bluebook X.208 and
X.209 specifications.  The Steedman book is helpful

1) because it elucidates those specifications,

2) because it describes the intent of the designers of ASN.1 and

3) because it supports the contention that the principals in the
design of SNMP (the so-called Gang of Four) were severely confused.

A web page describing the contents of the Steedman book can be found
at the following URL.

http://www.techapps.co.uk/contasn.html

Another possibly useful web site is the following.

http://www-sop.inria.fr/rodeo/personnel/hoschka/asn1.html

When trying to explicate ASN.1 in the context of the various forms of
SNMP and their associated SMIs, it is worthwhile to point out that the
Gang of Four misused or misunderstood the concepts that underlay ASN.1

ASN.1 is meant to be a transfer syntax description language (as
Steedman points out).  The rational of ASN.1 as a transfer syntax
description language postulates a set of abstract objects that are
indexed by Object Identifiers or OIDs.  In a given context, an Object
corresponds to a specific Type.  In the given context, Instances of
the specific Type that corresponds to the Abstract Object will have
corresponding Values.  ASN.1 is used to define of the syntax of
transfering Values of a specific Type to another context, wherein the
Abstract Object will correspond to another Type.

For example, suppose there is an abstract FileHandle Object with a
unique OID, which corresponds

(1) in the context of the DOS operating system to the
DosFileHandleType,

(2) in the context of the HP-UX operating system to the
HpUxFileHandleType and

(3) in the context of NFS to the NfsFileHandleType.

To transfer a value associated with an instance of the
HpUxFileHandleType, which corresponds to the abstract FileHandle
Object, from the HP-UX File Server to a DOS client, the
hpUxFileHandleValue of the instance is converted to the
nfsFileHandleValue as it is transferred to the network and is
converted from the nfsFileHandleValue to the dosFileHandleValue as it
is transferred from the network to the DOS client.  ASN.1 is used to
describe the syntax of such transfers.

Because the Gang of Four completely missed the distinction among
objects, instances and types that the designers of ASN.1 were making,
they somehow thought it made sense to (mis-)use OIDs as sorts of
addresses of the management variables in a virtual data store.

Because an object can reasonably have none, one or many instances,
such a kludge really cannot work.  In a vain attempt to obviate this
fairly significant problem, the Gang of Four introduced a particularly
arbitrary and nonsensical distinction between single instance and
multiple instance management variables.

Because the definition of the bridge MIB assumed that P802.1d
management variables like root bridge ID were single instance
variables, I ran into problems with the SMI when I architected a
bridge router (the VLAN Router)

1) whose network interfaces were fully powered bridges or LAN
switches and

2) for which I needed to provide an SNMP interface to get values like
the root bridge ID on each individual network interface/LAN switch.

In point of fact, the problem really exists with any single instance
variable.  Why, for example, should there only be one system contact
for a network device?

During the rancorous (d)evolution of SNMP in its various mutations,
all sorts of workarounds for the inadequacy of the SMI have appeared.
All of these proposals have been overly complex and problematic.  The
correct solution would have been

1) to acknowledge the fundamental insurmountable inadequacy of
SNMP,

2) to declare that SNMP was the perfect solution for managing network
toasters but nothing else and

3) to seek a complete replacement for SNMP.

Unfortunately, such a procedure, while perfectly good and reasonable
engineering, never seems to take place in the IETF milieue.

> I am not on the mailing list because I have read your archives
>and it was painful.  I just want to know where I can get some the
>above mentioned things.  Please e-mail me directly if you know...
>Thanks!!!

IETF discussion lists are established for groups of people that want
to define or to specify a protocol, procedure or system.  Providing
explanations, justifications or logic of the underlying assumptions is
of less importance and is often treated as a distraction from working
group goals.

For systematic analysis and discussion of packet switching systems and
related topics, the Packet Switching Technology mailing list described
below may be more useful.

Joachim Martillo

This mailing list [Packet Switching Technology] provides a forum for
discussion of packet switching theory, technology, implementation and
application in any relevant aspect including without limitation LAPB,
X.25, SDLC, P802.1d, LLC, IP, IPv6, IPX, DECNET, APPLETALK, FR, PPP,
IP Telephony, LAN PBX systems, management protocols like SNMP,
protocol implementation, protocol verification, conformance testing
and tools used in maintaining or developing packet switching systems.

This mailing list is of interest to implementers, users and managers
of packet switching technology, systems and devices including bridges,
routers, LAN switches, Unix/WindowsNT LAPB/SDLC drivers, X.25 packet
switches and FR networks.

------------------

   http://www.egroups.com/list/packet-switching

provides an interface to join the mailing list.

Members can post messages to its members via e-mail at:

   packet-switching@egroups.com

Members can also read and post group messages on the Web:

   http://www.egroups.com/list/packet-switching

Please direct any comments or questions about the group to the group
moderator at:

   packet-switching-owner@egroups.com



------------------------------------------------------------------------
eGroup home: http://www.eGroups.com/list/packet-switching
Free Web-based e-mail groups by eGroups.com

This mailing list provides a forum for discussion of packet switching theory,
technology, implementation and application in any relevant aspect including
without limitation LAPB, X.25, SDLC, P802.1d, LLC, IP, IPv6, IPX, DECNET,
APPLETALK, FR, PPP, IP Telephony, LAN PBX systems, management protocols like
SNMP, protocol implementation, protocol verification, conformance testing and
tools used in maintaining or developing packet switching systems.


Group Manager: packet-switching-owner@egroups.com

To subscribe, send a message to packet-switching-subscribe@egroups.com or go to
the e-group's home page at http://www.egroups.com/list/packet-switching