Subject: Re: [rrg] Fwd: RRG Recommendation

From: [email-masked]
Date: Wed, 6 Oct 2010 03:31:25 EDT

The current debate on this thread shows how many people are frustrated by  
the way their opinions had been ignored - including myself: Once I 
accomplished  that Lixia became interested in my TARA-objectives. I wrote up a list 
of 11  objectives and thereafter I have never heard any response again:-( 
Among these  objectives:  
 
----------------------------  
2) Moore's Law:  
Next hop retrieval by 1 resp. 3 (indexed) table  lookups. 
Will increase the speed of the next hop retrieval by factor 20 i.e.  enable 
Moore's law applicability - even in cases where the best next hop is to  be 
replaced by some other (e.g. detouring) next hop: you can simply,  
temporarily, replace the indexed table entry with the alternate next hop  info. 
No caching needed (of course). 
----------------------------- 
Hereby I assumed that the internet consisted of approx. 10,000  DFZ-routers 
only and that a TARA-router should see the closestly zoomed map of  its own 
entire square-degree-geopatch. 
Now Robin told me that there are rather 210,000 DFZ-routers. Hence it  
would be appropriate to have an even closer zoom showing the own entire  
square-minute-geopatch. 
Thanks to Robin I could make a jump of joy:The improved solution is a  
modified TARA-Locator consisting of 3 components: (1) Square-degree#, (2)  
Square-minute#, (3) Square-second#. 
The next hop retrieval can be made by ONE SINGLE table lookup in ALL  CASES 
: 
Is destination's locator.square-degree# not equal to my  own? 
If YES, offset 64800-elements-sized table t1 by  dest.square-degree# 
else : Is destination's locator.square-minute# not equal to my  own? 
If YES, offset 3600-elements-sized table t2 by  dest.square-minute# 
else: Is destination's locator.square-second# not equal to my  own? 
If YES, offset 3600-elements-sized table t3 by  dest.square-second# 
else: I (the current router) am the endpoint of  TARA-forwarding. 
Is there anyone else who cares for enabling that Moore's law becomes  
applicable? 
If YES, share my joy :-) 
Heiner

---

From: Toni Stoev <[email-masked]>
Date: Wed, 6 Oct 2010 14:56:05 +0300

> Is there anyone else who cares for enabling that Moore's law becomes  

I enjoy you and Robin interacting.

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Wed, 6 Oct 2010 07:11:28 -0500

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, October 06, 2010 3:31 AM
To: [email-masked]
Subject: Re: [rrg] Fwd: RRG Recommendation

The current debate on this thread shows how many people are frustrated by the way their opinions had been ignored - including myself: Once I accomplished that Lixia became interested in my TARA-objectives. I wrote up a list of 11 objectives and thereafter I have never heard any response again:-( Among these objectives:
 ----------------------------
2) Moore's Law:
Next hop retrieval by 1 resp. 3 (indexed) table lookups.
Will increase the speed of the next hop retrieval by factor 20 i.e. enable Moore's law applicability - even in cases where the best next hop is to be replaced by some other (e.g. detouring) next hop: you can simply, temporarily, replace the indexed table entry with the alternate next hop info.
No caching needed (of course).
-----------------------------

[[WEG]] I had not seen your previous message with your objectives, so I will beg pardon for ignorance in asking this question - could your objectives be abstracted from TARA's implementation and suggested as possible text for the design goals draft that is currently in review? It may not be a good fit, but it at least bears review if it can be made more general. In other words, it's not helpful if it leads only to TARA as a solution (not making a comment about TARA, simply pointing out that would conflict with the recommendation), but if any of your objectives have general applicability, it may bolster the design goals well. Obviously, this would be more about making the existing goals clearer and more articulate than it would be adding additional goals, so look at it with that in mind.

Thanks
Wes George

This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: [email-masked]
Date: Wed, 06 Oct 2010 10:28:47 -0400

These were the TARA = Topology Aggregating RoutingArchitecture - Objectives. The first two  objectives are updated.
Heiner

1)Scalability:
RIB: No single route is to becollected  (although  millions of additional (detouring) routes–which DV would never yield – will be enabled. Instead of the RIB: approx. 500 TARA-links per zooming level might becollected (which is just a guess). 6 (formerly 5) zooming levels should be envisioned.
 
FIB: No single prefix is to be built.Instead of the FIB three tables are required: Table t1 with 64800 entries;table t2 with 3600 entries and table t3 with 3600 entries.  
 
Update churn: tending to zero. The moredistant  topology changes occur, themore they are but the less become visible. Like in Google-map: Zoom closest andscroll such that the current node is in the middle of the screen.The topologiesthat you (the current node) will see while zooming out is all what you get toknow and get to deal with. This is a tiny fraction of the combined clostestzoom map of the entire globe.
 
2) Moore's Law: 
Next hop retrieval by one single  table lookup 
Will increase the speed of the next hop retrievalby factor 20 i.e. enable Moore's law applicability - even in cases where thebest next hop is to be replaced by some other (e.g. detouring) next hop: youcan simply, temporarily, replace the indexed table entry with the alternatenext hop info.
No caching needed (of course).
 
3) Mobility:
Enables  Mobility  solutionswithout any home agent or rendez-vous server: DNS gives you the current thougheventually not precise destination-TARA-locator. By new ANYWHERE-CAST i.e.well-scoped broadcast mechanism (better than  flooding) the properdestination-TARA-router could be searched.
(also: DNS be updated when a user roams toa different geopatch) 
 
4)Traffic engineering:
Traffic balancing:
Enables all kind of detouring Multipath(not just ECMP, yes, even crankbacks included).  
Enables time-of-day routing.
 
Congestion handling: For all kind ofstreams, in particular voice and live-TV streams whose transmissionrates cannot be slowed down, based on a communication between thecongested and the respective upstream neighbor network.(i.e. with TARA arearview mirror is provided which DV would never ever be able to). Congestionhandling is a network-local-area issue and not something to involve the sendingTCP entity!
 
Abolishes loops:
Disables endless (!) loops (butallows/enables crankback).  Makes theTTL-mechanism obsolet wrt its current task but would utilize it for doing  safe detours.
 
Will enable stretch-1 routing and avoidthe Istanbul-effect.
 
5)Multihoming:
Enables Multihoming 
a)       just like all the other proposed solutions 
b)       long-term: Because of its fantastic achievements wrt scalability wecould even envision a network where even the users (hosts) became nodes of theTARA-topology, which would have a certain impact on the multihoming issue.
 
6) Clean slate:
Will overcome the orthogonalitybetween intra- and inter-domain routing.
Will overcome the either-or thinkingbetween network-based CES versus user-based CEE
 
7) Enables Multi-addressing (IPv4, IPv6just like LISP, eventually more: HIT, names, E164 without enum ?! )  because the transit router uses theTARA-locator, i.e. doesn't look at the other address;
 
8) Eliminates the IPv4 depletion issue,because of 7): IPv4 must be locally unique only. 
   PI or PA? All are PI effectively.
 
9) Provides a strategy for incrementaldeployment
10) Multicast to millions of receivers(imagine TVoIP of the opening olympique celebration to hundredmillions of receivers - admitted, TARA would be the basis, a better thantoday's MC is needed (and could be developed), too.
 
 11) Provides a new realm for workingon IP technology in the future.

-----Ursprüngliche Mitteilung----- 
Von: George, Wes E IV [NTK] <[email-masked]>
An: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Verschickt: Mi., 6. Okt. 2010, 14:11
Thema: RE: [rrg] Fwd: RRG Recommendation

From: [email-masked] [mailto:[email-masked]] On Behalf Of 
[email-masked]
Sent: Wednesday, October 06, 2010 3:31 AM
To: [email-masked]
Subject: Re: [rrg] Fwd: RRG Recommendation

The current debate on this thread shows how many people are frustrated by the 
way their opinions had been ignored - including myself: Once I accomplished that 
Lixia became interested in my TARA-objectives. I wrote up a list of 11 
objectives and thereafter I have never heard any response again:-( Among these 
objectives:
 ----------------------------
2) Moore's Law:
Next hop retrieval by 1 resp. 3 (indexed) table lookups.
Will increase the speed of the next hop retrieval by factor 20 i.e. enable 
Moore's law applicability - even in cases where the best next hop is to be 
replaced by some other (e.g. detouring) next hop: you can simply, temporarily, 
replace the indexed table entry with the alternate next hop info.
No caching needed (of course).
-----------------------------

[[WEG]] I had not seen your previous message with your objectives, so I will beg 
pardon for ignorance in asking this question - could your objectives be 
abstracted from TARA's implementation and suggested as possible text for the 
design goals draft that is currently in review? It may not be a good fit, but it 
at least bears review if it can be made more general. In other words, it's not 
helpful if it leads only to TARA as a solution (not making a comment about TARA, 
simply pointing out that would conflict with the recommendation), but if any of 
your objectives have general applicability, it may bolster the design goals 
well. Obviously, this would be more about making the existing goals clearer and 
more articulate than it would be adding additional goals, so look at it with 
that in mind.

Thanks
Wes George

This e-mail may contain Sprint Nextel proprietary information intended for the 
sole use of the recipient(s). Any use by others is prohibited. If you are not 
the intended recipient, please contact the sender and delete all copies of the 
message.

---

From: [email-masked]
Date: Wed, 06 Oct 2010 11:09:31 -0400

Thank you, Toni
There are a few nice aspects which come along:
1) ALWAYS just one single table lookup for retrieving the next-hop info (obviously no one can do it by less)
2) A fix size for all 3 tables
3) Having one or two more zooming levels would match a tighter meshing, and also,  where this is not the case, we may apply  scale ratio = 1:1 
   so that no skimming occurs where inapproriate.

