Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures

[Tony Li <tli@cisco.com>]

Noel,

> > A mapping cache is a fine and tractable object IF AND ONLY IF the
> > working set at that location is tractable.
>
> Definitely a key architectual observation, although I'd rephrase it  
> more
> explicitly (although this is no doubt what you meant with your  
> abbreviated
> version) as:
>
>  "A mapping cache is a fine and tractable object IF AND ONLY IF the  
> working
>   set at that location is enough smaller than the full map that the  
> savings
>   are significantly larger than the overhead (complexity, etc) of  
> having a
>   cache."


I disagree here, a bit.  It's possible to make the full map tractable  
and in that case, the cache is still tractable.  It would provide no  
savings over the full map at that point.  There are other  
architectural drivers that might still make it the preferred approach.


> So there are two questions. The first is 'is this the case here'?


It is in some cases.   Certainly in the SOHO kind of setting, the  
working set is likely to be trivially small.  However, (and Dino is  
the one who pointed this out) there are a number of large content  
providers that have content that has extremely broad distribution,  
are exceedingly latency sensitive, and thus would have a working set  
that's effectively the full map.


> The second
> is, 'if not, is it practical to keep the full map'? Because if the  
> answers
> are 'no' and 'no', it's back to the drawing board....


That very much goes to the granularity of the map.  If you go to a  
per-host map, then I have some concerns.  It would make things very  
expensive.  However, the number of places that would have this level  
of expense is very, very small.  Architecturally, it might still fly.



> So what about the first question? I think for a lot of ITR's (and  
> maybe
> almost all), this could be true. (Although this is just a guess,  
> and could be
> way wrong. For instance, spam and port-scanning seem to be from  
> everywhere,
> to everywhere, and that will blow the caches. Although since those  
> are all
> incoming traffic, if we design the system so that incoming requests  
> carry, as
> an optimization, the reverse mapping, we'd be OK, in terms of load  
> on the
> resolution system.)
>
> Anyway, for 'normal' users, for smaller sites, even when you  
> integrate across
> a number of users, they are communicating with only a fraction of the
> endpoints in the Internet anyway.
>
> For another (and I think this is a more important factor), as the  
> Internet
> grows and the Web has a lot more content in other languages, you'll  
> see a
> natural splitting up of the user population into communities of  
> interest;
> English-speakers aren't going to be looking at a lot of sites in  
> Mandarin,
> etc, etc.
>
> One thing that could throw a monkey wrench into this is if we see a  
> lot of
> cross-group hosting; i.e. web servers which contain content in many
> languages, so that even if the user communities are disjoint, they  
> may be
> interacting with a single shared substrate of servers.
>
> So except for the Googles of the world, maybe caching will work?


Yes, I have to agree.  In fact, if you can make the system carry the  
reverse mappings (do they need to be secured?) you might even make  
the Googles work.


> The obvious counter-point is going to be 'well, why doesn't caching  
> work in
> the routers, then'? I think that's because (especially in core  
> routers) the
> traffic aggregation as you go up the transmission hierarchy (think  
> of it as
> the same as going from surface roads up to high-speed limited-access
> highways) naturally brings up a bigger set of sources and  
> destinations. E.g.
> in the US there's a lot of 'through' traffic (q.v. all the razz-ma- 
> tazz in
> the US about eavesdropping on transit traffic from a non-US-source  
> to a
> non-US-destination).


That's correct.  At the edge of the network, the working set will be  
far smaller because you have a much smaller cross section of sources  
and destinations.  In the transit case, you'll simply die.

Note that we also saw this with netflow.  ;-) ;-(


> > a) I'm in favor of caches in some places and b) I'm against them in
> > others.
>
> More detail? Remember, there are no 'core ITR's'...



Again, it's all about the working set.  Normal enterprises should be  
cacheable.  Google's might not be.  Comcasts would be cacheable, but  
you have to put the cache in the PE box, not the CE because the end  
user can't manage it.

> > No, what I saw was a total mess of mechanisms, with no coherency.
>
> Is coherency in the eye of the beholder? Systems with radically  
> different
> operating points are going to look radically different.
>
> As long as each operates well, they don't interfere with one  
> another, and
> there is a good algorithm/whatever for deciding which one to use in  
> a given
> situation, is it a problem if they are very dissimilar?


Something that looks like three different systems still looks like  
three different systems.  What we're talking here is a smooth  
continuum of solutions with a common infrastructure.  There was no  
dial that you could set for "light", "normal", and "heavy duty".

Tony


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg