I agree, they have been doing this in select locations for some time. I live in Atlanta and have seen this happening for about the 3 months, but I have friends in the suburbs that have (or had) no issues. I imagine they have been deploying their traffic shaping in more and more headends. Here is some actual operational details: It is reported that Comcast is using an application from Sandvine to throttle BitTorrent traffic. Sandvine breaks every (seed) connection with new peers after a few seconds if it's not a Comcast user. This makes it virtually impossible to seed a file, especially in small swarms without any Comcast users. Some users report that they can still connect to a few peers, but most of the Comcast customers see a significant drop in their upload speed. The throttling works like this: A few seconds after you connect to someone in the swarm the Sandvine application sends a peer reset message (RST flag) and the upload immediately stops. Most vulnerable are users in a relatively small swarm where you only have a couple of peers you can upload the file to. Only seeding seems to be prevented, most users are able to upload to others while the download is still going, but once the download is finished, the upload speed drops to 0. Some users also report a significant drop in their download speeds, but this seems to be less widespread. Worse on private trackers, likely that this is because of the smaller swarm size Although BitTorrent protocol encryption seems to work against most forms of traffic shaping, it doesn't help in this specific case. Comcast is making no effort to determine if the traffic they are blocking is legal or not. No one blocks all web traffic because some sites have illegal content or questionable/undesired material. Personally I think this is inappropriate behavior for an ISP and I hope it causes a mass exodus of Comcast customers. -Scott -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Clinton Popovich Sent: Friday, October 19, 2007 3:02 PM To: 'Steven M. Bellovin'; nanog@nanog.org Subject: RE: Comcast blocking p2p uploads This is old news man, that's been happening for at least 3 months now. Clinton Popovich Systems Administrator Nauticom Internet Services - An NPSI Company 2591 Wexford-Bayne Road, Suite 400 Sewickley, PA 15143 Tel: 724-933-9540 Fax: 724-933-9888 Email: crpopovi@nauticom.net Web: http://www.nauticom.net -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Steven M. Bellovin Sent: Friday, October 19, 2007 2:51 PM To: nanog@nanog.org Subject: Comcast blocking p2p uploads http://www.nytimes.com/aponline/technology/AP-Comcast-Data-Discrimination. ht ml http://www.nytimes.com/aponline/technology/AP-Comcast-Data-Discrimination- Te sts.html Not a lot more I can say, other than argghhh! --Steve Bellovin, http://www.cs.columbia.edu/~smb

In a message written on Fri, Oct 19, 2007 at 03:21:09PM -0400, Joe Provo wrote:

Content is irrelevent. BT is a protocol-person's dream and an ISP nightmare. The bulk of the slim profit margin exists in taking advantage of stat-mux oversubscription. BT blows that out of the water.

I'm a bit confused by your statement. Are you saying it's more cost effective for ISP's to carry downloads thousands of miles across the US before giving them to the end user than it is to allow a local end user to "upload" them to other local end users? Is this only a biproduct of the centralized downloads being throttled by thousands of miles of network, and/or a single centralized server? -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org

In a message written on Sat, Oct 20, 2007 at 07:12:35PM -0500, Joe Greco wrote:

...

In a message written on Fri, Oct 19, 2007 at 03:21:09PM -0400, Joe Provo wr= ote:

...

Content is irrelevent. BT is a protocol-person's dream and an ISP nightmare. The bulk of the slim profit margin exists in taking=20 advantage of stat-mux oversubscription. BT blows that out of the=20 water.

I'm a bit confused by your statement. Are you saying it's more cost effective for ISP's to carry downloads thousands of miles across the US before giving them to the end user than it is to allow a local end user to "upload" them to other local end users?

It's quite possible that I've completely missed it, but I hadn't seen many examples of P2P protocols where any effort was made to locate "local" users and prefer them. In some cases, this may happen due to the type of content, but I'd guess it to be rare. Am I missing some new development?

Most P2P clients favor the "faster" sources. Faster is some sort of combination of lower latency and/or higher bandwidth. This tends to favor local clients, however can be quickly skewed by other factors.

