[e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument
richard at bennett.com
Thu Nov 12 18:45:19 PST 2009
I'm not persuaded that the best engineering solution always wins the
prize, Bob: VHS vs. Beta for example. I think there's a lot of evidence
to suggest that non-engineering factors have had a lot to do with the
hegemony of TCP/IP.
It's difficult to respond in detail to the following as much of it is
mid-sentence complaints about thing that happen to be answered in the
next phrase or so, but I will say I don't imply that the designers of
internetworks didn't think abstractly; Pouzin certainly did and still
does.But I am saying the argument that a particular sub-optimal design
is best for a production network because it happens to avoid
fate-sharing or support innovation seems a bit like grasping at straws.
Secure, reliable, and efficient networks support innovation best.
Bob Braden wrote:
> Richard Bennett wrote:
>> Detlef, I'm asking you to think abstractly about certain problems in
>> the design of distributed systems. I regard many of the
>> interpretations and applications of end-to-end notions to network
>> management and regulation as flawed, regardless of the intent of any
>> of the authors of any particular paper decades ago, or even to their
> Richard, I am sure that the Internet designers (who wrote running
> code before they wrote papers) will be greatly
> relieved to know that you ascribe good intentions to them. My only
> problem is that you think they were well intnetioned but wrong, while
> I believe that they were well intentioned and right. Given the history
> of the Internet,
> this seems hard to deny.
>> subsequent refinement by the original authors or others.
>> One the problems that arises in distributed systems is access to
>> shared resources, and the end-to-end solution
> Yes, and those shared resources are queues (or equivalently, lines)
>> to this problem is deeply flawed.
> This seems to be proof by assertion.
>> In order to share resources according to a policy, there needs to be
>> a system element enforcing the policy.
> Well, no. There are papers showing that is not strictly true..
>> In network operations, this function is indispensable and must be
>> part of the network infrastructure. There are many reasons for this,
>> of course, but the chief ones are a) the lack of
> The Internet demonstrates that your assertion "must be part of the
> network infrastructure" is incorrect.
>> reliability and trust in end systems; and b) the lack of information
>> about system demand on the part of the end
> The fate sharing concept shows that the reliability and trust in end
> systems is irrelevant.
>> system, which in principle only knows that it wants and not what
>> anyone else wants to do on the shared resource.
>> The idea that access to shared resources is best accomplished by
>> uncoordinated end systems leads to a lot of grief.
> "Greif" is one of those loaded words that is inappropriate to this
> discussion, but in any case "uncoordinated end systems" also leads to
> a lot of advantages, like application-neutrality of the network. Have
> you Skyped lately? A lot of people will be surprised when you tell
> them it is fatally flawed.
>> What does this have to do with Jacobson's Algorithm? A lot, it turns
>> out, as we see in the rise of systems that take the job of congestion
>> mediation a couple of steps further, such as ECN and Re-ECN. If you
>> recognize that information about the state of shared resources is
>> essential to their rational management, no problem.
> "Rational" -- another of those Words. It clearly is not essential (we
> got along pretty well with simple VJCC and cumulative ACKs, but
> certainly SACK, RED, and ECN all extend the range of efficient
> But yes, I agree with you, it helps a lot if the end systems have some
> knowledge of conditions along the path.
>> Of course, all of this is simply to say that optimal solutions to
>> problems of resource management can only be made close to the
>> resource in question, but it doesn't address a later version of the
>> end-to-end arguments principle, that sub-optimal solutions (from an
>> efficiency of fair-sharing perspective) to such problems may be
>> preferred if they lead to greater system generality, opportunities
>> for innovation, free speech, reliability, or some other reason.
>> I hear this sort of argument being made very frequently these days,
>> and it does have some resonance. Efficiency is after all a short-term
>> goal, while generality is a long-term goal and innovation is a
>> positive externality. But to appreciate that, one needs to think a
>> bit abstractly.
> So we are having an agreement, except for your implication that the
> Internet designers did not think abstractly but you do. I can assure
> you that they did think abstractly, and around 1980 came to exactly
> the conclusions of your last paragraph.
> Now can we find some new Dead Horse to beat? Or even add some new
> Bob Braden
Information Technology and Innovation Foundation
More information about the end2end-interest