<?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: A TCP stack swapout solves nothing</title>
	<atom:link href="http://rdist.root.org/2008/03/24/a-tcp-stack-swapout-solves-nothing/feed/" rel="self" type="application/rss+xml" />
	<link>http://rdist.root.org/2008/03/24/a-tcp-stack-swapout-solves-nothing/</link>
	<description>Embedded security, crypto, software protection</description>
	<lastBuildDate>Sat, 18 May 2013 22:28:08 +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/24/a-tcp-stack-swapout-solves-nothing/comment-page-1/#comment-4515</link>
		<dc:creator><![CDATA[Nate Lawson]]></dc:creator>
		<pubDate>Fri, 28 Mar 2008 17:54:34 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.wordpress.com/?p=121#comment-4515</guid>
		<description><![CDATA[Ben C: thanks for the response and hi w0zz!

You&#039;re right that the IP address does not need to be examined to implement RED.  I added that in to show that all a user&#039;s connection could still be grouped (i.e. WRED) and RED did not have to be blind.  I expected people to argue RED alone wasn&#039;t a solution since it wouldn&#039;t allow differentiated service.  I wrote about WRED in my second post before I saw your comment but you&#039;re definitely right.]]></description>
		<content:encoded><![CDATA[<p>Ben C: thanks for the response and hi w0zz!</p>
<p>You&#8217;re right that the IP address does not need to be examined to implement RED.  I added that in to show that all a user&#8217;s connection could still be grouped (i.e. WRED) and RED did not have to be blind.  I expected people to argue RED alone wasn&#8217;t a solution since it wouldn&#8217;t allow differentiated service.  I wrote about WRED in my second post before I saw your comment but you&#8217;re definitely right.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ben C</title>
		<link>http://rdist.root.org/2008/03/24/a-tcp-stack-swapout-solves-nothing/comment-page-1/#comment-4504</link>
		<dc:creator><![CDATA[Ben C]]></dc:creator>
		<pubDate>Thu, 27 Mar 2008 04:39:04 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.wordpress.com/?p=121#comment-4504</guid>
		<description><![CDATA[Quote:
    So they certainly can implement RED based on IP address since that only requires looking at the header, not the contents of the TCP stream. Even if high-end users have multiple IP addresses, those can be grouped into a common pool based on PPPoE/RADIUS login information.

The equipment does not need to examine the IP header, or to group a user with multiple IP addresses. With (W)RED packets are dropped probabilistically. The more packets a user sends the higher the probability that one of their packet will be dropped. It doesn&#039;t matter if they have multiple IP addresses or not.

Quote:
    As long as ISPs want to charge per-application instead of per-user rates, all these proposals are pointless. RED allows an ISP to over-subscribe the gateway and enforce fairness among users. They can even give users that pay extra more bandwidth by assigning them a more favorable drop ratio. But RED doesn’t discriminate how that bandwidth is used, so ISPs will continue deploying equipment that does discriminate, no matter what George Ou or Bob Briscoe say.

The ISPs can use WRED (Weighted RED) to have different drop probabilities for different classes of traffic based on QoS marking. The QoS marking can be based off of the applications that the users are using. With WRED the service providers should have the control that you state they want. It does allow them to discriminate how the bandwidth is used.]]></description>
		<content:encoded><![CDATA[<p>Quote:<br />
    So they certainly can implement RED based on IP address since that only requires looking at the header, not the contents of the TCP stream. Even if high-end users have multiple IP addresses, those can be grouped into a common pool based on PPPoE/RADIUS login information.</p>
<p>The equipment does not need to examine the IP header, or to group a user with multiple IP addresses. With (W)RED packets are dropped probabilistically. The more packets a user sends the higher the probability that one of their packet will be dropped. It doesn&#8217;t matter if they have multiple IP addresses or not.</p>
<p>Quote:<br />
    As long as ISPs want to charge per-application instead of per-user rates, all these proposals are pointless. RED allows an ISP to over-subscribe the gateway and enforce fairness among users. They can even give users that pay extra more bandwidth by assigning them a more favorable drop ratio. But RED doesn’t discriminate how that bandwidth is used, so ISPs will continue deploying equipment that does discriminate, no matter what George Ou or Bob Briscoe say.</p>
<p>The ISPs can use WRED (Weighted RED) to have different drop probabilities for different classes of traffic based on QoS marking. The QoS marking can be based off of the applications that the users are using. With WRED the service providers should have the control that you state they want. It does allow them to discriminate how the bandwidth is used.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: w0zz</title>
		<link>http://rdist.root.org/2008/03/24/a-tcp-stack-swapout-solves-nothing/comment-page-1/#comment-4499</link>
		<dc:creator><![CDATA[w0zz]]></dc:creator>
		<pubDate>Tue, 25 Mar 2008 16:19:38 +0000</pubDate>
		<guid isPermaLink="false">http://rdist.wordpress.com/?p=121#comment-4499</guid>
		<description><![CDATA[While his prescription may be off, it&#039;s nice to see someone with a soapbox making the case that there *IS* a problem to be solved.  The loudest voices on this issue assume bad intentions on the part of Comcast and others and dismiss the technical concerns as distractions from the free speech concerns - of which there are very few actual examples.  We need more folks who understand the technical issues making more noise.]]></description>
		<content:encoded><![CDATA[<p>While his prescription may be off, it&#8217;s nice to see someone with a soapbox making the case that there *IS* a problem to be solved.  The loudest voices on this issue assume bad intentions on the part of Comcast and others and dismiss the technical concerns as distractions from the free speech concerns &#8211; of which there are very few actual examples.  We need more folks who understand the technical issues making more noise.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
