<?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/"
		>
<channel>
	<title>Comments on: Public Knowledge blows it</title>
	<atom:link href="http://bennett.com/blog/2006/07/public-knowledge-blows-its-cover/feed/" rel="self" type="application/rss+xml" />
	<link>http://bennett.com/blog/2006/07/public-knowledge-blows-its-cover/</link>
	<description>A regular old blog</description>
	<lastBuildDate>Fri, 04 Sep 2009 23:51:11 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: George Ou</title>
		<link>http://bennett.com/blog/2006/07/public-knowledge-blows-its-cover/comment-page-1/#comment-315004</link>
		<dc:creator>George Ou</dc:creator>
		<pubDate>Sun, 16 Jul 2006 20:48:35 +0000</pubDate>
		<guid isPermaLink="false">http://bennett.com/blog/?p=3989#comment-315004</guid>
		<description>&quot;Would free QoS even work if ISPs had to give them away for free? Businesses and users will lazily or greedily overstate the QoS that they need for their applications. If an ISP refuses their QoS requests, the ISP would probably be sued or prosecuted for a “violation of net neutrality.” Furthermore, users would have little incentive to not overuse QoS connections. For example, they might leave their HDTVs on or leave their VVoIP connections open.&quot;

MnZ, you hit the nail on the head!

