[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures
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
explicitly (although this is no doubt what you meant with your
"A mapping cache is a fine and tractable object IF AND ONLY IF the
set at that location is enough smaller than the full map that the
are significantly larger than the overhead (complexity, etc) of
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.
is, 'if not, is it practical to keep the full map'? Because if the
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
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
to everywhere, and that will blow the caches. Although since those
incoming traffic, if we design the system so that incoming requests
an optimization, the reverse mapping, we'd be OK, in terms of load
Anyway, for 'normal' users, for smaller sites, even when you
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
grows and the Web has a lot more content in other languages, you'll
natural splitting up of the user population into communities of
English-speakers aren't going to be looking at a lot of sites in
One thing that could throw a monkey wrench into this is if we see a
cross-group hosting; i.e. web servers which contain content in many
languages, so that even if the user communities are disjoint, they
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
the routers, then'? I think that's because (especially in core
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
in the US there's a lot of 'through' traffic (q.v. all the razz-ma-
the US about eavesdropping on transit traffic from a non-US-source
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
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
operating points are going to look radically different.
As long as each operates well, they don't interfere with one
there is a good algorithm/whatever for deciding which one to use in
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".
to unsubscribe send a message to email@example.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