On 2010-09-13, Tony Li wrote:
Might I suggest that a discussion of transit policies might also be in order?
The way I see geometric routing is that it is fundamentally different from the normal kind, because it's not about discrete topology, but a continuous geometry. It doesn't much matter which way you throw a packet, as long as it travels somewhat towards the right target. This, I believe, is what is also mostly behind the stability results presented above. So as long as you respect the fact that the geometric distance towards the target is diminishing with each routing hop (perhaps with minor, guaranteed to be bounded deviations e.g. for dead hops) you can be reasonably sure, especially within scale-free networks that the paper relies on, that the packet will arrive at the correct destination.
In that case it should be possible to do policy routing as well. As a first approximation it would be purely at the local, per-router level. Whatever metric you were using, you could use it like you would use a heuristic distance in an A* search, and forward based on policy as long as you didn't violate the heuristic. The proof of why A* goes through could be used to show why the packet will eventually be forwarded, using similar assumptions. I'm far from sure what else could be done with some further refinement, but that seems like a reasonable and well-documented starting point.
The more basic problem remains that asymmetry breaks every proof of this kind I've seen. Topology propagation is at least a theoretical problem, evenas the paper does present concrete empirical evidence that a static geometric routing paradigm could perhaps be surprisingly stable. There is also no substantive analysis of when drift in the routing geometry (here we cannot talk about topology alone) might necessitate the equivalent of renumbering the network, and how to maintain those stable reference points I already mentioned. As you already hinted at, policy routing based on AS's down the path do not seem too easy to incorporate. And then there is also the overall question of what the distance metric should be in the first place, especially keeping in mind that we might have IntServ/DiffServ objectives in mind as well, with multiple simultaneous traffic engineering constraints, and their mutual interactions. After all, here we're working with a very real distance measure just like in distance vector protocols, and that was given up for paths for a reason in BGP. (OTOH, the paper might also allow highly compressed and computationally efficient representations of multiple distance metrics at the same time, with little temporal instability. If so, that's again interesting.)
-- Sampo Syreeni, aka decoy - [email protected], http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2 _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
