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

[Bob Braden]

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
>
>>
>