[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




Yakov,

You can also go in the opposite direction and go to non-commodity
memories, but then you go off of the commodity cost curves. Once you
do that, it's hard to continue to sustain our growth rate at constant
cost, and that's simply another way of failing to scale.

What is a non-commodity memory today need not be non-commodity
memory tomorrow.


True, but it's been a VERY long time since the basic architecture for commodity memory has changed in a significant way that changed random access speeds. The last big change that I can think of was the original introduction of DRAM, back in the (yes, I'm dating myself) late 70's and early 80's. Original microprocessors were normally mated with SRAM, and DRAM was a new and welcome innovation, even though refresh was an annoyance. Since then, we've seen page mode, burst mode, and DDR. Some of those have helped, but many of them don't apply directly to the tree-structures that we normally need to manipulate.

In short, I don't think that we should really count on the commodity market to change its memory architectures anytime soon. We are certainly not enough of a market to have any kind of impact, and there's nothing in my crystal ball about any other drivers in the PC marketplace either. Thus, we should reasonably expect to stay on the current technology curves.


Moreover, what really matters is not whether "you go off of the
commodity cost curves", but how far are you off.


To a point. How far off you are only determines when costs become unsustainable. As soon as the cost curve to support the growth rate exceeds constant cost and there's no way to bring that curve back under control, you're
inevitably going to diverge.


Finally, while the argument about "constant cost" focuses on CAPEX,
let's not forget OPEX. The cost of operating the new system could
completely overshadow all the OPEX considerations.


A fine point. A revised routing architecture that is so expensive to maintain that it also cannot be deployed is not helpful. For example, a proposal that required manual propagation of mapping updates would instantly fail this test.

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