On Mar 16, 2010, at 1:25 AM, [email protected] wrote:
In einer eMail vom 16.03.2010 08:34:27 Westeuropäische Normalzeit
schreibt [email protected]:
On Mar 15, 2010, at 4:30 AM, [email protected] wrote:
In einer eMail vom 15.03.2010 08:00:10 Westeuropäische Normalzeit
schreibt [email protected]:
Heiner,
1/ I am not quite clear why collecting topological links is the #1
question for RRG/routing scalability solution development
2/ my group has been collecting Internet AS level topology for the
last 5 years.
the following one is the most recent paper:
The (in)Completeness of the Observed Internet AS-level Structure
IEEE/ACM Transactions on Networking, Feb 2010.
although the paper just got published, some of the numbers may have
already changed in reality. However one fact should remain true: by
putting BGP data from all the sources we can get our hand on, the
collected results still miss majority of the peering links between
ASes.
Lixia,
Thanks for the above document reference. My guess: You collect this
AS-level topological network information just for academic
interest. i.e. for doing some interesting studies. That's all.
we do not do studies just for academic interest.
The goal of the above is to explain what one can or cannot observe
about the AS connectivity.
I should have said "for doing off-line purposes". I have expressed
the "on-line" objectives many times, some of them see below, which I
think go beyond keeping the internet running just as well as is
currently still the case.
Not sure I understand the definition of "off-line purposes"; RIPE and
Routeviews get data from running routers.
This is not at all my point. My question is: What would be
achievable in terms of better routing, if the same kind of
topological information were available in inter-domain routing as
is the case in intra-domain routing !
I understand, and my point (based on the data) is that inter-domain
topological info is largely *not* available, and for a reason.
Nor would my TARA-model insist on being fed with all topology info,
even more: its goal is to skim the available topology information.
See below from my previous email, I didn't mention the two
additional side effects: 1) no single prefix and 2) no single route
to be disseminated/collected anymore.
looks like I just got lost further :(
And there is indeed a very long list of achievabilities including:
- Mobility without home-agent/care-of-address server by well-scoped
broadcast search messages
Any comments to this mobility objective?
a nice objective.
- Congestion handling by detouring and not, a la re-ECN, by
slowing down (video :-( ???) transmission
- Enabling any detours (incl. crankback using ones) and getting rid
of the loop phantom fear
Any comments to this TE objective?
not necessarily disagreement, though the above did not specifically
mention multipath approach (e.g. the multipath TCP effort), that can
be effective means towards those objectives
- 99 % state-less Multicast
Any comments here?
I do not understand fully here.
does it refer to IP multicast?
(there are lots host mcast solutions that dont introduce state to
routers; one may also view CDNs as asynchronous multicast delivery)
- speeding up next hop determination by 20 x 100 = 2000 %
-......etc..etc...
Comments?
Please let me just ask one question: any thought on how to achieve
those objectives? in particular how to get from here to there without
a total restart?
By insisting on DV this group prevents all major progress,
including that progress none of us is currently able to think of.
Remember the IBM commercial! Rather asking the transport goods for
where we are, we should provide a networking layer technology for
the benefit of services above.
if I could change couple words in the very last statement above: we
need to provide a networking layer technology that *best fit* the
services above.
Note that, in the long run, networking layer not necessarily = IP
layer; see the recent paper by Van Jacobson etc "networking named
content" (http://www.parc.com/publication/2318/networking-named-content.html
). I'm currently working with Van along this direction.
Lixia
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