If it isn't being transferred locally, then the ISP is being stuck with the pain of carrying a download thousands of miles, probably from a peering (or worse, transit) with another ISP that has also had to carry it some distance.

But back the the original premise. If say, Linux is being distributed both from a central web site, and via P2P: 1) Central web site. All but the one ISP with the web site will have the traffic going over peering or worse transit, and will often be carrying them thousands of miles from the central point. 2) P2P. Has a good chance at least some seeders will be on the same network, avoiding peering and transits for some fraction of the traffic. Has a good chance the seeders are closer to the user than the web site, perhaps even on the same cable segment. I think the more interesting thing here is overall rate limit. Let's compare a central web site with a 1Gbps connection for 10,000 downloaders, or a P2P model where there are 10,000 downloaders, 5,000 of which are willing to serve content (obviously starting with 1-5 seeders, and slowly growing as people download it. Even if provers only offer 1Mbp/sec of upload, those 5,000 content providers can put an aggregate 5Gbps into the network, where as the central server can only put a aggregate 1Gbps into the network. So, while the bit*mile cost may be lower in the P2P case, the peek bit rate is higher (which users like, faster downloads); and since ISP's are forced to size their network for peak rate to insure user satisfaction the "cost" of P2P is higher, even though the bit mile cost is lower. I think. At least, that's my guess from Joe's statement, I'd like him to elaborate. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org

On 10/22/07, Andy Davidson <andy@nosignal.org> wrote:

In the UK at least, option 1) is financially more favourable for ISPs, since the data flow is vendor -> transit -> last mile -> end user, rather than end user -> last mile -> last mile -> end user.

The last mile is where all the costs are.

Andy

Of course, bitstream and l2tp backhaul lend more complexity to the whole thing; the efficiency maximising behaviour for clients is exactly the opposite, as p2p traffic between local peers gets both a) tromboned up to the ISP's pop and back down again, and b) charged for per bit by BT/whoever. In fact, you want p2p content to come in from the 'net because it only transits BT's wires once... I can't think of an obvious way for a p2p client to detect this.

I can't think of an obvious way for a p2p client to detect this.

Work through middleboxes installed in the ISP's network and configured by the ISP. --Michael Dillon

On Tue, Oct 23, 2007, Alexander Harrowell wrote:

Good idea, but there's a trust issue. If I were Comcast I might configure the box to lie about our backhaul network in order to spork the p2pers.

.. as compared to whats going on now? Hm, Azureus seems to have deprecated their JPC support due to "lack of ISP support." Did anyone try the commercial JPC stuff out? What did you think? Does anyone still have a copy lying about? Adrian

I remember from the early days that ISPs meant the web to be just another kind of tv with you as a consumer and them as the provider. They were happy to NAT and to change your IPv4 address so you could not run servers for ftp or http. Some of them even hand out rfc 1918 addresses ... They were worried about VoIP and tried to stop it. They are worried about everything new. They think all users are children and try to block everything that is not meant for the kindergarden. UUCP is still there. With telefone flatrates I guess some people have already built there own little internets. A 14.4 modem can be as fast as 57.2 with big brother listening at both ends. You need only half the hardware because you never heard of CALEA and it is a problem of the phone company in the first place. I remember companies I worked for, who first moved from netware to tcp/ip and then even started interconnecting. Only when universities started connecting to us did we see the internet and had to renumber of course. I remember how our /etc/hosts was suddenly growing - no, we did not know DNS but some of us used IEN116 clients and servers. Ok - not all of them - only those who see all the money and dont know how to provide. The other side of the coin - a lot of people connected to us. We never asked their names. They connected on weekends or late at night. They rarely did big downloads, mostly uucp emails. And software was free. Enough ranting. Cheers Peter and Karin -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.arl.pirates http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ http://www.cesidianroot.com/

Forgot the links =P http://www.wired.com/software/webservices/news/2007/08/p2p http://www.dcia.info/documents/P4P_Overview.pdf Keith O'Neill wrote:

