> From: Erik Fair <fair(_at_)clock(_dot_)org>
> Almost all of the pressure created by the growth of the Internet is
> on the network operators and their vendors (e.g. router vendors),
> rather than on the users and the end systems (and the end system
> vendors
Well, there are rational (?) structural reasons for this. i) There are more
end systems than infrastructure boxes, so it's more work to change the
former. ii) The end system boxes are often under the control of people who
have less technical expertise, contacts, organization, etc than the
infrastructure boxes, so it's more work to change them.
All of which leads to solutions being jammed into the infrastructure boxes,
which are easier to get to, rather than the end system boxes, where it may
be desirable for architectural reasons. I wish a had some idea how to
change this, but I don't (short of finding some killer app and bundling it
with an end system architectural upgrade).
> So, with nearly all the pressure on the operators and the vendors
> that serve them, the "solutions" they come up with are necessarily
> pretty ugly hacks (e.g. NAT, TCP spoofing, Firewalls) because they
> have to deal with the reality that they can't change the end systems
> themselves, or require them to be changed.
There's another factor, which is that short-term fixes are less expensive
in the here-and-now than fixes with a longer horizon. You see this effect
operating even in areas that *don't* involve the end systems (e.g. routing).
> This is a structural problem. Until the situation changes, we're
> going to keep on seeing ugly hacks that do violence to the Internet
> architectural model deployed, marketed, touted as "solutions."
In the past, it has been a truism of system architecture that systems
usually die because i) the basic architecture had things missing; ii) the
'improvements' done to rectify these problem are usually poorly
thought-out/intergrated "warts" added by programmers who are new hires and
don't really have the vision/confidence to fundamentally alter things; and
iii) eventually the system crumbles under the addition of all these warts,
and you have to throw it all out and start again from scratch.
What's novel about the Internet is that i) the people making the additions
are not all working for one company, but are a large collection of people
without any central control, and ii) the process of "starting from scratch"
will be even more painful, since you not only have to keep the old system
running, but have it interoperate with the new one while the changeover is
happening. (Think NCP->TCP conversion, but ^69th.)
I'm not sure what the model is to make this happen, but I've come to the
conclusion that the IETF process, as the IETF has evolved, is not the way
to do it.
Noel