Good idea, if the network is smart enough to recognize the type of
traffic (even down to the individual message level) it could do MPLS
tagging to provide QoS across the WAN.
Another idea that came to me was creating an Akamai type cloud for
caching content close to consumer by being able to inspect content at
the message level and apply "caching policy".
For these and other reasons I see the network has to get smarter to
support the vision of cloud computing. However working for a networking
company I am a little biased :-)
Rgds
j
Khazret Sapenov wrote:
> John,
> Just rewinding a bit back (I'm easily distracted and often topic might
> go sideways :) ).
> Perhaps we could discuss things like differentiated services, where
> real-time applications like IP Telephony, Video On Demand/Conference
> etc, require end to end quality of service support and other
> guarantees (e.g. bandwidth). I've seen some efforts to run IP
> telephony on Amazon EC2, but didn't track it closely.
>
> Also we've had a pilot project with large media company related
> to Video on Demand that required some type of DiffServ cloud with
> tolerance to delays and guarantee for bandwidth to serve High
> Definition motion pictures.
>
> The latter might be a micromodel of Compute Cloud MBone, where edge
> routers manage QoS.
>
> KS
>
>
> On Mon, May 26, 2008 at 11:04 AM, John McDowall <john@mcdowall.com
> <mailto:john@mcdowall.com>> wrote:
>
>
> Khazret,
>
> My fault I did not frame thje question properly, I meant to say that
> packet routing/switching is fair game but the programmer semantics
> would
> be exposed at the message level. So put another way what would you
> like
> the switching/router fabric to do for you if you could program it with
> application/message knowledge not just packet knowledge.
>
> Regards
>
> John
> Khazret Sapenov wrote:
> > John,
> > Right, I intentionally didn't touch packet routing (as you
> asked), but
> > for private clouds UDP/unicast/multicast should work fine and
> will be
> > a bit more efficient, than TCP/IP.
> > KS
> > On Fri, May 23, 2008 at 8:52 PM, John McDowall
> <john@mcdowall.com <mailto:john@mcdowall.com>
> > <mailto:john@mcdowall.com <mailto:john@mcdowall.com>>> wrote:
> >
> >
> > Khazret,
> >
> > Interesting idea, so if the network was "smart" enough to
> act as a
> > discovery service it could direct "published" requests to the
> > appropriate source "subscribers". This would allow TCP/IP to
> be used
> > rather than UDP/multicast which has a few issues going
> across the
> > internet.
> >
> > Did I capture it right?
> >
> > John
> > Khazret Sapenov wrote:
> > > John,
> > > How about publish/subscribe event model, where interaction
> between
> > > cloud and user is done through message filtering?
> > > Say, client has named logical channel and there's also a
> common one
> > > for all clients, to which they subscribe and will receive all
> > messages
> > > published to the channels(topics).
> > > It would minimize bandwidth consumption (and maybe some other
> > > resources), if compared to polling cloud for current state
> of some
> > > process.
> > >
> > > KS
> > >
> > > On Fri, May 23, 2008 at 4:57 PM, John McDowall
> > <john@mcdowall.com <mailto:john@mcdowall.com>
> <mailto:john@mcdowall.com <mailto:john@mcdowall.com>>
> > > <mailto:john@mcdowall.com <mailto:john@mcdowall.com>
> <mailto:john@mcdowall.com <mailto:john@mcdowall.com>>>> wrote:
> > >
> > >
> > > All,
> > >
> > > I have seen some mention of the need for smart networks to
> > make cloud
> > > computing viable, or at least move it beyond hosting
> virtualized
> > > application containers. I would be interested in everyone
> > thoughts
> > > on what
> > > is needed from the network - smart and otherwise.
> (Disclaimer: I
> > > work for
> > > a network vendor).
> > >
> > > I see one of the attractive aspects of "cloud
> computing" is its
> > > potential
> > > elastic nature. To make elastic computing work (IMHO)
> there
> > needs
> > > to be
> > > some form of dynamic application/message routing (not
> > packets) that is
> > > activated based on "cloud policy" set jointly by the
> user and
> > > vendor of
> > > the cloud(s).
> > >
> > > Thoughts?
> > >
> > > Regards
> > >
> > > John McDowall
> > >
> > >
> > >
> > >
> > >
> > > >
> >
> >
> >
> >
> >
> > >
>
>
>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cloud Computing" group.
To post to this group, send email to cloud-computing@googlegroups.com
To unsubscribe from this group, send email to cloud-computing-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.ca/group/cloud-computing?hl=en
-~----------~----~----~----~------~----~------~--~---
No comments:
Post a Comment