Heiner

-----Ursprüngliche Mitteilung----- 
Von: Toni Stoev <[email-masked]>
An: [email-masked]
Verschickt: Mi., 6. Okt. 2010, 13:56
Thema: Re: [rrg] Fwd: RRG Recommendation

I enjoy you and Robin interacting.
_______________________________________________
rrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: "Dmitri Krioukov" <[email-masked]>
Date: Fri, 22 Oct 2010 11:49:10 -0700

folks, the lack of consensus is quite expected.
putting many low-level details aside, the deep
reason for that is the following, i think.

it occurred to me in some off-line discussions here,
that folks are still looking for scalable routing
which would work for any possible network topology.
as mentioned way back in
http://dx.doi.org/10.1145/1273445.1273450
scalable routing for arbitrary networks cannot
exist. in fact, it's intuitively easy to see,
but it's also a proven fact, like a theorem.
therefore the task of building a scalable routing
solution for *arbitrary* networks cannot succeed
in principle. the only option is to look for
solutions which would work only for *specific*
networks, e.g., the global internet :) such solutions
may be efficient and scalable if they find a way
to intelligently utilize network peculiarities.

best,
--
dima.
http://www.caida.org/~dima/

---

From: Toni Stoev <[email-masked]>
Date: Fri, 22 Oct 2010 22:11:43 +0300

2010.10.22 пет 21:49:10 Dmitri Krioukov:
> networks, e.g., the global internet :)

... establish inter-domain path selection as the solution for global internet routing.

> such solutions

---

From: Sampo Syreeni <[email-masked]>
Date: Fri, 22 Oct 2010 22:42:47 +0300 (EEST)

On 2010-10-22, Dmitri Krioukov wrote:

> the lack of consensus is quite expected.

Of course. A research group charts/hashes out possibilities and then in 
the end tries to focus real-life protocol development along the 
seemingly most productive avenues based on that. IRTF exists separately 
from IETF because somebody does need to intelligently speculate at the 
grand scale and using pure results from the academia as well. That sort 
of exercise isn't concensus bound, unlike the engineering side done 
within the IETF. Hence the division.

> it occurred to me in some off-line discussions here, that folks are 
> still looking for scalable routing which would work for any possible 
> network topology.

AFAICS, we're now working two separate topologies: the 
logical/identifier one, and the more well-known topological one. In 
isolation from one another, and needing some means of efficient and 
transparent mediation/mapping between them.

> [...] scalable routing for arbitrary networks cannot exist. in fact, 
> it's intuitively easy to see, but it's also a proven fact, like a 
> theorem.

It is. But even the charter of the RG has already moved past that 
dilemma: now we're considering architectures where there isn't just a 
single common routing architecture, but at least two (end point 
identifier vs. topological location) which are dynamically mapped via 
some way. We're not trying to do what you think we should do. We're 
doing something else entirely, using some sort of mapping between two 
namespaces, on the fly. The real debate is now about where to do the 
mapping, how to map it into the existing IP infrastructure, how best to 
do the mapping in a router and the interoperability and especially about 
how to distribute the map itself efficiently enough to make this whole 
thing transparent.

> the only option is to look for solutions which would work only for 
> *specific* networks, e.g., the global internet

That is not true. If you claim that, you will have to prove it beginning 
with first principles. And I think it's already quite clear you cannot 
do it using the basic axioms of the Internet, so to speak. ;)

But you are still quite right in that a) if we have a reason to believe 
the global Internet has some invariants, with strong theoretical reasons 
why we should not expect them to change, then b) we absolutely should 
find ways of exploiting them for routing efficiency, and whatnot.

If you can find such invariants in topology and can also tell us why 
they would hold over time, then you should definitely suggest a 
rechartering of the research group. Right now the RG is busy and also 
formally tasked with much simpler things. Why don't you help with the 
simpler thing first, while submitting a recharter request in parallel, 
so that we have something new to study as soon as possible after the 
current exercise?

> such solutions may be efficient and scalable if they find a way to 
> intelligently utilize network peculiarities.

Agreed. At least MANET's and the like have done this sort of thing for 
awile, and we even have IETF WG's working on this stuff. But that's no 
good reason to detract our attention from the current architectural 
problem, which is still unsolved and not ready to be fed to IETF's 
protocol designers.

Just as a hint, I've followed IETF and then IRTF work from afar since my 
early teen years. Many other standardization organizations as well, like 
W3C, IEEE, ISO and the like. What always impressed me in the IETF work 
(and IRTF by extension) was how goal-oriented, factual, free, and to the 
point it was. You too, just let it fly to its conclusion, and then 
suggest something new. In the meanwhile, contribute actively so that we 
might have something new to research/study over the next cycle. Help put 
the current topic to rest.
-- 
Sampo Syreeni, aka decoy - [email-masked], http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2