<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:go='http://ns.gigaom.com/'
xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Avoiding Latency in the Cloud</title>
	<atom:link href="http://gigaom.com/2009/06/20/avoiding-latency-in-the-cloud/feed/" rel="self" type="application/rss+xml" />
	<link>http://gigaom.com/2009/06/20/avoiding-latency-in-the-cloud/</link>
	<description></description>
	<lastBuildDate>Sat, 11 Feb 2012 12:44:45 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Google on Net Neutrality, Its Fiber Buildout and Cloud - A Collection of Latest Happening in Technology Field</title>
		<link>http://gigaom.com/2009/06/20/avoiding-latency-in-the-cloud/#comment-214702</link>
		<dc:creator><![CDATA[Google on Net Neutrality, Its Fiber Buildout and Cloud - A Collection of Latest Happening in Technology Field]]></dc:creator>
		<pubDate>Tue, 13 Apr 2010 19:34:06 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/?p=54736#comment-214702</guid>
		<description><![CDATA[&lt;p&gt;[...] protocols that are open and standardized might make sense.  Look at companies like Aspera, which is offering a proprietary protocol to shift huge volumes of information between data [...]&lt;/p&gt;]]></description>
		<content:encoded><![CDATA[<p>[...] protocols that are open and standardized might make sense.  Look at companies like Aspera, which is offering a proprietary protocol to shift huge volumes of information between data [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aspera&#8217;s iPhone App Sends Fat Files With Ease &#8211; GigaOM</title>
		<link>http://gigaom.com/2009/06/20/avoiding-latency-in-the-cloud/#comment-214701</link>
		<dc:creator><![CDATA[Aspera&#8217;s iPhone App Sends Fat Files With Ease &#8211; GigaOM]]></dc:creator>
		<pubDate>Thu, 11 Feb 2010 15:54:55 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/?p=54736#comment-214701</guid>
		<description><![CDATA[&lt;p&gt;[...] used by media companies for transporting huge video files from New York to Los Angeles and even for sending data to the cloud. Its move to the iPhone was something CEO and Co-founder Michele Munson talked to me about last [...]&lt;/p&gt;]]></description>
		<content:encoded><![CDATA[<p>[...] used by media companies for transporting huge video files from New York to Los Angeles and even for sending data to the cloud. Its move to the iPhone was something CEO and Co-founder Michele Munson talked to me about last [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Micro-burst: Retrofit or Net-New? — Dave Graham's Weblog</title>
		<link>http://gigaom.com/2009/06/20/avoiding-latency-in-the-cloud/#comment-214700</link>
		<dc:creator><![CDATA[Micro-burst: Retrofit or Net-New? — Dave Graham's Weblog]]></dc:creator>
		<pubDate>Wed, 12 Aug 2009 20:38:07 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/?p=54736#comment-214700</guid>
		<description><![CDATA[[...] Avoiding Latency in the Cloud (gigaom.com) [...]]]></description>
		<content:encoded><![CDATA[<p>[...] Avoiding Latency in the Cloud (gigaom.com) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Let&#039;s Innovate: Discussions about Supercomputing, High Performance Computing and High-Speed Networks &#187; Avoiding Latency in the Cloud</title>
		<link>http://gigaom.com/2009/06/20/avoiding-latency-in-the-cloud/#comment-214699</link>
		<dc:creator><![CDATA[Let&#039;s Innovate: Discussions about Supercomputing, High Performance Computing and High-Speed Networks &#187; Avoiding Latency in the Cloud]]></dc:creator>
		<pubDate>Wed, 22 Jul 2009 19:14:05 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/?p=54736#comment-214699</guid>
		<description><![CDATA[[...] Munson, the pres­i­dent and co-​founder of Aspera, writes about the chal­lenges and poten­tial of the cloud.  &#8220;Ask any IT exec­u­tive or dig­i­tal media man­ager who used FTP to move large data [...]]]></description>
		<content:encoded><![CDATA[<p>[...] Munson, the pres­i­dent and co-​founder of Aspera, writes about the chal­lenges and poten­tial of the cloud.  &#8220;Ask any IT exec­u­tive or dig­i­tal media man­ager who used FTP to move large data [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brett McAteer at IPeak Networks</title>
		<link>http://gigaom.com/2009/06/20/avoiding-latency-in-the-cloud/#comment-214698</link>
		<dc:creator><![CDATA[Brett McAteer at IPeak Networks]]></dc:creator>
		<pubDate>Mon, 22 Jun 2009 13:09:24 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/?p=54736#comment-214698</guid>
		<description><![CDATA[Mr President, his mode of expression notwithstanding, is right about the folly of substituting one cost for another while adding complexity at the user level.  That is a doomed proposition.

At some level, everybody is right on the issue but there is a natural tendency to stray from the fundamentals.  Will anybody argue that network latency is not a challenge?  Will anybody argue that packet loss is not a problem?  Our experience (and yours, too, whether you make the connection or not) is that the negative effects of packet loss are actually growing as real-time, cloud, and virtualized applications generate increasing demand for good network performance and quality.  And our experience also shows that it is entirely possible to all but eliminate the packet loss that is endemic to best efforts networks while adding no latency of any consequence.  This will prove a boon to some cloud apps.

This much seems obvious: We all want to be using best efforts networks before paying for the &#039;fat pipes&#039; of dedicated bandwidth.  In fact, we all need to be going over-the-top of the public Internet for many of our networked business applications.  At IPeak Networks, we believe Aspera has the right idea and we applaud every effort to make the cloud make better business sense.  IPeak Networks happens to be oriented on making the best use of the lowest cost and most readily available network services but there is certainly room for solutions at both ends of the economic spectrum.]]></description>
		<content:encoded><![CDATA[<p>Mr President, his mode of expression notwithstanding, is right about the folly of substituting one cost for another while adding complexity at the user level.  That is a doomed proposition.</p>
<p>At some level, everybody is right on the issue but there is a natural tendency to stray from the fundamentals.  Will anybody argue that network latency is not a challenge?  Will anybody argue that packet loss is not a problem?  Our experience (and yours, too, whether you make the connection or not) is that the negative effects of packet loss are actually growing as real-time, cloud, and virtualized applications generate increasing demand for good network performance and quality.  And our experience also shows that it is entirely possible to all but eliminate the packet loss that is endemic to best efforts networks while adding no latency of any consequence.  This will prove a boon to some cloud apps.</p>
<p>This much seems obvious: We all want to be using best efforts networks before paying for the &#8216;fat pipes&#8217; of dedicated bandwidth.  In fact, we all need to be going over-the-top of the public Internet for many of our networked business applications.  At IPeak Networks, we believe Aspera has the right idea and we applaud every effort to make the cloud make better business sense.  IPeak Networks happens to be oriented on making the best use of the lowest cost and most readily available network services but there is certainly room for solutions at both ends of the economic spectrum.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: knujlla</title>
		<link>http://gigaom.com/2009/06/20/avoiding-latency-in-the-cloud/#comment-214697</link>
		<dc:creator><![CDATA[knujlla]]></dc:creator>
		<pubDate>Mon, 22 Jun 2009 04:30:29 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/?p=54736#comment-214697</guid>
		<description><![CDATA[D00d for all this ferocity of your opinion, you aren&#039;t even secure enough to disclose who you are and what you stand for? I am sure many folks would love to have based discussion on this topic.

What Aspera is doing is to present a point of view, which you have full right to refute. All they are saying is their President will talk about this position at an upcoming conference.

At any rate, would you agree that data is being produced many times faster than the network speeds? And as this data being generated is increasing, it needs to be analyzed for which it need to be stored so interesting queries can be run on it.

In expressing you disapproval, you have gone from economics of cloud storage, economics of cloud itself, then UI (??).... could it be possible that this pain point is broad enough that Aspera may be addressing it and solving at least one aspect of the cloud storage economics - getting the data in a fast and reliable manner.]]></description>
		<content:encoded><![CDATA[<p>D00d for all this ferocity of your opinion, you aren&#8217;t even secure enough to disclose who you are and what you stand for? I am sure many folks would love to have based discussion on this topic.</p>
<p>What Aspera is doing is to present a point of view, which you have full right to refute. All they are saying is their President will talk about this position at an upcoming conference.</p>
<p>At any rate, would you agree that data is being produced many times faster than the network speeds? And as this data being generated is increasing, it needs to be analyzed for which it need to be stored so interesting queries can be run on it.</p>
<p>In expressing you disapproval, you have gone from economics of cloud storage, economics of cloud itself, then UI (??)&#8230;. could it be possible that this pain point is broad enough that Aspera may be addressing it and solving at least one aspect of the cloud storage economics &#8211; getting the data in a fast and reliable manner.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Barack Obama</title>
		<link>http://gigaom.com/2009/06/20/avoiding-latency-in-the-cloud/#comment-214696</link>
		<dc:creator><![CDATA[Barack Obama]]></dc:creator>
		<pubDate>Sun, 21 Jun 2009 21:00:23 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/?p=54736#comment-214696</guid>
		<description><![CDATA[These are fantastic shill comments, but they can&#039;t distract from the fact that if your organization is stupid enough to rely on FTP and naive enough to try to bandaid it with file storage, then your organization&#039;s problem isn&#039;t how to handle data, it&#039;s how to handle incompetence.

Let me put it this way: if you showed this article to an engineer at a company who takes data transfer and bandwidth seriously (say Google), you&#039;d get laughed out of the room for even presenting this laughably bad &quot;solution.&quot;

Here&#039;s why this article is pure snakeoil: it doesn&#039;t provide you with any useful information about *how* to approaches the problem. It simply states that its &quot;solution&quot; will solve your problems and make your life better. Like I said before, it&#039;s the value proposition. Not only is this approach willfully dishonest, it&#039;s completely unethical. If you want to make good decisions, get the facts, and judge their value on your own. Don&#039;t rely on some salesperson hiding in writer&#039;s clothes to make the value judgement for you. That&#039;s just plain stupidity.

The fact is that cloud storage provides absolutely no real cost savings anywhere. Why? Because the minuscule savings you achieve in bandwidth performance is fizzled away by the cloud service costs, not to mention the cost increases in IT deployment and maintenance procedures.

Never mind that the actual usability of cloud storage is very poorly thought through, no matter who you use for a provider.

Have you ever personally used a cloud solution to transfer data? What&#039;s the first headache you run into? Oh look, you have to use some lame web interface, or some poorly written Explorer add-in, or do a file-drop to some strange network location. All you&#039;re doing is asking your users to trade-in the familiarity of FTP for a new complicated procedure that saves them absolutely nothing. If it&#039;s a web interface, you still have to hit the browse button (there&#039;s no drag &amp; drop). If it&#039;s an explorer add-in, it typically doesn&#039;t replicate all of the explorer functionality users need, and it almost never plays nicely with other Explorer plug-ins. If it&#039;s a drop location, prepare for endless help desk calls as users ask, &quot;how do I know it went through? what&#039;s happening? I don&#039;t understand this?&quot;

Also, in reference to 1996, I&#039;m laughing at the fact that this article references latency as some sort of salient point. Seriously? You&#039;re attacking the problem by arguing latency? That&#039;s like me attacking the age of the Earth by citing flaws in carbon dating. It&#039;s a straw man argument that you should be ashamed of.

This sales pitch for cloud storage is a joke. Anyone who tries to sell you on the cloud by only telling you how great your life will be after is a thief. Anyone who falls for it is incompetent.]]></description>
		<content:encoded><![CDATA[<p>These are fantastic shill comments, but they can&#8217;t distract from the fact that if your organization is stupid enough to rely on FTP and naive enough to try to bandaid it with file storage, then your organization&#8217;s problem isn&#8217;t how to handle data, it&#8217;s how to handle incompetence.</p>
<p>Let me put it this way: if you showed this article to an engineer at a company who takes data transfer and bandwidth seriously (say Google), you&#8217;d get laughed out of the room for even presenting this laughably bad &#8220;solution.&#8221;</p>
<p>Here&#8217;s why this article is pure snakeoil: it doesn&#8217;t provide you with any useful information about *how* to approaches the problem. It simply states that its &#8220;solution&#8221; will solve your problems and make your life better. Like I said before, it&#8217;s the value proposition. Not only is this approach willfully dishonest, it&#8217;s completely unethical. If you want to make good decisions, get the facts, and judge their value on your own. Don&#8217;t rely on some salesperson hiding in writer&#8217;s clothes to make the value judgement for you. That&#8217;s just plain stupidity.</p>
<p>The fact is that cloud storage provides absolutely no real cost savings anywhere. Why? Because the minuscule savings you achieve in bandwidth performance is fizzled away by the cloud service costs, not to mention the cost increases in IT deployment and maintenance procedures.</p>
<p>Never mind that the actual usability of cloud storage is very poorly thought through, no matter who you use for a provider.</p>
<p>Have you ever personally used a cloud solution to transfer data? What&#8217;s the first headache you run into? Oh look, you have to use some lame web interface, or some poorly written Explorer add-in, or do a file-drop to some strange network location. All you&#8217;re doing is asking your users to trade-in the familiarity of FTP for a new complicated procedure that saves them absolutely nothing. If it&#8217;s a web interface, you still have to hit the browse button (there&#8217;s no drag &amp; drop). If it&#8217;s an explorer add-in, it typically doesn&#8217;t replicate all of the explorer functionality users need, and it almost never plays nicely with other Explorer plug-ins. If it&#8217;s a drop location, prepare for endless help desk calls as users ask, &#8220;how do I know it went through? what&#8217;s happening? I don&#8217;t understand this?&#8221;</p>
<p>Also, in reference to 1996, I&#8217;m laughing at the fact that this article references latency as some sort of salient point. Seriously? You&#8217;re attacking the problem by arguing latency? That&#8217;s like me attacking the age of the Earth by citing flaws in carbon dating. It&#8217;s a straw man argument that you should be ashamed of.</p>
<p>This sales pitch for cloud storage is a joke. Anyone who tries to sell you on the cloud by only telling you how great your life will be after is a thief. Anyone who falls for it is incompetent.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Phineas</title>
		<link>http://gigaom.com/2009/06/20/avoiding-latency-in-the-cloud/#comment-214695</link>
		<dc:creator><![CDATA[Phineas]]></dc:creator>
		<pubDate>Sun, 21 Jun 2009 17:02:46 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/?p=54736#comment-214695</guid>
		<description><![CDATA[&quot;Barack Obama&quot; couldn&#039;t have it more wrong. There&#039;s a reason that the cloud provider was offering &quot;shipped physical media&quot; as a way to get data into the cloud... traditional file transfer just doesn&#039;t cut it in the first place  (FTP and HTTP as TCP-based protocols being the worst), and this problem is exacerbated by poorly-performing clouds.

There are few successful companies providing file transfer alternatives to technologies like FTP, and the cloud providers need to begin devising a way to integrate those replacements into the core of their offering. &quot;Cloud storage&quot; providers expecting someone to upload terabytes of data--using methods like FTP--is the part that&#039;s dating back to 1996.

Whether on the cloud or not, enterprises need to look into the alternatives... yes, they cost money (sophisticated technology isn&#039;t an accident), but they&#039;re increasingly necessary with the volumes of data people handle these days.]]></description>
		<content:encoded><![CDATA[<p>&#8220;Barack Obama&#8221; couldn&#8217;t have it more wrong. There&#8217;s a reason that the cloud provider was offering &#8220;shipped physical media&#8221; as a way to get data into the cloud&#8230; traditional file transfer just doesn&#8217;t cut it in the first place  (FTP and HTTP as TCP-based protocols being the worst), and this problem is exacerbated by poorly-performing clouds.</p>
<p>There are few successful companies providing file transfer alternatives to technologies like FTP, and the cloud providers need to begin devising a way to integrate those replacements into the core of their offering. &#8220;Cloud storage&#8221; providers expecting someone to upload terabytes of data&#8211;using methods like FTP&#8211;is the part that&#8217;s dating back to 1996.</p>
<p>Whether on the cloud or not, enterprises need to look into the alternatives&#8230; yes, they cost money (sophisticated technology isn&#8217;t an accident), but they&#8217;re increasingly necessary with the volumes of data people handle these days.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Robins</title>
		<link>http://gigaom.com/2009/06/20/avoiding-latency-in-the-cloud/#comment-214694</link>
		<dc:creator><![CDATA[David Robins]]></dc:creator>
		<pubDate>Sun, 21 Jun 2009 06:35:16 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/?p=54736#comment-214694</guid>
		<description><![CDATA[I find this article quite interesting and informative. I am not sure what Mr &quot;Barack Obama-really!&quot; is talking about. The transfer speed is a big issue for any cloud site and needs to be resolved. FTP spec is much older than internet and needs to be replaced by something more efficient.]]></description>
		<content:encoded><![CDATA[<p>I find this article quite interesting and informative. I am not sure what Mr &#8220;Barack Obama-really!&#8221; is talking about. The transfer speed is a big issue for any cloud site and needs to be resolved. FTP spec is much older than internet and needs to be replaced by something more efficient.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Barack Obama</title>
		<link>http://gigaom.com/2009/06/20/avoiding-latency-in-the-cloud/#comment-214693</link>
		<dc:creator><![CDATA[Barack Obama]]></dc:creator>
		<pubDate>Sun, 21 Jun 2009 00:49:46 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/?p=54736#comment-214693</guid>
		<description><![CDATA[What the hell is this crap? Was this written in 1996 and freshened up for today? I&#039;m sorry, but this is the most obvious and vulgar jargon-filled snakeoil value proposition piece I&#039;ve ever read. This is the piece you show to executives who don&#039;t know the first thing about technology when you want to sucker them into buying some obscenely expensive package. For a professional who is immersed in technology and has seen all of the hucksters come and go, this rates a C-.]]></description>
		<content:encoded><![CDATA[<p>What the hell is this crap? Was this written in 1996 and freshened up for today? I&#8217;m sorry, but this is the most obvious and vulgar jargon-filled snakeoil value proposition piece I&#8217;ve ever read. This is the piece you show to executives who don&#8217;t know the first thing about technology when you want to sucker them into buying some obscenely expensive package. For a professional who is immersed in technology and has seen all of the hucksters come and go, this rates a C-.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

