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> 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>> 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>>> 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
-~----------~----~----~----~------~----~------~--~---
Posts
No comments:
Post a Comment