Interesting thread that has fallen off the GHPN reflector for no good reason. -franco ---------- Forwarded message ---------- From: Admela Jukan <jukan@uiuc.edu> Date: Mar 31, 2005 7:12 PM Subject: Re: Admela Jukan's presentation To: "<bill.st.arnaud@canarie.ca>" <bill.st.arnaud@canarie.ca> Cc: ebslee@ntu.edu.sg, chyoun@icu.ac.kr, travos@ieee.org, Leon Gommans <lgommans@science.uva.nl>, Gigi Karmous-Edwards <gkarmous@mcnc.org>, imonga@nortel.com, Cees de Laat <delaat@science.uva.nl>, "Masum Z. Hasan" <masum@cisco.com> Thanks a lot Bill for your feedback. My specific responses are given below in detail. I look forward to further discussions - Admela On Mar 31, 2005, at 2:13 PM, Bill St.Arnaud wrote:
I enjoyed Admela's presentation on control plane issues. I think it is a good summary of most of the issues. However I would suggest there are some areas that may be worth further exploring:
(a) in addition to applications needing to interact with the network physical layer for large data flows, there are some situations where it would be advantageous to bring the network into the application. This is a lot different than the network being "aware" of the application. There is a lot of work going on in the HPC community to "decompose" large data applications into smaller modules which then can be relocated anywhere on the network. However in some cases the application modules may still be on the same physical machine interconnected by a "virtual" network or pipeline. Extending HPC pipeline architectures into network pipes would be clearly advantageous.
I agree with you. Not sure however what would be the best way to incorporate that view into the three dimensional diagram I gave in the presentation, without explaining virtualization, soft switches,...etc. (I wish you can be there next time and talk about the extension of networks into applications, or point us to some good docs.) In the three dimensional space between apps, Grid resources and networks, the applications can nevertheless pick up networks, or part of networks and fully incorporate (link or pipe) them - to be their own very part in the whole distributed application. I think this in line with your thinking. It is in my opinion a great research area. Hence, I do agree with you that networks, as much as they will extend into the physical layer, will also extend into the applications.
(b) I remain skeptical about reservation and scheduling of bandwidth or lightpaths. The cost of wavelengths continues to plummet – and it is now cheaper to nail up the bandwidth and leave it there sitting idle, rather than paying the high OPEX costs for scheduling, reservation, billing etc. For example I have been informed by reliable sources that the annual cost of a 10 Gbps wavelength on the new Geant network will be in the order of 20K Euros. You couldn't hire a graduate student for that price to do the scheduling and reservation. The counter argument is that there will be applications where data transfers are infrequent, and buying nailed up wavelengths, even at 20k Euros, can't be justified – in that case I say use a general purpose routed network. Given that the data transfers are so infrequent, I suspect the slightly longer delays of using the routed network can be tolerated. But I suspect most large data flow applications will be from well known and often used sources and sinks – so the need for scheduling and reservation will be very limited
I share your concerns given the recent trends, price of bandwidth etc. However, there maybe at least two good reasons why scheduling may be an issue we do not want to completely neglect, at least not for a while. First: network local grid scheduler, just like other Grid resources' schedulers, is represented in the corresponding hierarchical architecture within the scheduling working group in GGF (https://forge.gridforum.org/projects/gsa-rg). They look forward to our input to that issue. If we, as "networkers", can provide Grid network services for "no waiting time" (i.e. no scheduling) - that is a wonderful message to the scheduling group that no longer has to worry about that. *** Soapbox: Given that network resource management is far from the "on the fly" provision, at least not at a grander scale and not for complex application composition, I am not sure if the community is ready to make the statement. For example, one part of a complex dynamic application has to wait that the related other part of the same applications finishes. So, do you schedule the "second part" after the first part is done, and how (1)? Or, do you just set up continuous communication patterns for the whole duration of application (2)? Or, you integrate dynamic control plane processes into the application ("extend") and dynamically allocate network resources as the applications evolve (3)? I understand that if bandwidth is cheap we can waste it and do the (2). On the other hand, you suggest to "extend" into application (corresponds to (3), since the SW processes pipe to each other.) - this is more elegant but does not per se exclude the need for (advance) scheduling. Etc. Your input is a very valuable starting point to this line of discussions. *** Second, - I admit less intriguing, - network is still a shared resource. While I agree with you that network resources have to be provided with no waiting time to applications, bandwidth may not be the only requirement - it may be "guaranteed performance" . So, your comment is also here a good start of the discussion whether we have "cheap guaranteed performance" yet to be provided "with no waiting time". And, if so, how do we deal with the scale (number of bandwidth pipes, scale in implementation of network control plane software, etc,...) As a researcher, I could also imagine that scheduling can be interesting in some specific situations (recovery, failure, etc) or when the network topologies make it difficult to design reliable connections (connectivity, and min cut problem). However, I do agree that the prices can diminish the practical importance of all these possible scenarios.
Bill
-----Original Message----- From: owner-ghpn-wg@ggf.org [mailto:owner-ghpn-wg@ggf.org] On Behalf Of Franco Travostino Sent: Thursday, March 31, 2005 2:44 PM To: ghpn-wg@gridforum.org Cc: chyoun@icu.ac.kr; ebslee@ntu.edu.sg; Masum Z. Hasan; Leon Gommans; imonga@nortel.com; Admela Jukan; Gigi Karmous-Edwards; Cees de Laat Subject: [ghpn-wg] Fwd: Seoul material is on-line
I've been informed that Admela's presentation could not be opened with PowerPoint. It turns out that the handoff between Admela and me has altered the file's content somehow. I have now replaced the file in forge.gridforum.org.
For further reference:
/cygdrive/D/GGF13 (19) sum Admela* 59184 2731 Admela Correct File.ppt 11383 2731 Admela Damaged File.ppt
-franco
Date: Wed, 30 Mar 2005 13:08:06 -0500 To: ghpn-wg@gridforum.org From: Franco Travostino <travos@ieee.org> Subject: Seoul material is on-line Cc: chyoun@icu.ac.kr, ebslee@ntu.edu.sg, "Masum Z. Hasan" <masum@cisco.com>, Leon Gommans <lgommans@science.uva.nl>, "inder [BL60:418:EXCH] Monga" <imonga@AMERICASM06.nt.com>, Admela Jukan <jukan@uiuc.edu>, Gigi Karmous-Edwards <gkarmous@mcnc.org>, Cees de Laat <delaat@science.uva.nl>
The whole GHPN production for GGF13 is available at: https://forge.gridforum.org/docman2/ViewCategory.php? group_id=53&category_id=941
We've had a lively meeting (we went 10' past the end of our slot actually). I hope you will take the time to peruse the minutes and the material.
The State of the Drafts that I prepared is thought to be up to date (alert me if not) ... it also covers a couple of drafts that have been announced even though they didn't make the GGF13 cutoff date. See https://forge.gridforum.org/docman2/ViewProperties.php? group_id=53&category_id=941&document_content_id=3603
The GGF13 program featured a couple of interesting BOFs with strong network connotation. Kindly enough, both referenced GHPN material.
One was the Firewall and NAT BOF. The room consensus was that it should be chartered as a RG.
The other one was the VPN BOF.
On behalf of the GHPN, I invite these groups to use the GHPN community as a sounding board for their work. If they don't get the nod from the GFSG, they can also consider using the GHPN as the temporary home where to incubate their work further.
-franco
-- Admela -- http://www.francotravostino.name