More on The fallacy of bandwidth on demand

[An excellent rebuttal by Bill Johnston from ESnet, although I have not changed my opinion. Although I want to make one point clear - I am a big believer there will be a huge demand for dedicated optical circuits, I just don’t see the need for bandwidth on demand or reservation, or fast optical switching for that matter in order to optimize utilization of bandwidth -- BSA]


Needless to say, I don't agree with your views expressed
below.

There are two uses for the suite of end-two-end (virtual) circuit tools that ESnet, Interenet2, DANTE, and the European NRENs are developing that, among other things, provide schedulable bandwidth (which has a bit different flavor than BOD but this is still what people frequently call it). These tools also provide the network engineers with very powerful traffic engineering capability.

Re: the rate of growth of big science traffic: The rate of growth - without any of the next generation of scientific instruments yet fully operational - is tracking very steady at 10X every 4 yrs. Resulting in an average of 10Gb/s in our core by 2009-10 and 100 Gb/s by 2013-14. This growth has been consistent since 1990. However, this does not account for any “disruptive” use of the network by science that we have not seen in the past, and there are several of these showing up in the next several years. The LHC is the first of the big next gen. experiments, and even in the data system testing phase (which is now winding down as CERN gets ready for first operation later this year) has already saturated both ESnet and Internet2 circuits in the US is necessitating a lot of mixed circuit + "cloud" TE. By 2008-09 the LHC is expected to be generating 20-30 Gb/s steady state traffic (24 hrs/day 9 mo./yr) into ESnet to the data centers and then out to Internet2, NLR, and the RONs to the analysis systems at universities..

There are several important science uses of the virtual
circuit tools capabilities:
1) One (and the reason for the wide flung collaboration
noted above) is to manage bandwidth on long, diverse, international virtual circuits where there are frequently (nay, almost always) bandwidth issues somewhere along the multi-domain path. The circuit tools have already proved important where some level of guaranteed bandwidth is needed end-to-end between institutions in the US and Europe in order to accomplish the target science.

2) There are science applications - which we are quite sure will be showing up in the next year because we are tracking the construction of the instruments and the planned methodology for accomplishing the science - where remote scientists working on experiments with a real-time aspect will definitely require guaranteed bandwidth in order to ensure the success of the experiment. This use is scheduled and frequently of limited time duration, but requires guaranteed bandwidth in order to get instrument output to analysis systems and science feedback back to the instrument on a rigid time schedule. I won't go into details here but there are a number documented case studies that detail these needs. See, e.g., “Science Network Requirements (ppt)” and “Science-Driven Network Requirements for ESnet: Update to the 2002 Office of Science Networking Requirements Workshop Report - February 21, 2006” at http://www.es.net/hypertext/requirements.html.

There are very practical reasons with we do not build larger and larger "clouds" to address these needs: we can't afford it. (To point out the obvious, the R&E networks in the US and Europe are large and complex and expensive to grow - the Internet2-ESnet network is 14,000 miles of fiber organized into six interconnected rings in order to provide even basic coverage of the US. The situation is more complex, though not quite as large a geographic scale, in
Europe.) We have to drop down from L3 in order to use
less expensive network equipment. As soon as you do that
you must have circuit management tools in order to go e2e
as many sites only have IP access to the network. Since this involves a hybrid circuit-IP network, you end up having to manage virtual circuits that stitch together the paths through different sorts of networks and provide ways of steering the large-scale science traffic into the circuits. Given this, providing schedulable, guaranteed bandwidth is just another characteristic of managing the e2e L1-L2-L3 hybrid VCs.

I have watched big science evolve over more than 35 years
and the situation today is very different than in the past. There is no magic in this - the root causes are a combination of 1) the same Moore's law that drives computer chip density is driving the density of the sensing elements in large detectors of almost all descriptions, and
2) very long device refresh times. The technology "refresh" time for large scientific instruments is much, much longer than in the computing world. This is mostly because the time to design and build large science instruments is of order 10-15 years, and the next generation of instruments just now starting to come on-line is the first to make use of modern, high-density chip technology in sensors (and therefore generates vastly more data than older instruments). (This is an "approximation," but my observation indicates it true to first order.) This is why we are about to be flooded with data - and at a rate that I believe, given the R&E network budgets, we will just barely be able to keep ahead of just in terms of provisioning more and more lambdas each year. And keeping up with demand assumes 100G lambdas and associated deployed equipment by 2012-ish for essentially the same cost as 10G today.

End-to-end circuit management (including allocation of bandwidth as a potentially scarce resource) is rapidly becoming a reality in today’s R&E networks and is going to become more important in the next 5 years. Schedulable bandwidth allocation is one of several aspects of the VC management.

Bill