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

[Richard Bennett]

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 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 to this problem is deeply flawed. 
In order to share resources according to a policy, there needs to be a 
system element enforcing the policy. 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 reliability and trust in end systems; and 
b) the lack of information about system demand on the part of the end 
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.

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.

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.

RB

Detlef Bosau wrote:
> O.k., I still don't have an idea, what this argument is all about.
>
> Nevertheless:
>
> Richard Bennett wrote:
>> Classical Ethernet - the co-ax cable-based, Aloha-derived CSMA/CD 
>> system - is one of the canonical examples of a purely edge-managed 
>> network.
>
> First of all, classical Ethernet is the canonical example of classical 
> Ethernet.
>
> Period.
>
> No one was forced to use classical Ethernet, and no one was forced to 
> avoid classical Ethernet.
>
> The discussion initiated by Salzer, Reed and Clark was _not_, whether 
> or not a certain network technology should have management capabilies, 
> leaky bucket facilities, SNMP agents or whatever. Instead, the authors 
> invite us to carefully
> consider, where certain functions, duties, responsibilities should be 
> placed and where not.
>
> IIRC, Dave Reed told us, there were no such think like an "end to end 
> principle" some weeks ago.
>
> And in fact, there is none. But it is useful to carefully consider the 
> placement and separation of concerns and responsibilities. No more, no 
> less.
>
>
>> It actually hails from the era during which the Internet protocols 
>> were designed, and expresses a similar set of engineering trade-offs.
>
> And scientists and priests still argue, whether we hail from adam and 
> eve - or from apes and evolution.
>
> Would this make a difference? Despite of the fact, that mankind should 
> rather behave like apes (and hopefully, apes still do!), because we 
> wouldn't have seen thermonuclear weapons and many other "human 
> inventions" then?
>
> When I use a network, my primary interest is not its historical origin 
> but its use for my problem.
>
>> Thirty-five years after the design of Ethernet, we've dropped the 
>> purely edge-managed approach to building layer 1 and 2 networks in 
>> favor of somewhat more centralized systems: Switched Ethernet, 
>> DOCSIS, DSL, Wi-Max, and Wi-Fi are the leading examples. 
>
> You mentioned some examples where some separations of concerns might 
> have been done in a different way than 1985.
>
> Wonderful!
>
> When there are compelling reasons for doing so: Go ahead!
>
>>
>> While we now know that edge-managed LANs and MANs are not the way to 
>> go, we still use edge-managed protocols to
>
> Why not?
>
> Typically, it's a good idea to fit a solution to a problem and not the 
> other way round.
>
> So, first of all, I will have a look at my problem, e.g. how many 
> systems are to be connected, are there constraints, e.g. I must not 
> use a wireline connection in a certain scenario and so on, and then I 
> will make a choice for a certain networking technology.
>
> This may be switched Ethernet - or it may be something different. 
> Depending on my actual needs and my actual constraints.
>
>
>> operate the Internet. The Jacobson Algorithm is probably the purest 
>> example.
>
> And I don't see, how switched Ethernet provides an alternative to VJCC.
>
>>
>> The triumph of switched and semi-centralized systems at layer 2 
>> suggests that it might be beneficial to revisit some of
>
> Excuse me, but where is the triumph of switched Ethernet over VJCC?
>
>> the design tradeoffs at layer 3 if for no other reason than to bring 
>> them up-to-date. In principle, IP isn't supposed to care what's 
>> happening at layer 2, 
>
> but it's always a good idea for IP, not to ignore the lower layers.
>
> (I'm actually writing a very small and tiny network simulator, because 
> NS2 and other ones are still to big for my purposes and it's quite 
> appealing to have a small simulator in some few hundred lines of Java, 
> which simply does its job.
>
> However, it would really spare me quite a few night sessions, if IP 
> could really ignore the lower layers.)
>
>> but in practice it makes a great deal of difference; this is one 
>> reason that people design networks nowadays with the express 
>> intention of being good for IP; e.g., MPLS.
>>
>
> Excuse me, but I don't see your point.
>
> We can well discuss the advantages of circuit switching over packet 
> switching or the other way round.
>
> However, both have their justification and both are in use for several 
> decades now.
>
> And I really don't see the big difference between placing a flow label 
> into an Ethernet frame or to introduce some
> "Flow Switching Over Ethernet Protocol (FSOEP)" to achieve the same goal.
>
> This is a major argument for minor a minor benefit.
>
> Detlef
>

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