<?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: Anagran Launches: The Return of Larry Roberts</title>
	<atom:link href="http://gigaom.com/2007/08/06/anagran/feed/" rel="self" type="application/rss+xml" />
	<link>http://gigaom.com/2007/08/06/anagran/</link>
	<description></description>
	<lastBuildDate>Sat, 11 Feb 2012 06:01:09 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Jon heil</title>
		<link>http://gigaom.com/2007/08/06/anagran/#comment-177112</link>
		<dc:creator><![CDATA[Jon heil]]></dc:creator>
		<pubDate>Fri, 10 Aug 2007 06:15:13 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/2007/08/06/anagran/#comment-177112</guid>
		<description><![CDATA[&lt;p&gt;Certainly one must be able to limit customers traffic for non revenue generating traffic and p2p users should not make the provider over provision their networks.  If one put in place a mechanism to limit the number of video and voice calls in high priority queues, this would be a welcome addition to any IP network.   Its fine to let a network congest if people are using the network illegally for p2p stuff.  Why should I bear the cost of another 10G interface?&lt;/p&gt;]]></description>
		<content:encoded><![CDATA[<p>Certainly one must be able to limit customers traffic for non revenue generating traffic and p2p users should not make the provider over provision their networks.  If one put in place a mechanism to limit the number of video and voice calls in high priority queues, this would be a welcome addition to any IP network.   Its fine to let a network congest if people are using the network illegally for p2p stuff.  Why should I bear the cost of another 10G interface?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: correlate &#187; Blog Archive &#187; Second Time is a Charm?</title>
		<link>http://gigaom.com/2007/08/06/anagran/#comment-177111</link>
		<dc:creator><![CDATA[correlate &#187; Blog Archive &#187; Second Time is a Charm?]]></dc:creator>
		<pubDate>Wed, 08 Aug 2007 01:10:13 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/2007/08/06/anagran/#comment-177111</guid>
		<description><![CDATA[&lt;p&gt;[...] Anagran Launches: The Return of Larry Roberts   Sphere: Related Content [...]&lt;/p&gt;]]></description>
		<content:encoded><![CDATA[<p>[...] Anagran Launches: The Return of Larry Roberts   Sphere: Related Content [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: &#187; Flow technology based routers for uninterrupted voice and video over the internet &#124; IT News Digest &#124; TechRepublic.com</title>
		<link>http://gigaom.com/2007/08/06/anagran/#comment-177110</link>
		<dc:creator><![CDATA[&#187; Flow technology based routers for uninterrupted voice and video over the internet &#124; IT News Digest &#124; TechRepublic.com]]></dc:creator>
		<pubDate>Tue, 07 Aug 2007 16:17:51 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/2007/08/06/anagran/#comment-177110</guid>
		<description><![CDATA[&lt;p&gt;[...] needs to be replaced with a more contiguous unit, such as &#8220;flow&#8221; of data. As defined at GigaOM, &#8220;A flow is a single meaningful end-to-end activity over the network, and is defined by the [...]&lt;/p&gt;]]></description>
		<content:encoded><![CDATA[<p>[...] needs to be replaced with a more contiguous unit, such as &#8220;flow&#8221; of data. As defined at GigaOM, &#8220;A flow is a single meaningful end-to-end activity over the network, and is defined by the [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Victor Blake</title>
		<link>http://gigaom.com/2007/08/06/anagran/#comment-177109</link>
		<dc:creator><![CDATA[Victor Blake]]></dc:creator>
		<pubDate>Tue, 07 Aug 2007 13:04:07 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/2007/08/06/anagran/#comment-177109</guid>
		<description><![CDATA[&lt;p&gt;While no-one can predict what will happen to any one company it is both easy and safe to say that within 2 generations all IP routers will have strong dpi and flow management capabilities. Most already have first generation flow-like technologies designed for streaming (ldp for example) forwarding. It&#039;s essentially the same idea.&lt;/p&gt;

&lt;p&gt;The Caspian platform was ahead of it&#039;s time in many ways, although -- again can&#039;t argue about the spending of money and the making of companies. Good technology doesn&#039;t necessarily make for great products.&lt;/p&gt;

&lt;p&gt;-Victor&lt;/p&gt;]]></description>
		<content:encoded><![CDATA[<p>While no-one can predict what will happen to any one company it is both easy and safe to say that within 2 generations all IP routers will have strong dpi and flow management capabilities. Most already have first generation flow-like technologies designed for streaming (ldp for example) forwarding. It&#8217;s essentially the same idea.</p>
<p>The Caspian platform was ahead of it&#8217;s time in many ways, although &#8212; again can&#8217;t argue about the spending of money and the making of companies. Good technology doesn&#8217;t necessarily make for great products.</p>
<p>-Victor</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Raindeer</title>
		<link>http://gigaom.com/2007/08/06/anagran/#comment-177108</link>
		<dc:creator><![CDATA[Raindeer]]></dc:creator>
		<pubDate>Tue, 07 Aug 2007 07:30:26 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/2007/08/06/anagran/#comment-177108</guid>
		<description><![CDATA[&lt;p&gt;I&#039;m definitely not sold on the concept. The trouble with this approach is that it expects that it can say which packets can be dropped and which packets can&#039;t be dropped. Like any and all Quality of Service mechanisms in the network it is based on the premise that there will be times when the network needs to drop packets. However a well run access network and backbone will not ever need to face that situation, if the network upgrades fast enough. If the network doesn&#039;t upgrade fast enough and it meets bottlenecks than these kind of technologies might alleviate the pain for a short while, but with traffic growing in most networks at a rate of 50% to a 100% per year, pretty soon after you&#039;ve chosen to drop one packet, your dropping one more and than one more at an alarming rate. By the end of the year, not even real time voice and video are safe from dropped packets.&lt;/p&gt;]]></description>
		<content:encoded><![CDATA[<p>I&#8217;m definitely not sold on the concept. The trouble with this approach is that it expects that it can say which packets can be dropped and which packets can&#8217;t be dropped. Like any and all Quality of Service mechanisms in the network it is based on the premise that there will be times when the network needs to drop packets. However a well run access network and backbone will not ever need to face that situation, if the network upgrades fast enough. If the network doesn&#8217;t upgrade fast enough and it meets bottlenecks than these kind of technologies might alleviate the pain for a short while, but with traffic growing in most networks at a rate of 50% to a 100% per year, pretty soon after you&#8217;ve chosen to drop one packet, your dropping one more and than one more at an alarming rate. By the end of the year, not even real time voice and video are safe from dropped packets.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Mackey</title>
		<link>http://gigaom.com/2007/08/06/anagran/#comment-177107</link>
		<dc:creator><![CDATA[David Mackey]]></dc:creator>
		<pubDate>Tue, 07 Aug 2007 02:42:22 +0000</pubDate>
		<guid isPermaLink="false">http://gigaom.com/2007/08/06/anagran/#comment-177107</guid>
		<description><![CDATA[&lt;p&gt;While the founder&#039;s background is a plus, I&#039;m not sold on the concept. I&#039;m not even sold that IPv6 will happen. How are we supposed to remember IP addresses? Its impossible - they are too long.&lt;/p&gt;]]></description>
		<content:encoded><![CDATA[<p>While the founder&#8217;s background is a plus, I&#8217;m not sold on the concept. I&#8217;m not even sold that IPv6 will happen. How are we supposed to remember IP addresses? Its impossible &#8211; they are too long.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

