It occurred to me that it might be useful to include David Reed in the route
for this msg.
David, hoping you will have time to comment on the notes below. The
hack4dean guys are building a network to support regime change and then
some.
best,
Jon L.
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
Subject: [hackers] Re: Edge-to-Edge Principal / Reed's Law
Hi, Zack.
Thanks for the pointers. I'm copying the list on this so we can all
have the same context in this discussion.
1. THE END-TO-END ARGUMENT
--
On Thu, 31 Jul 2003, zachary rosen wrote:
http://www.wikipedia.org/wiki/End-to-end_argument
[...]
A lot more can be found on Edge to Edge (also referred to as end to
end) from google. It is something that has been talked about for
quite some time.
Ah -- now i see that you are talking about what is familiar to me as
the end-to-end argument. I do know the Saltzer, Reed, and Clark
paper [1]. I wondered if this is what you meant by edge-to-edge,
but you seemed to be describing something so different from the
end-to-end argument that i assumed you must have meant something else.
I think you have misunderstood what Saltzer et al. were trying to say.
Let me try to explain. The end-to-end argument is a design
principle that has to do with deciding whether system functionality
should be placed at high levels or low levels. The paper argues that
functions placed at low levels may be redundant or to costly to be
worth it, because the same functions often have to get reimplemented
by the higher levels anyway -- because the higher levels (e.g. the
application) know their own needs better.
Putting functionality at a lower level amounts to making an assumption
that every application will want that functionality. But if your
assumption is wrong, the lower levels might waste a lot of resources
trying to provide a service that the application doesn't even need.
So you should rely on intelligence at the highest level (in the case
of a network, the endpoints of communication) instead of getting too
obsessed with the lower levels.
For example, it might seem reasonable to assume that a network should
always deliver error-free packets. So adding a checksum-and-retry
feature to a network layer in order to guarantee accurate delivery may
seem like a good idea. But there are some applications that care more
about speed than accuracy -- such as voice over IP -- and these would
be harmed by the inefficiency of a checksum-and-retry feature.
Now let's return to our question about whether the media database
should be centralized. Regardless of whether it is centralized or
distributed, we are still obeying the end-to-end argument: we are not
putting any smarts in the transport layer (TCP/IP); we are totally
relying on smarts at the endpoints of communication (that is, the Web
browser and the Web server). No one is putting in functions at a low
level that are getting reimplemented at a higher level.
So the end-to-end argument has no bearing on our decision at all.
In particular, it is purely an efficiency argument, and it doesn't
say anything about peer-to-peer networks. (Be warned, by the way,
that lots of companies use the terms end-to-end and peer-to-peer
because they are fashionable, not because they know what they mean.)
2. REED'S LAW
-
http://www.wikipedia.org/wiki/Reed%27s_law
Originally, my response was going to be that Reed's Law has no effect
on our decision either. Reed's Law says that the utility of a network
is exponentially related to the number of participants. But it
doesn't matter whether you have 5 users at site A and 5 users at site
B, or just 10 users at site Z -- you still have 10 users, and utility
on the order of 2^10. The utility is the same regardless of whether
the database is centralized or distributed.
But then i went back and read the original paper [2] and thought about
it a little more. Now i've realized that Reed's Law actually argues
in *favour* of a centralized database.
Notice that the paper doesn't say all networks have utility that
scales exponentially in the number of participants. It refers to a
specific *type* of network -- a Group-Forming Network. In his
words:
A GFN has functionality that directly enables and supports
affiliations (such as interest groups, clubs, meetings,
communities) among subsets of its customers. Group tools and
technologies (also called community tools) such as user-defined
mailing lists, chat rooms, discussion groups, buddy lists, team
rooms, trading rooms, user groups, market makers, and auction
hosts, all have a common theme -- they allow small or large
groups of network users to coalesce and to organize their
communications around a common interest, issue, or goal.
The reason that the utility scales exponentially is that, if N people
are allowed to form and coordinate their own
