Re: [rrg] Next topic?

[Sampo Syreeni <[e-mail]>]

On 2011-05-09, Noel Chiappa wrote:

> In prior conversations with you, you have suggested that the broad 
> architectural approach I prefer for path selection - i.e. topology 
> distribution, with unified path computation [...]

I'm sensing NIMROD, here. It'd be nice to see it rehashed why precisely 
OSPF-like full topology distribution and/or a purely source routing 
framework could or couldn't be done within a wider, multilevel context. 
Also the relative pros and cons of going that way, or not. A couple of 
decades or so more experience certainly couldn't hurt.

I also wonder whether there is some unifying factor under the 
Interplanetary Internet work, the recent, more practical routing work 
on-list wrt IRON/LISP/whatnot, and the long (thin or thick) network 
stuff. All three pictures rely heavily on information stored at the edge 
of the network, which will or should influence routing decisions. 
Evidently the data should stay at the edge, if at all possible, but all 
that caching, prediction and compression seems somehow unifiable to me.

Is there some overa(r)ching principle lying around here, perhaps having 
to do with (nondeterministic?) source routing, unconventional prediction 
by the source, and (soft state?) edge to core (? to edge? one-way?) 
signaling? With the grand aim of countering otherwise-expected latency 
and other routing-relevant problems, in an e2e-compatible way?

As a much more well-defined problem, a recent I-D-in-queue points out 
many problems in how IPv6's flow label is defined and constrained. One 
of the main solutions to the hassle that it proposes is to hide any 
manipulations of the semantics to within some fixed realm and/or AS 
and/or something, so that the manipulations aren't visible from the 
outside. Much of the LISP/IRON/MPLS/whatnot work tries to achieve the 
precise same thing -- transparent routing from the viewpoint of the edge 
device, while the core is doing something else entirely. So do we even 
now have a good description of what the edge device should see, once and 
for all? If not, nailing that down to pure logic would seem like a 
worthwhile exercise, and a rather well-defined one at that. As such it 
would be an academically motivated one, but in practice it might help in 
unexpected ways wrt the protocols we actually use, right now, including 
but not limited to IP and ICMP in their two main versions.

Van Jacobson et al's content centric networking, of course. Especially 
if we could somehow make it lighter-weight than it is now. (The inherent 
copying aspect is just as relevant or irrelevant as it was with TCP, I 
think, from the purely technical viewpoint. I'm also pretty sure there 
are efficient ways to compress those long URI-style addresses downto 
something routable in even current silicon. If not e2e, then at least 
MPLS-style hop-to-hop FEC-like. I'm thinking about some derivation of 
0-complete trees or something to that effect. But that's still research 
stuff, not real, clear-cut engineering, the precise way HIP used to be.)

An evaluation of any and all ways to aggregate and/or cheaply refine 
existing congestion pricing work done by the IETF at the core routing 
level would be neat as well. I.e. how might the ConEx work interface 
with the core routing fabric. Again, there might be a multitude of 
fundamental interface questions lurking around here, well-suited for 
IRTF and not so much for IETF.

Even a facts-based unification of fundamental internet protocol 
compressions is very much lacking. It probably could be done at least to 
a degree, and it would be very useful especially with IPv6, with its fat 
headers and the current deeply nested protocol stack. But nobody's ever 
tried to tackle the problem in full, at a fundamental level, at least to 
my knowledge.

These are all newbie ideas, but perhaps one or two of them could also 
break the silence Noel mentioned.
-- 
Sampo Syreeni, aka decoy - [e-mail], http://decoy.iki.fi/front
[phone], 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2