Actually Pando does try to localize traffic as much as possible. Not only that we have started the P4P Working Group.

Keith

Pando Networks

See link below

Joe Greco wrote:

...

...

In a message written on Fri, Oct 19, 2007 at 03:21:09PM -0400, Joe Provo wr= ote:

...

Content is irrelevent. BT is a protocol-person's dream and an ISP nightmare. The bulk of the slim profit margin exists in taking=20 advantage of stat-mux oversubscription. BT blows that out of the=20 water.

I'm a bit confused by your statement. Are you saying it's more cost effective for ISP's to carry downloads thousands of miles across the US before giving them to the end user than it is to allow a local end user to "upload" them to other local end users?

It's quite possible that I've completely missed it, but I hadn't seen many examples of P2P protocols where any effort was made to locate "local" users and prefer them. In some cases, this may happen due to the type of content, but I'd guess it to be rare. Am I missing some new development?

If it isn't being transferred locally, then the ISP is being stuck with the pain of carrying a download thousands of miles, probably from a peering (or worse, transit) with another ISP that has also had to carry it some distance.

... JG

Leo Bicknell wrote:

...

I'm a bit confused by your statement. Are you saying it's more cost effective for ISP's to carry downloads thousands of miles across the US before giving them to the end user than it is to allow a local end user to "upload" them to other local end users?

Not to speak on Joe's behalf, but whether the content comes from elsewhere on the Internet or within the ISP's own network the issue is the same: limitations on the transmission medium between the cable modem and the CMTS/head-end. The issue that cable companies are having with P2P is that compared to doing a HTTP or FTP fetch of the same content you will use more network resources, particularly in the upstream direction where contention is a much bigger issue. On DOCSIS 1.x systems like Comcast's plant, there's a limitation of ~10mbps of capacity per upstream channel. You get enough 384 - 768k connected users all running P2P apps and you're going to start having problems in a big hurry. It's to remove some of the strain on the upstream channels that Comcast has started to deploy Sandvine to start closing *outbound* connections from P2P apps.

That's part of it, certainly. The other problem is that I really doubt that there's as much favoritism towards "local" clients as Leo seems to believe. Without that, you're also looking at a transport issue as you shove packets around. Probably in ways that the network designers did not anticipate. Years ago, dealing with web caching services, there was found to be a benefit, a limited benefit, to setting up caching proxies within a major regional ISP's network. The theoretical benefit was to reduce the need for internal backbone and external transit connectivity, while improving user experience. The interesting thing is that it wasn't really practical to cache on a per-POP basis, so it was necessary to pick cache locations at strategic locations within the network. This meant you wouldn't expect to see a bandwidth savings on the internal backbone from the POP to the aggregation point. The next interesting point is that you could actually improve the cache hit rate by combining the caches at each aggregation point; the larger userbase meant that any given bit of content out on the Internet was more likely to be in cache. However, this had the ability to stress the network in unexpected ways, as significant cache-site to cache-site data flows were happening in ways that network engineering hadn't always anticipated. A third interesting thing was noted. The Internet grows very fast. While there's always someone visiting www.cnn.com, as the number of other sites grew, there was a slow reduction in the overall cache hit rate over the years as users tended towards more diverse web sites. This is the result of the ever-growing quantity of information out there on the Internet. This doesn't map exactly to the current model with P2P, yet I suspect it has a number of loose parallels. Now, I have to believe that it's possible that a few BitTorrent users in the same city will download the same Linux ISO. For that ISO, and for any other spectacularly popular download, yes, I would imagine that there is some minor savings in bandwidth. However, with 10M down and 384K up, even if you have 10 other users in the city who are all sending at full 384K to someone new, that's not full line speed, so the client will still try to pull additional capacity from elsewhere to get that full 10M speed. I've always seen P2P protocols as behaving in an opportunistic manner. They're looking for who has some free upload capacity and the desired object. I'm positive that a P2P application can tell that a user in New York is closer to me (in Milwaukee) than a user in China, but I'd quite frankly be shocked if it could do a reasonable job of differentiating between a user in Chicago, Waukesha (few miles away), or Milwaukee. In the end, it may actually be easier for an ISP to deal with the deterministic behaviour of having data from "me" go to the local upstream transit pipe than it is for my data to be sourced from a bunch of other random "nearby" on-net sources. I certainly think that P2P could be a PITA for network engineering. I simultaneously think that P2P is a fantastic technology from a showing- off-the-idea-behind-the-Internet viewpoint, and that in the end, the Internet will need to be able to handle more applications like this, as we see things like videophones etc. pop up. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

