: I note that he doesn't actually describe how to implement
: a large-scale addressing and routing architecture. It's all
: handwaving.
There is more discussed in the book. The paper was written by another person and had to only hit the highlights, or it'd be too long for folks to want to read. I'd imagine you can get a copy of the book in a university library.
:And he seems to think that core routers can cope with per-flow state.
Can you elaborate for me?
: The only bits he's at all concrete about are the transport
: protocol, which isn't really where the unsolved problems are.
It wasn't about just solving problems. It seems to me to be about if you could clean-slate design, what would you do? AFAICT the RRG folks are specifically focused on fixing problems: map-n-encap and tunneling being the most liked solutions.
One similar thing to other proposals on that list, though, that has me wondering is the use of a 'server' in the middle to keep track of everything.
scott
From: Tony Finch <dot@dotat.at>
: I note that he doesn't actually describe how to implement
: a large-scale addressing and routing architecture. It's all
: handwaving.
There is more discussed in the book.
I have bought and read the book. It's an interesting and entertaining rant
about the protocol wars, but still far too vague about proposing solutions
for our current pain points. Argiung about TCP vs. Delta-T is a very long
way from the problems that need solving.
My comment stands.
:And he seems to think that core routers can cope with per-flow state.
Can you elaborate for me?
Perhaps I don't understand how connection-oriented networks work. How do
you reserve bandwidth for a connection with guaranteed quality of service
without establishing state on every router in the path? How do you do it
in a network that spans multiple organizations? What connection-oriented
inter-domain protocols have had widespread deployment?
It wasn't about just solving problems. It seems to me to be about if
you could clean-slate design, what would you do?
If your lovely clean architecture can't solve problems why should anyone
pay attention to it? A clean slate architecture needs to synthesize what
we have learned from practical experience and add a dose of cleverness so
that problems can be solved much more easily.
A simple mostly-unrelated example: in the 1980s hypertext systems had
links that were bidirectional and they made an effort to keep them
consistently maintained. This made it impossible to have an inter-domain
hypertext system. The WWW discarded the requirement for consistent
bidirectional links, so it was not "proper hypertext". Even so, because it
does not require co-operation between the ends of the link, it rapidly
outgrew any previous hypertext system.
The point of a clean slate design is to rethink the foundations of your
architecture, and get rid of constraints that set you up to fail.
Tony.