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

Sat Apr 2 10:50:55 CST 2005

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

---------- Forwarded message ----------
From: Franco Travostino <franco.travostino at gmail.com>
Date: Mar 31, 2005 10:42 PM
Subject: Re: Admela Jukan's presentation
To: Admela Jukan <jukan at uiuc.edu>
Cc: "<bill.st.arnaud at canarie.ca>" <bill.st.arnaud at canarie.ca>,
ebslee at ntu.edu.sg, chyoun at icu.ac.kr, 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>

With regard to the 20k x 10Gbps argument eroding the usefulness of scheduling:

the cost may be that low until you hit a discontinuity and run out of
something --- PHYs, cards, NE's backplane, lambdas, software licenses,
OpEx contracts --- and need to go issue a new procurement.

also, there appears to be a "virtuous cycle" at play, with more
bandwidth enabling new services that enable new applications that
demand new bandwidth.

we have seen this phenomenon occurring in computing many times over.

we're seeing it with wireless (who would have thought that we would be
watching mobisodes when it all started)

if we want Grids to be a somewhat future-proof and versatile
infrastructure (beyond circuits), we need to take this virtuous cycle
of expansion into consideration and toy with (resource-agnostic!)
schedulers.

-franco

On Mar 31, 2005 7:12 PM, Admela Jukan <jukan at uiuc.edu> wrote:
> 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

-- 
http://www.francotravostino.name