SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : LAST MILE TECHNOLOGIES - Let's Discuss Them Here -- Ignore unavailable to you. Want to Upgrade?


To: Frank A. Coluccio who wrote (9610)12/10/2000 8:05:36 AM
From: justone  Respond to of 12823
 
Frank:

Technology may annihilate distance as a limiting attribute of the Ethernet, but
not ownership and control problems.

When I owned an ethernet, I controlled who got on it, when, and where. I
controlled the numbering plan, and chastised the users who overloaded the
servers, and told people what they could and could not do with their
workstations.

Given that my outdated view of the Ethernet as that good old LAN with
vampire taps and cables and host servers and workstation clients has been
bypassed by new protocols and technologies, I still wonder if there is an
important distinction between a 'private' Ethernet and a 'public' one. This, not
distance, is still important, I think.

Now, if I want to be completely free to enter this ether at any point on the
cloud I can do so. Why not? Are you suggesting that a service order and the
installation of a medium to the side of my home, which must necessarily follow,
is anti-ethernet?


No, ethernet owners always controlled access, albeit in a simpler way than with
the old PSTN switches. But the LAN owner of a private ethernet also had
more control over the computers- in the public ethernet this won't be the case.
Remember that one major point of the ethernet was that it distributed control.
Network providers are frightened of this, since you can't control the stuff on an
end users computer or terminal. This is one reason why DOCSIS has so many
protocols to manage the end terminal.

The fact that it is switched v. shared is another area where I feel it is
inconsequential today, especially when we use Layer 3 switching, where we
resolve to an IP address that is being advertised by my very own end point
(even if I do have to go through a DHCP or a NAT occasionally).


Switching vs sharing is important for traffic concerns, security, and reliability
issues in addition to numbering. This is my big concern with HFC based
phones, for example. Because we are trying to share the network with different
traffic types, we are getting some really amazing and complex new protocols
for QoS, recovery, security, and even billing.

I agree with you on one point: I don't think numbering is that important in this
issue: directory name services have made this issue somewhat moot. Typically,
you can solve numbering problems by going to a higher level. IP address can
be private (more or less) and even 'illegal'- or local- using NAT, but
webnames and emails are public. You only have to find a way to pay someone
for managing the name servers.

And while switching is not important for addressing today, the coming of QoS
and security, with IP over MPLS stacks, may have a fairly large impact on the
way traffic is handled. Basically, we a putting a little bit of content into our
formerly clean contentless protocol stacks.

You reach a conclusion, which I can partially agree with, except that I
don't think you've followed through all the way on certain issues: "Which,
when you look at what a switched port is, is nothing radically different in
principle, although the newer ports are backed up with a
lot more intelligence and speed, with some of them looking at the upper
layers for instructions, to boot..."

My first impulse is to ask, How could the early pioneers of Ethernet, and the
greater 'Net, twenty-five years ago have taken such a negative position as you
suggest against switched Ethernet, if switched Ethernet
didn't come into play until the Nineties?

Unless, of course, you are drawing an analogy to the PSTN type of switched,
which is in another league altogether, and therefore doesn't belong.


Yes, except I would say that the early pioneers were the ones drawing the
analogy, not me. Now whenever you write a patent, or publish a paper, you
want to claim you are proposing something new, something without prior art,
something exciting. So they were comparing and contrasting their net with
other nets, and with the PSTN dial up 300 baud modem net in particular. They
were not being negative, just comparative. But you can forgive inventors for
slanting the discussion in their own favor!

BTW, this is one of the reasons I like to view historical readings such as
you've presented. The volumetric and timeliness requirements of those
laboratory folks at that stage of the Internet's growth were almost quaint by
today's standards, wouldn't you agree? Their notions about store and
forward, for example? How does this play against today's caching models,
where information is not only stored, but updated from time to time, sometimes
on cue, to keep it fresh? Another example of how the 'Net is both evolving, on
the one hand, and devolving, on the other, at the same time.

And their expectations of what the network could, or should, deliver, were also
limited by the developments of the day, just as ours are today.


Well, let us list what is timeless, and time bound.

Timeless (things thought about and covered)
- topology (star vs. LAN)
- queuing - store and forward, fully distributed vs. network hubs
- salability - adding a station at any point
- numbering
- multicasting
- central vs. distributed control

Timebound (things they didn't know about and didn't cover, or thought were
other people's problems and didn't belong in the network)
- volume expectations
- caching on the net and not in the computer (actually, this might be covered,
since one point of the ethernet was to have Smart distributed intelligence in the
terminals, and not in the network- they just rejected network based caching
along with network based numbering and switching and control)
- multi-media traffic
- mobile or nomadic stations
- real time requirements and quality of service
- security

These latter are what is causing not the Ethernets but IP networks and the
internet to change.
--------------

I just read a great piece by Judy Estrin (ex-Precept, then ex-Cisco, and now
head of Packet Design), btw, where she devotes a part of her interview to
the potential evils of MPLS, when it is taken to places where, in her opinion, it
oughtn't oughta be. And for some of the same reasons that you have
cited, centering on the tensions between switched and end to end, shared.
Briefly, she cites how initially MPLS was viewed as a means of reconciling
the mapping of ATM and IP to one another, but how since those early days
it's been viewed as a panacea for all ills. Great stuff. It's in the January
Cook Report on Internet, if you can get your hands on a copy.


When I first looked at the MPLS solution, I was fascinated to note that the
QoS solution for IP, took a layer of ATM protocol, and glued it under IP
packets. I see a whole LOT of problems with this and other multi-media traffic solutions.
Basically, to solve the QoS problems, we must overrule IP! We must destroy
the forest to save the trees.

To be fair, what is really going on, as I've observed before, is that the backend
network will be 'un-converged', while we want to use a padded up IP to
support multi-media packets in the access networks. The crazy thing is that the
professors currently don't have the mathematical models to know if any of this
multi media stuff will work- we will have to try it and see.

I'm sure the Cook report is quite good, but I'm not sure it is worth $575! There are a lot of whitepapers for free at
packetdesign.com,
including "Clouds vs Strings: Why IP Will Continue to Provide the Foundation of the Internet", by Judy Estrin, CEO