{'Borrowing' a new, more appropriate Subject: from a private reply...}
> From: John C Klensin <john-ietf(_at_)jck(_dot_)com>
> What does this say about the IETF and how we make decisions? Does that
> need adjusting?
Perhaps, but even I shrink from tackling that particular windmill!
> while ... recriminations based on hindsight may be satisfying in some
> ways, the question is what to do going forward.
I couldn't agree with your latter point more.
> There are communities out there who believe that we have managed to
> "prove" that datagram networks, with packet-level routing, are a
> failure at scale and that we should be going back to an essentially
> connection-oriented design at the network level.
I (perhaps obviously) think that's a rash conclusion: the circa 1975 Internet
architecture was never intended to grow to this size, and that it has done so
at all (albeit via the use of a number of hacks, some merely kludgy, others
downright ugly) is a testament to how well the basic concept (of unreliable
packets, and minimal state in the network) works.
I do think that the architecture does require some work, though, and for a
number of reasons. For one, the real requirements have become more complex as
the network has grown, and a number that have arrived (e.g. provider
independence for users; the need for ISP's to be able to manage traffic
flows; etc) aren't really handled well (or at all) by the existing
architecture. For another, we need to bring some order to the cancerous chaos
that has resulted from piecemeal attempts to deal with the previous point.
Finally, it's a truism of system design that arrangements that work at one
order of scale don't at another, and as the network has grown beyond almost
our wildest expectations - and certainly larger than it was ever designed to
- I think we're seeing that too.
> If not, then there are other focused discussions that would be helpful.
> The latter discussions that have almost started in this and related
> threads, but have (I believe) gotten drowned out by the noise, personal
> accusations about fault, and general finger-pointing.
Well, sometimes one has to clear the air (or underbrush, if you will), and
get everyone's minds open, before one can make forward progress. But I agree,
'hah-hah, your end of the ship is sinking' rapidly becomes totally
unproductive.
> How would you propose moving forward?
Well, IMO there are a number of things we need to do, which can be done all
in parallel.
The first is to be honest with ourselves, and with the people out there who
depend on us to set direction, about what's really likely to happen out in
the network; e.g. a very long period during which we are stuck with multiple
naming realms with various kinds of translators (NATxx) gluing them together.
This whole 'don't worry, everything will be fine' schtick has got to go -
we're now in what I call "The Emperor's New Protocol" land, where (almost)
everybody knows the theoretical plan isn't going to work, and major revisions
are needed, but nobody wants to come right out and say so formally.
We need to do that.
I think a group (set up by the IAB, who make these kind of pronouncements)
should sit down and draw up a _realistic_ picture of what the future over the
next couple of years (say, up to 5 years out - 5 only, because of a second
parallel effort, below) is likely to be, and get that out, so people have a
realistic appraisal of how things stand (and restore a little bit of the I*'s
credibilty, in the process).
That group (or perhaps a sister group) should produce a formal statement
covering the implications for IETF work of that present/future; i.e. about the
_existing_ architectural environment in which the protocols the IETF designs
have to operate, and thus have to be designed for. E.g. a formal IETF policy
statement 'all IETF protocols MUST work through NAT boxes'. Etc, etc.
The second is to set up a group (and again, this is the IAB's job) to try and
plan some sort of evolutionary architectural path, which would have two
phases: i) to survey all classes of stakeholders (ISP's, content providers,
users) to see what the network needs to be able to do that it can't now, and
ii) provide both a) an architecture that meets those needs, and b) a
_realistic_ plan for getting there. Realistic in economic, interoperability,
etc terms - all the things we have learned (painfully) are so critical to the
viable roll-out of new stuff.
Do note that that effort implies that the current solution _doesn't_ provide
all those things. So we might as well swallow hard and admit _that_ publicly
too.
Whether all the above is politically feasible in the current IETF - who knows?
If not, it's back to 'The Emperor's New Protocol' for another year or so, I
guess, by which time the environment may be a bit more receptive.
Noel
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf