<?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: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: How RED can solve congestion problems</title>
	<atom:link href="http://rdist.root.org/2008/03/27/how-red-can-solve-congestion-problems/feed/" rel="self" type="application/rss+xml" />
	<link>http://rdist.root.org/2008/03/27/how-red-can-solve-congestion-problems/</link>
	<description>Embedded security, crypto, software protection</description>
	<lastBuildDate>Mon, 06 Feb 2012 20:16:28 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Nate Lawson</title>
		<link>http://rdist.root.org/2008/03/27/how-red-can-solve-congestion-problems/comment-page-1/#comment-4601</link>
		<dc:creator><![CDATA[Nate Lawson]]></dc:creator>
		<pubDate>Mon, 05 May 2008 20:37:33 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/?p=122#comment-4601</guid>
		<description><![CDATA[Stephan, fascinating stuff.  Hopefully, the telcos were too blatant about this and the backlash will force them to comply with what we all want in Internet access (no interference).]]></description>
		<content:encoded><![CDATA[<p>Stephan, fascinating stuff.  Hopefully, the telcos were too blatant about this and the backlash will force them to comply with what we all want in Internet access (no interference).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stephan Sokolow</title>
		<link>http://rdist.root.org/2008/03/27/how-red-can-solve-congestion-problems/comment-page-1/#comment-4596</link>
		<dc:creator><![CDATA[Stephan Sokolow]]></dc:creator>
		<pubDate>Sun, 04 May 2008 17:13:48 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/?p=122#comment-4596</guid>
		<description><![CDATA[I&#039;d suggest you take a look at what&#039;s happening in Canada right now.

Bell Sympatico (The ISP owned by the local telecom provider) started throttling and, taking a lesson from the ingenuity of P2P software developers, they based it on whitelisting to catch encrypted or obfuscated P2P connections. (Any traffic that hasn&#039;t been pre-approved has to share the same 30KB per person out of the total 5Mbit the user purchased) They also switched from flat-rate bandwidth to 60GB per month combined up/down with $1.50/GB overage.

Cable providers like Rogers (outside Quebec) and Videotron (inside Quebec) have implemented the exact same pricing model but have managed to game the system so that it&#039;s not feasible for 3rd-party ISPs to lease their lines. The customers are convinced that it&#039;s price-fixing and the Quebec l’Union des consommateurs has filed a class action lawsuit against Videotron.

Customers started fleeing to third-party DSL ISPs like TekSavvy, and six months later, Bell moved their throttling to the GAS loops (controlled by BCE Nexxia, the bell subsidary which handles internal backbone infrastructure) without warning the 3rd-party ISPs. (Keep in mind that, according to their contracts, GAS loops are supposed to behave as if the two parties had strung their own wire between two points)

Knowing that they were on shaky ground legally, Bell claimed that their network was congested and it was a necessary measure to prevent degradation of all services on the Bell network. Surprisingly, they&#039;re also apparently preparing an IPTV service for launch. (Surprisingly, because they seem to think they can get away with all of these blatant lies)

They claimed that 5% of users (with P2P) use over 90% of the bandwidth, but that was based on an outdated report published by a manufacturer of throlling boxes. (SandVine, I believe) A newer report indicates that, at &quot;peak times&quot; (when Bell throttles hardest), the biggest consumer of bandwidth is now HTTP, primarily video streaming on sites like YouTube.

In addition, according to frustrated customers and former Bell employees, Bell literally runs their infrastructure until it breaks (Apparently, they waited until the late 70s or early 80s to replace a telephone switch made in 1918) sometimes refusing to replace faulty wiring. Cost breakdowns show that Bell has gouged customers enough that we could probably have FTTC by now.

At present, CAIP (the Canadian Association of Internet Providers) has filed a complaint with the CRTC (canadian FCC) and has been joined by Vaxination Informatique and Primus (one of Bell&#039;s telecom competitors) and most Canadians are hoping that quantity will overcome quality since the CRTC has historically been in big telecom&#039;s pocket.

The government has been taking a lot of flack in the papers because Jim Prentice (minister of industry) essentially said &quot;not our problem&quot;.

Finally, keeping this account chronological, Wireless Nomad and the Quebec l’Union des consommateurs have joined CAIP in the request to the CRTC that Bell be forced to cease throttling. (More specifically, two requests. One requesting that it be stopped permanently and one requesting that it be stopped until the CRTC decides in order to prevent economic harm to Sympatico&#039;s competitors.)

The general view on the issue from consumers like myself is that it&#039;s a conflict of interest with BCE Nexxia being told to give Bell ExpressVu (satellite tv) and Bell Canada (telephone) a leg up on VoIP, IPTV, and P2P (They&#039;re apparently also partnering with Microsoft to offer music downloads) since companies in Nexxia&#039;s position usually prefer to sell as much bandwidth as client companies are willing to pay for.

In Quebec, a bill is being introduced by the Bloc Québecois to give the province it&#039;s own CRTC-equivalent called the CRTQ and, if the current conservative (right-wing) government doesn&#039;t support it, it&#039;ll really bite them come election time. (Remember, this is the province which almost separated from Canada in 1995)

http://www.p2pnet.net/story/15671 provides a good way to get up to speed on it if you&#039;d like to read more.]]></description>
		<content:encoded><![CDATA[<p>I&#8217;d suggest you take a look at what&#8217;s happening in Canada right now.</p>
<p>Bell Sympatico (The ISP owned by the local telecom provider) started throttling and, taking a lesson from the ingenuity of P2P software developers, they based it on whitelisting to catch encrypted or obfuscated P2P connections. (Any traffic that hasn&#8217;t been pre-approved has to share the same 30KB per person out of the total 5Mbit the user purchased) They also switched from flat-rate bandwidth to 60GB per month combined up/down with $1.50/GB overage.</p>
<p>Cable providers like Rogers (outside Quebec) and Videotron (inside Quebec) have implemented the exact same pricing model but have managed to game the system so that it&#8217;s not feasible for 3rd-party ISPs to lease their lines. The customers are convinced that it&#8217;s price-fixing and the Quebec l’Union des consommateurs has filed a class action lawsuit against Videotron.</p>
<p>Customers started fleeing to third-party DSL ISPs like TekSavvy, and six months later, Bell moved their throttling to the GAS loops (controlled by BCE Nexxia, the bell subsidary which handles internal backbone infrastructure) without warning the 3rd-party ISPs. (Keep in mind that, according to their contracts, GAS loops are supposed to behave as if the two parties had strung their own wire between two points)</p>
<p>Knowing that they were on shaky ground legally, Bell claimed that their network was congested and it was a necessary measure to prevent degradation of all services on the Bell network. Surprisingly, they&#8217;re also apparently preparing an IPTV service for launch. (Surprisingly, because they seem to think they can get away with all of these blatant lies)</p>
<p>They claimed that 5% of users (with P2P) use over 90% of the bandwidth, but that was based on an outdated report published by a manufacturer of throlling boxes. (SandVine, I believe) A newer report indicates that, at &#8220;peak times&#8221; (when Bell throttles hardest), the biggest consumer of bandwidth is now HTTP, primarily video streaming on sites like YouTube.</p>
<p>In addition, according to frustrated customers and former Bell employees, Bell literally runs their infrastructure until it breaks (Apparently, they waited until the late 70s or early 80s to replace a telephone switch made in 1918) sometimes refusing to replace faulty wiring. Cost breakdowns show that Bell has gouged customers enough that we could probably have FTTC by now.</p>
<p>At present, CAIP (the Canadian Association of Internet Providers) has filed a complaint with the CRTC (canadian FCC) and has been joined by Vaxination Informatique and Primus (one of Bell&#8217;s telecom competitors) and most Canadians are hoping that quantity will overcome quality since the CRTC has historically been in big telecom&#8217;s pocket.</p>
<p>The government has been taking a lot of flack in the papers because Jim Prentice (minister of industry) essentially said &#8220;not our problem&#8221;.</p>
<p>Finally, keeping this account chronological, Wireless Nomad and the Quebec l’Union des consommateurs have joined CAIP in the request to the CRTC that Bell be forced to cease throttling. (More specifically, two requests. One requesting that it be stopped permanently and one requesting that it be stopped until the CRTC decides in order to prevent economic harm to Sympatico&#8217;s competitors.)</p>
<p>The general view on the issue from consumers like myself is that it&#8217;s a conflict of interest with BCE Nexxia being told to give Bell ExpressVu (satellite tv) and Bell Canada (telephone) a leg up on VoIP, IPTV, and P2P (They&#8217;re apparently also partnering with Microsoft to offer music downloads) since companies in Nexxia&#8217;s position usually prefer to sell as much bandwidth as client companies are willing to pay for.</p>
<p>In Quebec, a bill is being introduced by the Bloc Québecois to give the province it&#8217;s own CRTC-equivalent called the CRTQ and, if the current conservative (right-wing) government doesn&#8217;t support it, it&#8217;ll really bite them come election time. (Remember, this is the province which almost separated from Canada in 1995)</p>
<p><a href="http://www.p2pnet.net/story/15671" rel="nofollow">http://www.p2pnet.net/story/15671</a> provides a good way to get up to speed on it if you&#8217;d like to read more.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ben C</title>
		<link>http://rdist.root.org/2008/03/27/how-red-can-solve-congestion-problems/comment-page-1/#comment-4549</link>
		<dc:creator><![CDATA[Ben C]]></dc:creator>
		<pubDate>Fri, 11 Apr 2008 02:37:29 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/?p=122#comment-4549</guid>
		<description><![CDATA[You know what would work even better then Congestion Avoidance such as WRED. Class-based Weighted Fair Queuing (CBWFQ). CBWFQ can kick in when there is congestion to guarantee classes of traffic specific amounts of bandwidth and to give priority to classes of traffic for queuing (low-latency queuing LLQ).

So P2P traffic that is clogging the choke-points can be limited in bandwidth, VoIP and gaming traffic can be give low-latency by giving them priority, and P2P traffic can be throttled, with the default-class left to use up the rest of the bandwidth as best-effort.

If a Service Provider wanted to differentiate Seeding traffic from downloading traffic, they could have them in separate classes. And if they really wanted to they could police the seeding traffic to 0, effectively blocking it.]]></description>
		<content:encoded><![CDATA[<p>You know what would work even better then Congestion Avoidance such as WRED. Class-based Weighted Fair Queuing (CBWFQ). CBWFQ can kick in when there is congestion to guarantee classes of traffic specific amounts of bandwidth and to give priority to classes of traffic for queuing (low-latency queuing LLQ).</p>
<p>So P2P traffic that is clogging the choke-points can be limited in bandwidth, VoIP and gaming traffic can be give low-latency by giving them priority, and P2P traffic can be throttled, with the default-class left to use up the rest of the bandwidth as best-effort.</p>
<p>If a Service Provider wanted to differentiate Seeding traffic from downloading traffic, they could have them in separate classes. And if they really wanted to they could police the seeding traffic to 0, effectively blocking it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ben C</title>
		<link>http://rdist.root.org/2008/03/27/how-red-can-solve-congestion-problems/comment-page-1/#comment-4548</link>
		<dc:creator><![CDATA[Ben C]]></dc:creator>
		<pubDate>Fri, 11 Apr 2008 01:52:52 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/?p=122#comment-4548</guid>
		<description><![CDATA[Nate: They can do deep packet inspection to determine if its BitTorrent seeding and if so mark the packet. Once the packet is marked, WRED etc can be used downstream.

If the edge devices&#039; deep packet inspection features (NBAR, or similar) does not understand the difference between seeding and downloading (or any other protocol-specific fine granularity) it should at least be able to identify bittorrent traffic. This traffic could then be punted to a proxy that has the smarts to differentiate seeding and downloading and re-inject the packets into the network with the corresponding markings.

I think it is the wrong solution to change the TCP stacks on the client machines to mark the traffic. TCP/IP today already supports marking, and the client cannot be trusted to mark the traffic according the the service providers business rules. The SP needs to inspect the traffic and mark it themselves.]]></description>
		<content:encoded><![CDATA[<p>Nate: They can do deep packet inspection to determine if its BitTorrent seeding and if so mark the packet. Once the packet is marked, WRED etc can be used downstream.</p>
<p>If the edge devices&#8217; deep packet inspection features (NBAR, or similar) does not understand the difference between seeding and downloading (or any other protocol-specific fine granularity) it should at least be able to identify bittorrent traffic. This traffic could then be punted to a proxy that has the smarts to differentiate seeding and downloading and re-inject the packets into the network with the corresponding markings.</p>
<p>I think it is the wrong solution to change the TCP stacks on the client machines to mark the traffic. TCP/IP today already supports marking, and the client cannot be trusted to mark the traffic according the the service providers business rules. The SP needs to inspect the traffic and mark it themselves.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nate Lawson</title>
		<link>http://rdist.root.org/2008/03/27/how-red-can-solve-congestion-problems/comment-page-1/#comment-4525</link>
		<dc:creator><![CDATA[Nate Lawson]]></dc:creator>
		<pubDate>Sat, 29 Mar 2008 19:04:34 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/?p=122#comment-4525</guid>
		<description><![CDATA[Evan S: that&#039;s an interesting theory.  We&#039;ll have to wait and see what happens.]]></description>
		<content:encoded><![CDATA[<p>Evan S: that&#8217;s an interesting theory.  We&#8217;ll have to wait and see what happens.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Evan S</title>
		<link>http://rdist.root.org/2008/03/27/how-red-can-solve-congestion-problems/comment-page-1/#comment-4518</link>
		<dc:creator><![CDATA[Evan S]]></dc:creator>
		<pubDate>Fri, 28 Mar 2008 18:36:17 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.root.org/?p=122#comment-4518</guid>
		<description><![CDATA[Nate: I was imagining this in a linux/bsd context, where modifying your TCP stack and recompiling is fairly trivial. Given the prevalence of Linux-based routers, a firmware upgrade could provide a router with a new stack and a proxy service that users could use for their high bandwidth applications. However, if ISPs go with this as their primary means of congestion control, I&#039;d bet on seeing a Windows-only alternative in the spirit of winpcap very soon.]]></description>
		<content:encoded><![CDATA[<p>Nate: I was imagining this in a linux/bsd context, where modifying your TCP stack and recompiling is fairly trivial. Given the prevalence of Linux-based routers, a firmware upgrade could provide a router with a new stack and a proxy service that users could use for their high bandwidth applications. However, if ISPs go with this as their primary means of congestion control, I&#8217;d bet on seeing a Windows-only alternative in the spirit of winpcap very soon.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