Who are we to say what is illegal traffic... I mean they could be downloading anything from p2p not just mp3's.. don't get me wrong I HATE WoW but it uses bittorrent to decentralize its updates. Clinton Popovich Systems Administrator Nauticom Internet Services - An NPSI Company 2591 Wexford-Bayne Road, Suite 400 Sewickley, PA 15143 Tel: 724-933-9540 Fax: 724-933-9888 Email: crpopovi@nauticom.net Web: http://www.nauticom.net -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of John C. A. Bambenek Sent: Friday, October 19, 2007 3:11 PM To: Steven M. Bellovin Cc: nanog@nanog.org Subject: Re: Comcast blocking p2p uploads I love how the framed it as "data discrimination". Let's just be honest... 99% of it was illegal traffic taking up far more than their fair share of bandwidth. On 10/19/07, Steven M. Bellovin <smb@cs.columbia.edu> wrote:

http://www.nytimes.com/aponline/technology/AP-Comcast-Data-Discrimination.ht ml

http://www.nytimes.com/aponline/technology/AP-Comcast-Data-Discrimination-Te sts.html

Not a lot more I can say, other than argghhh!

--Steve Bellovin, http://www.cs.columbia.edu/~smb

John C. A. Bambenek wrote:

Well, as far as I'm concerned WoW can burn and get blocked with the rest of the bad traffic because they are externalizing their maintenance costs on others. They should pay for the bandwidth to update their own software.

Actually, one could say they offload some of the maintenance cost to their subscribers in order to keep subscription prices down. Many subscribers to WoW don't seem to mind this at all and find updates much easier to handle than other MMOs. If the ISP is losing money for selling bandwidth they don't have or below the cost they pay, is it really the fault of the gaming company or the customer? The real issue always seems to end up with the ISP wanting to say they give X bandwidth, yet they really don't. Should all the high band video sites also be shut down? There really is no problem in filtering traffic or shaping it to manageable volumes. Just make sure the customer is aware of it. If the service doesn't meet their needs, they can go elsewhere. Jack Bates

John C. A. Bambenek wrote:

I love how the framed it as "data discrimination". Let's just be honest... 99% of it was illegal traffic taking up far more than their fair share of bandwidth.

With the remaining 1% being Linux ISOs. I wonder what happens to these network police appliances (Sandvine, Packeteer etc) when the P2Ps implement encryption and tunnel it all over 443/tcp?

For anyone who is not aware this Comcast issue does have a solutions and its called iptables. works great for those behind either the great firewall of china or the great firewall of Comcast. http://redhatcat.blogspot.com/2007/09/beating-sandvine-with-linux-iptables.h tml Clinton Popovich Systems Administrator Nauticom Internet Services - An NPSI Company 2591 Wexford-Bayne Road, Suite 400 Sewickley, PA 15143 Tel: 724-933-9540 Fax: 724-933-9888 Email: crpopovi@nauticom.net Web: <http://www.nauticom.net/> http://www.nauticom.net From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Mark Owen Sent: Friday, October 19, 2007 4:01 PM To: Mike Lewinski Cc: nanog@nanog.org Subject: Re: Comcast blocking p2p uploads On 10/19/07, Mike Lewinski <mike@rockynet.com> wrote: With the remaining 1% being Linux ISOs. I wonder what happens to these network police appliances (Sandvine, Packeteer etc) when the P2Ps implement encryption and tunnel it all over 443/tcp? They'll just monitor for streams that utilize large portions of bandwidth for extended amounts of time and throttle all. -- Mark Owen

