[e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument

[Richard Bennett]

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.

RB

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 
> performance.
> 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 
> insights?
>
> Bob Braden
>
>>
>> RB
>>
>>>
>>
>
>

-- 
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC