Subject: Re: Dependency on mapping [Re: [RRG] Tunnel fragmentation/reassembly for RRG ...

From: [email-masked]
Date: Fri, 18 Jan 2008 05:54:29 EST

In einer eMail vom 18.01.2008 10:54:33 Westeuropäische Normalzeit schreibt  
[email-masked]:

If we are going to introduce a big change in  the Internet  Architecture (and 
Loc/ID split -is- a big change) to think that todays  protocol will work with 
the same degree of efficiency is kind of  utopia. 

Once loc/ID is introduced, probably something like a future TCP-Vegas++  or 
TCP-New-New-New-Reno will fix the inefficiencies.

In other words, we should aim not at preserving top performances, but to  not 
"degrade them too much".

Luigi Iannone

Given these additional concerns about loc-id-split, what is wrong with  my 
NIRA architecture, which would, as repeatedly said  and proven, reduce the 
routing tables down to 2-3 K, eliminate the  so-called update churn, and (!) speed 
up the IP forwarding by factor 20 
 
(while providing a new and better basis for QoS/policy routing, traffic  
balancing,network maintenance,and overcoming the orthogonality between intra-  and 
inter-domain routing)  ?
 
Heiner

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 18 Jan 2008 12:01:06 +0100

Hi Heiner,
Le 18-janv.-08 à 11:54, [email-masked] a écrit :

> In einer eMail vom 18.01.2008 10:54:33 Westeuropäische Normalzeit  
> schreibt [email-masked]:
> If we are going to introduce a big change in  the Internet  
> Architecture (and Loc/ID split -is- a big change) to think that  
> todays protocol will work with the same degree of efficiency is  
> kind of utopia.
>
> Once loc/ID is introduced, probably something like a future TCP- 
> Vegas++ or TCP-New-New-New-Reno will fix the inefficiencies.
>
> In other words, we should aim not at preserving top performances,  
> but to not "degrade them too much".
>
> Luigi Iannone
> Given these additional concerns about loc-id-split, what is wrong  
> with my NIRA architecture, which would, as repeatedly said and  
> proven, reduce the routing tables down to 2-3 K, eliminate the so- 
> called update churn, and (!) speed up the IP forwarding by factor 20
>

I get the point of how NIRA would  reduce the routing tables, but
how NIRA can speed up IP forwarding on routers' line cards by a  
factor of 20?

> (while providing a new and better basis for QoS/policy routing,  
> traffic balancing,network maintenance,and overcoming the  
> orthogonality between intra- and inter-domain routing)  ?
>
> Heiner
>

Luigi Iannone

[email-masked]

---

From: [email-masked]
Date: Fri, 18 Jan 2008 08:18:25 EST

In einer eMail vom 18.01.2008 12:02:23 Westeuropäische Normalzeit schreibt  
[email-masked]:

I get the point of how NIRA would  reduce the routing tables,  but 
how NIRA can speed up IP forwarding on routers' line cards by a factor of  20?

due to just one matrix element look up instead of 20 compares
Heiner

---

From: Tony Li <[email-masked]>
Date: Fri, 18 Jan 2008 10:05:39 -0800

On Jan 18, 2008, at 5:18 AM, [email-masked] wrote:

>  get the point of how NIRA would  reduce the routing tables, but

Ok, it reduces the cost of a lookup, but that doesn't imply that you  
can forward 20x faster.  There's still a ton of other overhead.

Tony