This solution is only partially effective because Comcast's Sandvine deployment sends a farced RST packet to both sides of the connection. The solution linked below drops the RST packet on your firewall keeping the connection from being torn down as far as your client is concerned, but it is not very likely that the other end will have this as well. This is not to say it can't help. Using HTTPS on the tracker and data encryption also help. So does any kind of tunneling including tor or DNS/icmp tunneling, but these have some level of performance impact that may be undesirable. -Scott _____ From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Clinton Popovich Sent: Friday, October 19, 2007 4:49 PM To: 'Mark Owen'; 'Mike Lewinski' Cc: nanog@nanog.org Subject: RE: Comcast blocking p2p uploads For anyone who is not aware this Comcast issue does have a solutions and its called iptables. works great for those behind either the great firewall of china or the great firewall of Comcast. http://redhatcat.blogspot.com/2007/09/beating-sandvine-with-linux-iptables .html Clinton Popovich Systems Administrator Nauticom Internet Services - An NPSI Company 2591 Wexford-Bayne Road, Suite 400 Sewickley, PA 15143 Tel: 724-933-9540 Fax: 724-933-9888 Email: crpopovi@nauticom.net Web: <http://www.nauticom.net/> http://www.nauticom.net

I recommend using ip-over-dns http://dnstunnel.de/ If they are really that smart I'd laugh at them killing DNS Cheers Peter and Karin Mark Owen wrote:

On 10/19/07, *Mike Lewinski* <mike@rockynet.com <mailto:mike@rockynet.com>> wrote:

With the remaining 1% being Linux ISOs.

I wonder what happens to these network police appliances (Sandvine, Packeteer etc) when the P2Ps implement encryption and tunnel it all over 443/tcp?

They'll just monitor for streams that utilize large portions of bandwidth for extended amounts of time and throttle all.

-- Mark Owen

-- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.arl.pirates http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ http://www.cesidianroot.com/

On Oct 19, 2007, at 3:10 PM, John C. A. Bambenek wrote:

I love how the framed it as "data discrimination". Let's just be honest... 99% of it was illegal traffic taking up far more than their fair share of bandwidth.

I didn't know that you doing something illegal with your application made it OK to block my use of it. Also, what _is_ my "fair share of bandwidth"? -- TTFN, patrick P.S. I am making absolutely no judgement on whether block is good or bad. Just wondering how other people rationalize doing, or not doing, these types of things.

On 10/19/07, Steven M. Bellovin <smb@cs.columbia.edu> wrote:

...

http://www.nytimes.com/aponline/technology/AP-Comcast-Data- Discrimination.html http://www.nytimes.com/aponline/technology/AP-Comcast-Data- Discrimination-Tests.html

Not a lot more I can say, other than argghhh!

--Steve Bellovin, http://www.cs.columbia.edu/~smb

On Fri, 19 Oct 2007, Patrick W. Gilmore wrote:

Also, what _is_ my "fair share of bandwidth"?

And therein lies the rub of statistical multiplexing. It's possible to come up with some ballpark fair-use numbers, but those numbers could be twisted into just about anything, depending on who is doing the twisting :) jms

On Fri, Oct 19, 2007, Randy Bush wrote:

...

I didn't know that you doing something illegal with your application made it OK to block my use of it.

p2p protocols are illegal? since when?

p2p protocols are tools. like most tools, they can be used for good and for bad.

Where good and bad suddenly aren't moral/ethical questions, but financial questions.. (Hi from "Clients are used to traffic shaping!" land.) Adrian

On 10/19/07, John C. A. Bambenek <bambenek@gmail.com> wrote:

I love how the framed it as "data discrimination". Let's just be honest... 99% of it was illegal traffic taking up far more than their fair share of bandwidth.

And 84% of statistics are made up on site. If it is illegal it is not your right to judge and punish. We have courts for that. As for limiting my bandwidth, if you have a problem with my usage you should state it in a policy and not discreetly forge RST packets. -- Mark Owen

On 10/19/07, John C. A. Bambenek <bambenek@gmail.com> wrote:

