Re: A call for the future. Was: Re: Verio Decides what parts ofthe internet to drop

[Vijay Gill <wrath () cs umbc edu>]

On Wed, 8 Dec 1999, Dean Anderson wrote:

> > ip is a connectionless protocol.  before hitting the reply key, think about
> > that.
>
> I thought about it. It seems to me that a router is not presented with a
> stream of randomly addressed packets. In any time frame, there are going
> to be from 1 to many hundreds of packets between the same set of
> addresses. 

This is a major fallacy.  Many promising local ISPs had experience with
this when they were smaller and more local.  I am sure dkatz will tell you
of his experiences with trying to get caching algorithms to work well with
core network flows.  In short, the core network flows cause so much churn
in cache memory that the working set of the cache tends to be the size of
the entire FIB to get adequate performance.

Caching does NOT work in context of tcp flows at the core level. Period.

> the packets. By contrast, an IP packet traversing an IP network carries
> all the state it needs with it.  However, that doesn't mean that you
> need to start from scratch each time you see the same src/dest pair. 
> Methods which hold some additional state in the router for faster
> processing can be used to speed things up. 


Once again, at the core of promising local ISP's, this does NOT work.

> The full route table could be very large. Much larger than 256Meg or
> even 4Gig. And even moving to disk backed storage (many gigs) most
> likely means that access would still be in tens or hundreds of
> milliseconds, not seconds.  However, any given router doesn't really
> need to use very much of it at any given time. 


Full route table size is not a problem. You can burn a hard disk as you
mentioned to store it.  The issue is getting data in and out of the
processor, i.e. number of pins.  Core flows are not ameneable to caching.
This approach will fail the first time you see a new packet and need to
swap from hard disk.

/vijay