re: contra-indications, too many cooks in the kitchen, queuing vs bandwidth
Jay, where have you been hiding? Great post, and I welcome you and your expertise in this matter to the thread. Re: queuing:
I recently listened to a discussion between a ballistics specialist (bandwidth hawk) and a systems maven (bandwidth accountant) which I now wish I had taped. The gist of this give and take was this:
The hawk maintained that the imminent abundance of bandwidth will eventually obviate much of the work that has been done in queuing theory, in many extant and future WAN-related spaces, where queuing had previously been seen as making a primary contribution to the remedy of irregularities associated with congestion, latency, jitter, and, in effect, the overall throughput problem.
The accountant countered that the turnpike and corridor effects would see to it that that would never happen.
[A note to lurkers: Turnpike and Corridor will be discussed in another post. Would someone indulge us here? Ray? Wake up. It's time to go to work.]
---------
Of course, they both made valid points and the eventual outcome is still very academic at this point, as perhaps it will always be, but the issue is interesting to contemplate, nonetheless.
While I don't accept the premise that b-w will ease the problem to the degree that the hawk maintained, I do think it's obvious at this point that much of this trend has already come to pass in some solution areas. Here again, the race between increasing bandwidth supplies and the encroachment of traffic creep will be a determining factor, as are factors associated with price-performance, and what a given application is worth to a user. Stated another way: How much a user organization is willing to pay for response time and QoS <cough>!
I still need to learn how to present that term in a graceful manner.
"The REAL money is in the automatic admin of the caching issue ... doubt it?"
I don't doubt the value of caching, of course not. But I see some offsets occurring, where some previous implementations of localized storage and buffering would have been a no brainer five years ago, are no longer solely satisfied by such measures. While the terms 'buffering' and 'caching' connote different functions, and conjure images of boxes placed in different situations on diagrams, in the end they are the same thing, differentiated only by degree, in terms of granularity and implementation.
A case in point is cut-through, wire-speed routing, switching and forwarding, albeit these are transmission considerations, and do not deal with where you spot, or source, content.
"Just look at a mask of a Pentium chip and see how the real estate is invested there."
I liken this analogy to the comparison of LAN and WAN environments. In the LAN, bandwidth is a one time sunk cost, as are those found on a semiconductor's substrate and mask. In the WAN, however, there are recurring charges which are assessed on the basis of pipe size and distance, to name just two, and consequently the availability is constrained. What this has meant in historical terms is that protocols and throughput rates which were attainable on the LAN were not commutable to the WAN.
The chip, like the LAN riser system, usually has adequate "head room" [room above normal flow utilization that allow bursting to even higher speeds without penalties of congestion] designed into it, to facilitate extremely high speeds of operation over a wide range of parameters. On the WAN, in contrast, the same rules do not hold true, although bandwidth gains, facilitated by a movement to dark fiber and wavelength leasing may be offsetting this soon in some areas, and in some limited situations, the WAN, as well.
"We'll see 3-5 years of silly solutions before the real deal kicks in."
No doubt. I think we're already on the cusp of this during this latest stage of 'net development, if not spinging off the board, already. If I can impose on you, kindly review these links, below. They are from another thread, where Rupert and I have been discussing the use of multiple, IMO, additive, fixes by (let's keep it generic) an ASP, and potentially multiple other background web traffic management aids. The links:
Message 11757761
Message 11758723
Message 11760437
Message 11760848
I look forward to the thoughts and assessments of yourself and others on this matter. Thanks.
Regards, Frank Coluccio |
