[ghpn-wg] Fwd: Admela Jukan's presentation

Sat Apr 2 10:49:59 CST 2005

Interesting thread that has fallen off the GHPN reflector for no good
reason. -franco

---------- Forwarded message ----------
From: Admela Jukan <jukan at uiuc.edu>
Date: Mar 31, 2005 7:12 PM
Subject: Re: Admela Jukan's presentation
To: "<bill.st.arnaud at canarie.ca>" <bill.st.arnaud at canarie.ca>
Cc: ebslee at ntu.edu.sg, chyoun at icu.ac.kr, travos at ieee.org, Leon Gommans
<lgommans at science.uva.nl>, Gigi Karmous-Edwards <gkarmous at mcnc.org>,
imonga at nortel.com, Cees de Laat <delaat at science.uva.nl>, "Masum Z.
Hasan" <masum at 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 at ggf.org [mailto:owner-ghpn-wg at ggf.org] On Behalf
> Of Franco Travostino
> Sent: Thursday, March  31, 2005 2:44 PM
> To: ghpn-wg at gridforum.org
> Cc: chyoun at icu.ac.kr; ebslee at ntu.edu.sg; Masum Z. Hasan; Leon Gommans;
> imonga at 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 at gridforum.org
>  From: Franco Travostino <travos at ieee.org>
>  Subject: Seoul material is on-line
>  Cc: chyoun at icu.ac.kr, ebslee at ntu.edu.sg, "Masum Z. Hasan"
> <masum at cisco.com>, Leon Gommans <lgommans at science.uva.nl>, "inder
> [BL60:418:EXCH] Monga" <imonga at AMERICASM06.nt.com>, Admela Jukan
> <jukan at uiuc.edu>, Gigi Karmous-Edwards <gkarmous at mcnc.org>, Cees de
> Laat <delaat at 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