Subject: Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of

From: [email-masked]
Date: Tue, 16 Mar 2010 04:25:25 EDT

In einer eMail vom 16.03.2010 08:34:27 Westeuropäische Normalzeit schreibt  
[email-masked]:

On Mar 15, 2010, at 4:30 AM, [email-masked] 
(mailto:[email-masked])  wrote:

In einer eMail vom 15.03.2010 08:00:10 Westeuropäische Normalzeit  schreibt 
[email-masked] (mailto:[email-masked]) :

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_ 
(http://www.cs.arizona.edu/~bzhang/paper/10-ToN-completness.pdf) 
 
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.

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.

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?

- 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?

- 99 %  state-less Multicast

Any comments here?

- speeding up  next hop determination by 20 x 100 = 2000 % 
-......etc..etc...

Comments?

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.

Heiner

_______________________________________________
rrg  mailing  list
[email-masked]
http://www.irtf.org/mailman/listinfo/rrg

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 16 Mar 2010 23:53:09 -0700

On Mar 16, 2010, at 1:25 AM, [email-masked] wrote:

> In einer eMail vom 16.03.2010 08:34:27 Westeuropäische Normalzeit  
> schreibt [email-masked]:
> On Mar 15, 2010, at 4:30 AM, [email-masked] wrote:
>
>> In einer eMail vom 15.03.2010 08:00:10 Westeuropäische Normalzeit  
>> schreibt [email-masked]:
>> Heiner,
>>
>> 2/ my group has been collecting Internet AS level topology for the  
>> last 5 years.
>> The (in)Completeness of the Observed Internet AS-level Structure
>> 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,
>> AS-level topological network information just for academic  
>> interest. i.e. for doing some interesting studies. That's all.
>
> 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 !
>
> 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 :(

> 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
>

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

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 %

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

---

From: Scott Brim <[email-masked]>
Date: Wed, 17 Mar 2010 07:49:48 -0400

Excerpts from Lixia Zhang at 23:53:09 -0700 on Tue 16 Mar 2010:
> 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.

But the problems are all the same regardless of what you use to name
the endpoints.

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 17 Mar 2010 08:13:57 -0700

On Mar 17, 2010, at 4:49 AM, Scott Brim wrote:

>> layer; see the recent

Scott's questions are always right to the point!
As the paper title suggested: this new direction moved away from  
naming endpoints.
(in the paper this effort was named CCN, now it has been changed to  
NDN, Named Data Networking, just to make this most important point as  
clear as possible)

Lixia