Oh but we can&#039;t be doing &quot;deep packet inspection&quot; now can we.  Remember if we have to look at the source or destination and the routers interact (collude with BGP in any way), we can&#039;t call it the &quot;Internet&quot; according to DPSProject.</description>
		<content:encoded><![CDATA[<p>&#8220;Would free QoS even work if ISPs had to give them away for free? Businesses and users will lazily or greedily overstate the QoS that they need for their applications. If an ISP refuses their QoS requests, the ISP would probably be sued or prosecuted for a “violation of net neutrality.” Furthermore, users would have little incentive to not overuse QoS connections. For example, they might leave their HDTVs on or leave their VVoIP connections open.&#8221;</p>
<p>MnZ, you hit the nail on the head!</p>
<p>Oh but we can&#8217;t be doing &#8220;deep packet inspection&#8221; now can we.  Remember if we have to look at the source or destination and the routers interact (collude with BGP in any way), we can&#8217;t call it the &#8220;Internet&#8221; according to DPSProject.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard</title>
		<link>http://bennett.com/blog/2006/07/public-knowledge-blows-its-cover/comment-page-1/#comment-314271</link>
		<dc:creator>Richard</dc:creator>
		<pubDate>Fri, 14 Jul 2006 23:49:23 +0000</pubDate>
		<guid isPermaLink="false">http://bennett.com/blog/?p=3989#comment-314271</guid>
		<description>That&#039;s always a challenge, of course. Given that Snowe-Dorgan bans for-fee QoS, I would emphasize why that&#039;s a technically infeasible approach, Ed. </description>
		<content:encoded><![CDATA[<p>That&#8217;s always a challenge, of course. Given that Snowe-Dorgan bans for-fee QoS, I would emphasize why that&#8217;s a technically infeasible approach, Ed.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ed Felten</title>
		<link>http://bennett.com/blog/2006/07/public-knowledge-blows-its-cover/comment-page-1/#comment-314262</link>
		<dc:creator>Ed Felten</dc:creator>
		<pubDate>Fri, 14 Jul 2006 23:27:50 +0000</pubDate>
		<guid isPermaLink="false">http://bennett.com/blog/?p=3989#comment-314262</guid>
		<description>The &quot;error&quot; you point to is just a decision on my part to simplify the explanation for nontechnical readers.   If you want to write a short paper that nontechies will be willing and able to understand, you have to leave some things out.  The congestion control discussion is about the cooperative nature of TCP backoff.  For that purpose it&#039;s enough to know that TCP works that way, and there is lots of TCP traffic.</description>
		<content:encoded><![CDATA[<p>The &#8220;error&#8221; you point to is just a decision on my part to simplify the explanation for nontechnical readers.   If you want to write a short paper that nontechies will be willing and able to understand, you have to leave some things out.  The congestion control discussion is about the cooperative nature of TCP backoff.  For that purpose it&#8217;s enough to know that TCP works that way, and there is lots of TCP traffic.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: max</title>
		<link>http://bennett.com/blog/2006/07/public-knowledge-blows-its-cover/comment-page-1/#comment-314195</link>
		<dc:creator>max</dc:creator>
		<pubDate>Fri, 14 Jul 2006 22:00:39 +0000</pubDate>
		<guid isPermaLink="false">http://bennett.com/blog/?p=3989#comment-314195</guid>
		<description>&lt;blockquote&gt;Could someone elaborate on the “smallish technical errors” in Professor Fulton’s paper?&lt;/blockquote&gt;

One of them revolves around the difference between TCP and UDP.  

In this example, he describes the behavior of TCP:

&lt;blockquote&gt;This is a very indirect way of coping with congestion—drop packets, wait for endpoint computers to notice the missing packets, and respond by slowing down—but it works pretty well.&lt;/blockquote&gt;


But doesn&#039;t realize that not all applications use TCP, some use UDP where there are no backoff, sliding windows or other flow control mechanisms.  Unfortunately, VOIP is an application that uses UDP primarily ;-)


Also take into consideration that the network community has realized for awhile the TCP is not very efficient and has many problems of it&#039;s own.  It was built for a time when the Internet was much less reliable, and has been reworked frequently to deal with it&#039;s performance related shortcomings.  It&#039;s sort of the X.25 of the IP world because of that.

He also seems at various times to confuse two different types of QoS.  There are guaranteed services, and then there are priority/ differentiated  services.  He clarifies this somewhat by saying he&#039;s only talking about guaranteed services as being QoS, fair enough point.

But in the networking world, you can user either or both together to get the same practical effects, depending on the situation. There are variations in the QoS world that are more complicated than just switching it on or off.

 Plus, the Internet is growing.  Right now,  Consumer grade VOIP is mostly a toy.  People expect better reliablity out of their land lines than their Cellphones, and a Pizza Joint that relies heavily on delivery orders will  require that same level of wireline reliability.</description>
		<content:encoded><![CDATA[<blockquote><p>Could someone elaborate on the “smallish technical errors” in Professor Fulton’s paper?</p></blockquote>
<p>One of them revolves around the difference between TCP and UDP.  </p>
<p>In this example, he describes the behavior of TCP:</p>
<blockquote><p>This is a very indirect way of coping with congestion—drop packets, wait for endpoint computers to notice the missing packets, and respond by slowing down—but it works pretty well.</p></blockquote>
<p>But doesn&#8217;t realize that not all applications use TCP, some use UDP where there are no backoff, sliding windows or other flow control mechanisms.  Unfortunately, VOIP is an application that uses UDP primarily ;-)</p>
<p>Also take into consideration that the network community has realized for awhile the TCP is not very efficient and has many problems of it&#8217;s own.  It was built for a time when the Internet was much less reliable, and has been reworked frequently to deal with it&#8217;s performance related shortcomings.  It&#8217;s sort of the X.25 of the IP world because of that.</p>
<p>He also seems at various times to confuse two different types of QoS.  There are guaranteed services, and then there are priority/ differentiated  services.  He clarifies this somewhat by saying he&#8217;s only talking about guaranteed services as being QoS, fair enough point.</p>
<p>But in the networking world, you can user either or both together to get the same practical effects, depending on the situation. There are variations in the QoS world that are more complicated than just switching it on or off.</p>
<p> Plus, the Internet is growing.  Right now,  Consumer grade VOIP is mostly a toy.  People expect better reliablity out of their land lines than their Cellphones, and a Pizza Joint that relies heavily on delivery orders will  require that same level of wireline reliability.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: MnZ</title>
		<link>http://bennett.com/blog/2006/07/public-knowledge-blows-its-cover/comment-page-1/#comment-314183</link>
		<dc:creator>MnZ</dc:creator>
		<pubDate>Fri, 14 Jul 2006 21:13:44 +0000</pubDate>
		<guid isPermaLink="false">http://bennett.com/blog/?p=3989#comment-314183</guid>
		<description>&lt;i&gt;If VoIP and streaming video need a smarter network, companies can build that smarter network. They just cannot charge extra for delivery of those specific services.&lt;/i&gt;

Would free QoS even work if ISPs had to give them away for free? Businesses and users will lazily or greedily overstate the QoS that they need for their applications. If an ISP refuses their QoS requests, the ISP would probably be sued or prosecuted for a &quot;violation of net neutrality.&quot; Futhermore, users would have little incentive to not overuse QoS connections. For example, they might leave their HDTVs on or leave their VVoIP connections open.</description>
		<content:encoded><![CDATA[<p><i>If VoIP and streaming video need a smarter network, companies can build that smarter network. They just cannot charge extra for delivery of those specific services.</i></p>
<p>Would free QoS even work if ISPs had to give them away for free? Businesses and users will lazily or greedily overstate the QoS that they need for their applications. If an ISP refuses their QoS requests, the ISP would probably be sued or prosecuted for a &#8220;violation of net neutrality.&#8221; Futhermore, users would have little incentive to not overuse QoS connections. For example, they might leave their HDTVs on or leave their VVoIP connections open.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.207 seconds -->
