<?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: Giving packets sirens</title>
	<atom:link href="http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/</link>
	<description>Let's just see what happens</description>
	<lastBuildDate>Sun, 16 Jun 2013 09:24:11 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Net Neutrality: Will the Web last forever? &#124; ShoutingInDigital</title>
		<link>http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/comment-page-1/#comment-48117</link>
		<dc:creator>Net Neutrality: Will the Web last forever? &#124; ShoutingInDigital</dc:creator>
		<pubDate>Wed, 15 Jul 2009 15:08:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/#comment-48117</guid>
		<description><![CDATA[[...] by SaveTheInternet.com and their cause has been taken up by thousands of people. However, not everyone agrees that Net Neutrality is necessarily a good thing, arguing that the new model might &#8220;allow [...]]]></description>
		<content:encoded><![CDATA[<p>[...] by SaveTheInternet.com and their cause has been taken up by thousands of people. However, not everyone agrees that Net Neutrality is necessarily a good thing, arguing that the new model might &#8220;allow [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: davidw</title>
		<link>http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/comment-page-1/#comment-28579</link>
		<dc:creator>davidw</dc:creator>
		<pubDate>Thu, 28 Feb 2008 17:57:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/#comment-28579</guid>
		<description><![CDATA[Richard, can you explain more about how the bucket-of-bits idea manages congestion? Let&#039;s say the 500 people sharing my stretch of the cable have bought the various size buckets, but we all decide to watch the high-def He-Hunks of Baywatch online special at 9pm on Monday. Presumably, we&#039;ll create congestion for one another. Does the bit-bucket proposal help prevent that somehow or help sort it out, or is it irrelevant to that particular traffic jam?

I&#039;m just trying to understand...]]></description>
		<content:encoded><![CDATA[<p>Richard, can you explain more about how the bucket-of-bits idea manages congestion? Let&#8217;s say the 500 people sharing my stretch of the cable have bought the various size buckets, but we all decide to watch the high-def He-Hunks of Baywatch online special at 9pm on Monday. Presumably, we&#8217;ll create congestion for one another. Does the bit-bucket proposal help prevent that somehow or help sort it out, or is it irrelevant to that particular traffic jam?</p>
<p>I&#8217;m just trying to understand&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard Bennett</title>
		<link>http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/comment-page-1/#comment-28482</link>
		<dc:creator>Richard Bennett</dc:creator>
		<pubDate>Wed, 27 Feb 2008 17:51:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/#comment-28482</guid>
		<description><![CDATA[Yes, it does manage congestion provided it&#039;s implemented in both the upstream and downstream entry point to the residential link.  It&#039;s pretty normal in enterprise wireless, and the universities love it. 

I suggested it in my written filing with the FCC a couple of weeks ago. It enhances both sein and zeit.]]></description>
		<content:encoded><![CDATA[<p>Yes, it does manage congestion provided it&#8217;s implemented in both the upstream and downstream entry point to the residential link.  It&#8217;s pretty normal in enterprise wireless, and the universities love it. </p>
<p>I suggested it in my written filing with the FCC a couple of weeks ago. It enhances both sein and zeit.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: davidw</title>
		<link>http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/comment-page-1/#comment-28471</link>
		<dc:creator>davidw</dc:creator>
		<pubDate>Wed, 27 Feb 2008 14:15:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/#comment-28471</guid>
		<description><![CDATA[Larry, I assume the provider would only provide a best-effort to speed the chosen packets through the last-mile funnel. Since, as Comcast said, they are managing the slowdowns caused by their party-line model, accelerating packets through that particular bulge in the pipe ought to be as effective as the protocol-based discrimination Comcast has been engaged in. (Am I getting this right? Or, more exactly, how am I getting this wrong?)

Richard, what you&#039;re proposing is a version of the &quot;bucket of bits&quot; idea that&#039;s structured like most cell phone contracts in the US? I like that idea in general. But does it manage the congestion?

Richard, after years of I&#039;d say pretty much uninterrupted disagreement, it was good to meet you and have a chance to talk with you about some of what we have in common.]]></description>
		<content:encoded><![CDATA[<p>Larry, I assume the provider would only provide a best-effort to speed the chosen packets through the last-mile funnel. Since, as Comcast said, they are managing the slowdowns caused by their party-line model, accelerating packets through that particular bulge in the pipe ought to be as effective as the protocol-based discrimination Comcast has been engaged in. (Am I getting this right? Or, more exactly, how am I getting this wrong?)</p>
<p>Richard, what you&#8217;re proposing is a version of the &#8220;bucket of bits&#8221; idea that&#8217;s structured like most cell phone contracts in the US? I like that idea in general. But does it manage the congestion?</p>
<p>Richard, after years of I&#8217;d say pretty much uninterrupted disagreement, it was good to meet you and have a chance to talk with you about some of what we have in common.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Akma &#187; Hmmm, Changing Topic</title>
		<link>http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/comment-page-1/#comment-28463</link>
		<dc:creator>Akma &#187; Hmmm, Changing Topic</dc:creator>
		<pubDate>Wed, 27 Feb 2008 09:12:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/#comment-28463</guid>
		<description><![CDATA[[...] Since I suggested yesterday that I would alternate days between anxiety and other topics, Iâ€™ll point to the heavy-handed corruption evinced by Comcastâ€™s deliberate inhibition of participatory democracy, and Iâ€™ll put off talking about lost sleep till tomorrow. On the other hand, if that fortune cookie slip were right, and my dreams were indeed to come true when I least expect it, I would be hard-pressed to imagine a time I expect it less than, for instance, right about now. &#160; Returning to Comcast, David provides both a rich account of what happened at the hearing (bloggie-style, so you have to read from the bottom up) and a meditation on how dangerous the path is that starts identifying some packets as privileged. [...]]]></description>
		<content:encoded><![CDATA[<p>[...] Since I suggested yesterday that I would alternate days between anxiety and other topics, Iâ€™ll point to the heavy-handed corruption evinced by Comcastâ€™s deliberate inhibition of participatory democracy, and Iâ€™ll put off talking about lost sleep till tomorrow. On the other hand, if that fortune cookie slip were right, and my dreams were indeed to come true when I least expect it, I would be hard-pressed to imagine a time I expect it less than, for instance, right about now. &nbsp; Returning to Comcast, David provides both a rich account of what happened at the hearing (bloggie-style, so you have to read from the bottom up) and a meditation on how dangerous the path is that starts identifying some packets as privileged. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard Bennett</title>
		<link>http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/comment-page-1/#comment-28429</link>
		<dc:creator>Richard Bennett</dc:creator>
		<pubDate>Wed, 27 Feb 2008 03:57:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/#comment-28429</guid>
		<description><![CDATA[Here&#039;s how I think this should work: your ISP should sell you a plan that allows you a certain quota of bandwidth in four classes of service. In the highest class, you&#039;d be limited to the equivalent of 30 minutes a day of VoIP, or about  30 MB. In the second class, you&#039;d get maybe 2 hours at SDTV video rate, about 75MB; in the third class you&#039;d get 150MB, and the fourth would be unlimited. You&#039;re free to use these quotas as you see fit, and it&#039;s your obligation to mark the streams, which your home gateway/router would do for you according to rules you define (as people configure WiFi WMM today.) 

If you go over quota for a certain class, it&#039;s simply demoted to the next lower class for which you have some quota left.  There is no guarantee of QoS outside the carrier&#039;s network, but if he wants to negotiate with his wholesale provider to honor your QoS markings that can be a selling point. 

This is good for ISP&#039;s because it relieves them of the hassle of packet stream inspection, and it&#039;s good for The People because it gives them QoS when they want it.

On a statistical network, there are no hard and fast guarantees, but there are statistical behaviors that can be manipulated in a meaningful way. So let&#039;s open the door to doing that. 

The only downside is that it make the NN issue go away completely, and some people obviously need to keep on making a living from it.

BTW, it was good to meet you yesterday, David.]]></description>
		<content:encoded><![CDATA[<p>Here&#8217;s how I think this should work: your ISP should sell you a plan that allows you a certain quota of bandwidth in four classes of service. In the highest class, you&#8217;d be limited to the equivalent of 30 minutes a day of VoIP, or about  30 MB. In the second class, you&#8217;d get maybe 2 hours at SDTV video rate, about 75MB; in the third class you&#8217;d get 150MB, and the fourth would be unlimited. You&#8217;re free to use these quotas as you see fit, and it&#8217;s your obligation to mark the streams, which your home gateway/router would do for you according to rules you define (as people configure WiFi WMM today.) </p>
<p>If you go over quota for a certain class, it&#8217;s simply demoted to the next lower class for which you have some quota left.  There is no guarantee of QoS outside the carrier&#8217;s network, but if he wants to negotiate with his wholesale provider to honor your QoS markings that can be a selling point. </p>
<p>This is good for ISP&#8217;s because it relieves them of the hassle of packet stream inspection, and it&#8217;s good for The People because it gives them QoS when they want it.</p>
<p>On a statistical network, there are no hard and fast guarantees, but there are statistical behaviors that can be manipulated in a meaningful way. So let&#8217;s open the door to doing that. </p>
<p>The only downside is that it make the NN issue go away completely, and some people obviously need to keep on making a living from it.</p>
<p>BTW, it was good to meet you yesterday, David.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jay Fienberg</title>
		<link>http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/comment-page-1/#comment-28413</link>
		<dc:creator>Jay Fienberg</dc:creator>
		<pubDate>Wed, 27 Feb 2008 01:31:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/#comment-28413</guid>
		<description><![CDATA[Quality of service (QoS) is also very subjective to the context in which someone is using an app. So, the real network management decision, imho, is not simply between one app and another app, or one protocol and another, but between specific needs in specific cases--something that *can&#039;t* be managed primarily at the public router level.

For example, I was involved in running some live audio events, RTSP streaming over the net, going back to 1996. And, the ability for certain players to buffer the streams effected the perception of QoS--in some cases, higher quality audio that was delayed (buffered) for 30 seconds was not acceptable. In other cases,  buffering was way better than degraded quality audio.

Given the known limitations of the network, between manual and automatic features in the audio players (one end) and decisions we&#039;d make about broadcasting the audio (the other end), we could optimize based on what we considered to be QoS for each event.]]></description>
		<content:encoded><![CDATA[<p>Quality of service (QoS) is also very subjective to the context in which someone is using an app. So, the real network management decision, imho, is not simply between one app and another app, or one protocol and another, but between specific needs in specific cases&#8211;something that *can&#8217;t* be managed primarily at the public router level.</p>
<p>For example, I was involved in running some live audio events, RTSP streaming over the net, going back to 1996. And, the ability for certain players to buffer the streams effected the perception of QoS&#8211;in some cases, higher quality audio that was delayed (buffered) for 30 seconds was not acceptable. In other cases,  buffering was way better than degraded quality audio.</p>
<p>Given the known limitations of the network, between manual and automatic features in the audio players (one end) and decisions we&#8217;d make about broadcasting the audio (the other end), we could optimize based on what we considered to be QoS for each event.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Larry Borsato</title>
		<link>http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/comment-page-1/#comment-28411</link>
		<dc:creator>Larry Borsato</dc:creator>
		<pubDate>Wed, 27 Feb 2008 00:40:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/#comment-28411</guid>
		<description><![CDATA[ISPs can get away with this story because of the network topology. Whether star or hub and spoke design, there are many different types of customers along the line between the cloud and you. That means that a single set of priority decisions will likely impact everyone in between.

If every end user were to be able to prioritize themselves, as some point those priorities would have to be resolved with each other. It surely won&#039;t be as granular as heart monitoring vs. thyroid because those probably aren&#039;t identfied as such - perhaps one can only use a source like MassGen to make the decision. VOIP or P2P are identifiable though, and thus easier to decide to block.]]></description>
		<content:encoded><![CDATA[<p>ISPs can get away with this story because of the network topology. Whether star or hub and spoke design, there are many different types of customers along the line between the cloud and you. That means that a single set of priority decisions will likely impact everyone in between.</p>
<p>If every end user were to be able to prioritize themselves, as some point those priorities would have to be resolved with each other. It surely won&#8217;t be as granular as heart monitoring vs. thyroid because those probably aren&#8217;t identfied as such &#8211; perhaps one can only use a source like MassGen to make the decision. VOIP or P2P are identifiable though, and thus easier to decide to block.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Harold Feld</title>
		<link>http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/comment-page-1/#comment-28399</link>
		<dc:creator>Harold Feld</dc:creator>
		<pubDate>Tue, 26 Feb 2008 21:47:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/#comment-28399</guid>
		<description><![CDATA[Indeed, I think it&#039;s important to resist this framing.  I&#039;ve written before both on the idea of allowing subscribers to shape their own traffic rather than having the providers do it.
http://www.wetmachine.com/totsf/item/988

And, as I&#039;ve observed, this is a best efforts network.  You want certainty, use a different network.  Different applications belong on different networks.  It is foolish to break the current best efforts network for a handful of applications favored by providers.]]></description>
		<content:encoded><![CDATA[<p>Indeed, I think it&#8217;s important to resist this framing.  I&#8217;ve written before both on the idea of allowing subscribers to shape their own traffic rather than having the providers do it.<br />
<a href="http://www.wetmachine.com/totsf/item/988" rel="nofollow">http://www.wetmachine.com/totsf/item/988</a></p>
<p>And, as I&#8217;ve observed, this is a best efforts network.  You want certainty, use a different network.  Different applications belong on different networks.  It is foolish to break the current best efforts network for a handful of applications favored by providers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Julian Bond</title>
		<link>http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/comment-page-1/#comment-28390</link>
		<dc:creator>Julian Bond</dc:creator>
		<pubDate>Tue, 26 Feb 2008 18:32:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.hyperorg.com/blogger/2008/02/26/giving-packets-sirens/#comment-28390</guid>
		<description><![CDATA[Show me something that genuinely needs low latency, low jitter packets and I&#039;ll show you something that shouldn&#039;t be carried over a consumer grade internet line. In general, more bandwidth and better design just solves this problem. And for proof of that, see Skype.]]></description>
		<content:encoded><![CDATA[<p>Show me something that genuinely needs low latency, low jitter packets and I&#8217;ll show you something that shouldn&#8217;t be carried over a consumer grade internet line. In general, more bandwidth and better design just solves this problem. And for proof of that, see Skype.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic page generated in 0.363 seconds. -->
<!-- Cached page generated by WP-Super-Cache on 2013-06-16 20:15:22 -->