Since when did private companies no longer have the right to regulate their own property?

I must have missed the Amendment...

(Yeah, ok, I exaggerated the 99%)

It's not a matter of them not being able to do what they want, it is their lines after all, as it is more along doing it in a manner that is a little more civil. Sending RST packets in ongoing streams is just down right rude and I dare say a form of forgery. -- Mark Owen

On Fri, Oct 19, 2007 at 04:38:11PM -0400, Clinton Popovich wrote:

Its not that they are not permitted to control network traffic, but they are impersonating the other server and I have a feeling there are a few laws that could fall under. Like fraud for one.

Not to defend Comcast, but I think that this is a pretty far-fetched idea. Firewalls that send RSTs, nearly every IDP device, SYN-proxy DDoS mitigation are just a few of the widely deployed technologies that depend on the exact same forgeries. It's all more-or-less the same principle of doing just enough forgery to be able to interrupt a flow. If you really want around that, IPSec is always there for ya. -- Ross Vandegrift ross@kallisti.us "The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell." --St. Augustine, De Genesi ad Litteram, Book II, xviii, 37

On 10/19/07, Patrick Giagnocavo <patrick@zill.net> wrote:

On Oct 19, 2007, at 3:42 PM, John C. A. Bambenek wrote:

...

Since when did private companies no longer have the right to regulate their own property?

I must have missed the Amendment...

If you want to make a property argument, how do you explain them denying me my right to enjoy my rental of their property?

If Comcast were a landlord, they would be interfering with my quiet enjoyment and my rights in possession.

I'm finding the thread interesting with respect to the devices, how they work, how we might be able to identify them, and why this is a bad idea as related to the engineering and/or operation; capex, opex, O&M, etc. We already know that the givens are that it's generally socially unacceptable to filter, but without Comcast's motivation being know, it's hard to speculate as to the "why" they did it. Let's not. If we can drop the politics and legalities, I think we have a winner. Best Regards, Martin Hannigan NANOG MLC Member

On Oct 19, 2007, at 7:16 PM, Sean Figgins wrote:

You ever wonder why some places have cable modem but not DSL? That's usually because the telcos can't get the bandwidth there.

That is a laughable statement.

In many places there is no real ability to tag the voice traffic with a higher class service, so it has to contend just like everyone else.

This is also a laughable statement as Comcast (the provider in question) has at least, DOCSIS 1.1 on all parts of their network, if not newer than that. The DOCSIS 1.1 specification has this capability (multiple service flows). DOCSIS 1.1 is of April 1999 vintage. rest of your post also questionable. --Patrick

Frank Bulk wrote:

2) DSL and fiber have limitations, too. The modulation and spectrum width can vary, but most MSOs have their forward configured with a maximum of around 38 Mbps (256-QAM, 6 MHz wide) and the return in the 9 Mbps range (64-QAM, 3.2 MHz wide). Charts here: Forward: http://www.cable360.net/images/articles/15131_1168455349.gif Return: http://www.cable360.net/images/articles/15131_1168455396.gif

Thank you, Frank. I'm not a HFC engineer, but rather an IP/Network/Server/Security guy, that worked on the backbone and lab side of a large MSO. My HFC experience is exclusive of what is between the CMTS and the cable modem. I know just enough to be able to live there. I got my figures reversed. For some reason I was thinking that it was about 100 meg on the upstream and 45 meg on the downstream, but looks like I remembered it wrong. Anyways, regardless of that, you pretty much validated what I was saying as to the reason why a MSO would deploy such a device. It's possibly cheaper to do so than to deploy the hardware to split the HFC pland and increase available bandwidth to subscriber ratio. Not that I agree with such a practice. -Sean

On Oct 19, 2007, at 10:53 PM, John C. A. Bambenek wrote:

Because you signed up to an AUP that allows what they are doing.

That, and in most states, if you rent my house, I can throw you out for no reason given that I give you proper notice and enough time.

In this case, if you want to use rental analogies, that's like saying a landlord can't evict you or otherwise take action because you're having loud parties and throwing appliances out windows. P2P is about the exact opposite of "quiet enjoyment".

