<?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"
	>
<channel>
	<title>Comments on: ISP vs. BitTorrent</title>
	<atom:link href="http://cubist.cs.washington.edu/Security/2008/02/16/isp-vs-bittorrent/feed/" rel="self" type="application/rss+xml" />
	<link>http://cubist.cs.washington.edu/Security/2008/02/16/isp-vs-bittorrent/</link>
	<description></description>
	<pubDate>Sun, 12 Oct 2008 19:55:18 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: sky</title>
		<link>http://cubist.cs.washington.edu/Security/2008/02/16/isp-vs-bittorrent/#comment-1615</link>
		<dc:creator>sky</dc:creator>
		<pubDate>Mon, 18 Feb 2008 23:59:42 +0000</pubDate>
		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/2008/02/16/isp-vs-bittorrent/#comment-1615</guid>
		<description>This Tracker Peer Obfuscation business has an element to its encryption that we do not hear about in class. We learn about integrity/privacy/authenticity/availability, but here we have a totally new concept. This TPO stuff is masking patterns about the sender/receiver of the packets. This might only be the begging of a whole new series of encryption schemes that place less value on the information being sent, and more value on the anonymity of the sender and receiver.</description>
		<content:encoded><![CDATA[<p>This Tracker Peer Obfuscation business has an element to its encryption that we do not hear about in class. We learn about integrity/privacy/authenticity/availability, but here we have a totally new concept. This TPO stuff is masking patterns about the sender/receiver of the packets. This might only be the begging of a whole new series of encryption schemes that place less value on the information being sent, and more value on the anonymity of the sender and receiver.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kurifodo</title>
		<link>http://cubist.cs.washington.edu/Security/2008/02/16/isp-vs-bittorrent/#comment-1504</link>
		<dc:creator>kurifodo</dc:creator>
		<pubDate>Mon, 18 Feb 2008 06:56:44 +0000</pubDate>
		<guid isPermaLink="false">http://cubist.cs.washington.edu/Security/2008/02/16/isp-vs-bittorrent/#comment-1504</guid>
		<description>I am someone who is of the position that ISPs should not be allowed to throttle traffic in this manner.  When signing up for service, they do not make it clear that this kind of behavior is carried out, and when it was first implemented, they did not warn customers or differentiate between "good" and "bad" torrenters.

So they would like to limit BitTorrent traffic so that overall internet experiences for everyone are smoother, but it seems to me, we are paying for an experience that is just being cut short of what it really ought to be.  This is wrong.  Comcast and other ISPs who do throttling should instead consider investing in upgrading their lines to increase bandwidth.  What ever happened to serving the customer and putting them first?</description>
		<content:encoded><![CDATA[<p>I am someone who is of the position that ISPs should not be allowed to throttle traffic in this manner.  When signing up for service, they do not make it clear that this kind of behavior is carried out, and when it was first implemented, they did not warn customers or differentiate between &#8220;good&#8221; and &#8220;bad&#8221; torrenters.</p>
<p>So they would like to limit BitTorrent traffic so that overall internet experiences for everyone are smoother, but it seems to me, we are paying for an experience that is just being cut short of what it really ought to be.  This is wrong.  Comcast and other ISPs who do throttling should instead consider investing in upgrading their lines to increase bandwidth.  What ever happened to serving the customer and putting them first?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