I am afraid your skill at analogies is lacking. First, in most states, you may NOT "throw [me] out for no reason". Well, unless you consider "proper notice and enough time" equivalent to "wait until the end of the lease". Second, eviction is totally different than the discussion here. Comcast is still taking these people's "rent", an evicted tenant does not pay. Third, the _police_ handle loud parties and vandalism, not the landlord. Etc., etc. But the analogy is flawed anyway. A cable modem is not an apartment, and the Internet does not fit well into "normal" modes of operation. If the AUP does not allow this activity, then Comcast has remedies detailed in their AUP. I have not read the AUP, and it is late, so I will not do so now. However, would you care to take a bet about the remedies listed? I would guess it gives Comcast the right to shut down the service. I seriously doubt it gives Comcast the right to randomly kill sessions while still billing the full month's rent. -- TTFN, patrick P.S. Careful how far you defend this action lest your own words be turned against you.

On 10/19/07, Patrick Giagnocavo <patrick@zill.net> wrote:

...

On Oct 19, 2007, at 3:42 PM, John C. A. Bambenek wrote:

...

Since when did private companies no longer have the right to regulate their own property?

I must have missed the Amendment...

If you want to make a property argument, how do you explain them denying me my right to enjoy my rental of their property?

If Comcast were a landlord, they would be interfering with my quiet enjoyment and my rights in possession.

Interfering with my traffic rather than blocking it, could lose them common carrier protection. They are exerting editorial control, in a fashion, over what I transmit and receive.

--Patrick

On Fri, 19 Oct 2007, John C. A. Bambenek wrote:

Since when did private companies no longer have the right to regulate their own property?

I don't know that anyone would disagree with their right to do so, but if there are usage limits, those limits should be made known to the user community. I'm sure Comcast has ways to communicate TOS updates to their user base - mass email, stuff a letter in peoples' cable bills, etc... How would you react if you were pulled over for speeding on a road that had no posted speed limit? jms

Communication of rules is fair... I was criticizing the "net neutrality" argument. They should communicate the rules, I agree. On 10/19/07, Justin M. Streiner <streiner@cluebyfour.org> wrote:

On Fri, 19 Oct 2007, John C. A. Bambenek wrote:

...

Since when did private companies no longer have the right to regulate their own property?

I don't know that anyone would disagree with their right to do so, but if there are usage limits, those limits should be made known to the user community. I'm sure Comcast has ways to communicate TOS updates to their user base - mass email, stuff a letter in peoples' cable bills, etc...

How would you react if you were pulled over for speeding on a road that had no posted speed limit?

jms

I was hearing complaints about this months ago... Regards Marshall On Oct 19, 2007, at 3:20 PM, Patrick W. Gilmore wrote:

On Oct 19, 2007, at 2:50 PM, Steven M. Bellovin wrote:

...

http://www.nytimes.com/aponline/technology/AP-Comcast-Data- Discrimination.html http://www.nytimes.com/aponline/technology/AP-Comcast-Data- Discrimination-Tests.html

Not a lot more I can say, other than argghhh!

"Argghhh" that they are doing it?

Or "argghhh" that people are just now figuring it out?

And did you "arrgghhh" when rate limiting became commonplace about, oh, 1865? :)

-- TTFN, patrick

Curtis Doty wrote: [..]

It would be sad if one of the leaders in deploying IPv6 was now motivated to maintain the status-quo; with its IPv4 RST meddling "feature". :-(

Which "Leaders in deploying IPv6"? They are only deploying IPv6 for their management infrastructure, thus internally and not for their customers. Just to show how 'deployed' it is: http://www.sixxs.net/tools/grh/dfp/arin/ Prefix: 2001:558::/32 Name: COMCAST6NET Allocated: 2003-01-06 Seen: *NEVER* That stuff is the same PR crap as Verizon with: http://money.cnn.com/news/newsfeeds/articles/prnewswire/NYTU05725092007-1.ht... Note the: "The deployment, expected to be completed during the next 18 months, will permit companies to fully integrate to IPv6,..." Nice PR, but no cheese yet, but at least now they are pretty much committed to actually do it ;) Really, don't claim that something is deploying IPv6 until you see "IPv6" as a feature on the product pages and you can actually really get it and traceroute it globally... As for the RST's, this just shows again that things like IPSEC or otherwise protected packet sending are the way to go and ISP's show not be stating that you have "unlimited traffic" but simply provide the user with a real limit. Then it is clear what you are buying and when you go over that limit THEN limit the endpoint to 5kbit/s so that they at least can go to the "you reached your limit, do your leeching next month". And I am pretty sure that technically simply ratelimitting (or simply shutting them down completely or sending them to a sandbox) after they hit the traffic limit is much more efficient than trying to figure out what is and what is not "illegal" or "bulky" traffic. It is only complicating the wee job that an ISP really have to do: gain nothing. Greets, Jeroen

Sean Figgins wrote:

Eric Spaeth wrote:

...

With rate-shaping they would need to have the P2P identification widget in-line with the data path to be able to classify and mark traffic so that it can be queued/throttled appropriately.

The Sandvine, in particular, is designed to be placed in-line like this. It does, however, deploy a technology to shunt the traffic through the device in the event that the server craters. Many network devices do this now. I have previous experience with Sitara QoS devices that sported that same feature. The problem was that the relay would only shut if the box lost power or if it received a software command to disengage. We had numerous problems where the packet processing engine would become overwhelmed and lock up; the relay stayed engaged because the box retained power and the software driver was rendered useless once the whole OS locked up.

Maybe it's just me, but when a vendor is concerned enough about their box failing that they work out these elaborate bypass options it doesn't inspire a lot of confidence in the stability of the product. IMHO, wedging a 99.5% available piece of hardware between your 99.99+% available network hardware is just bad karma. -Eric

At 07:36 AM 10/20/2007, William Allen Simpson wrote:

Mikael Abrahamsson wrote:

...

I cannot access relevant pages on www.comcast.com due to me not being in the US (or rather, they require an address first), could anyone please paste or other way supply the wording/text they use in their fineprint, to allow them contractually to disrupt customer TCP session in other way than delaying or dropping the packets (which I guess is accepted industry standard). Sending/spoofing RST on certain customer TCP sessions doesn't qualify as normal network behaviour in my mind, so would be interesting to hear how they word it legally. They don't, Comcast is egregiously in violation of their own AUP!

http://www.comcast.net/terms/use.jsp

It is interesting to note that the terms of service given on comcast.com say nothing about restrictions on use. I make the distinction between comcast.net and comcast.com for an important reason: comcast.com is where folks go to sign up. Comcast.net is a portal for existing users. In other words, it appears this AUP is not posted (at least not that I could find) on the sales-oriented page. Does the user actually agree to this AUP prior to signing a commitment with Comcast? Of course the AUP starts with the usual big-business text (popular with credit card companies too) that says the company is free to make any adjustments to the AUP at any time. In all the years I've been a Comcast customer at home, I don't recall any notices about changes to the terms of service. The credit card companies at least tell you, and advise if you don't agree you can cancel your account.

On Oct 20, 2007, at 4:08 AM, Mikael Abrahamsson wrote:

On Fri, 19 Oct 2007, Steven M. Bellovin wrote:

...

http://www.nytimes.com/aponline/technology/AP-Comcast-Data- Discrimination.html

I cannot access relevant pages on www.comcast.com due to me not being in the US (or rather, they require an address first), could anyone please paste or other way supply the wording/text they use in their fineprint, to allow them contractually to disrupt customer TCP session in other way than delaying or dropping the packets (which I guess is accepted industry standard).

Sending/spoofing RST on certain customer TCP sessions doesn't qualify as normal network behaviour in my mind, so would be interesting to hear how they word it legally.

It is interesting that this has come up before in a somewhat related context http://www.schneier.com/blog/archives/2006/06/ignoring_the_gr.html Regards Marshall

-- Mikael Abrahamsson email: swmike@swm.pp.se