This is a good point too. Comcast has refused to define what exactly their
limits are so assuming all the content is legal, how does a law abiding
citizen know when he is over his limits?
-Scott
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
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.htm
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
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
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.
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
Steven M. Bellovin wrote:
Not a lot more I can say, other than argghhh!
You have a residential bandwidth offering with a price point that is possible because of massive oversubscription that is in violent competition with a technology that aims to make use of all that "idle" network capacity at each subscriber end-point. This is one of those issues where people like to play both sides; you have massive outbursts of moral outage that an ISP would engage in throttling activities, and an equal outburst when things like usage-based billing get discussed. No matter how you slice it, there are costs involved in moving bits and as a provider you either need to level the playing field by throttling people to reasonable consumption or be able to differentially bill those who insist on generating massive traffic loads. Of course, the challenge is that due to current limitations in access technologies (both cable and DSL) many broadband ISPs couldn't accommodate some of these traffic loads even if people are willing to pay.
It's worth noting that the traffic Comcast is filtering is called out in their Terms of Use in the "PROHIBITED USES AND ACTIVITIES" section, paragraph xiv. http://www.comcast.net/terms/use.jsp
-Eric
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
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
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
Mark Owen 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.
Which seems completely fair and reasonable to me, and likely won't require very expensive layer 4-7 packet shapers either. Plus they can just state that flat limit in their contract and NANOG will issue a collective yawn.
It just seems to me that the more Sandvine type applications are deployed, the sooner we will burn that bridge out from under us.
Then again, I saw the first Packeteer in action nearly 3 years ago and predicted it would only take 6-9 months before encryption became widespread.
Let's be honest. The US ISPs have been advertising "unlimited" service, but heavily oversubscribe to limit costs. The expectation is that users will only use the bandwidth rarely and in short bursts. We all know all about over subscription, but it is now problematic due to distributed applications.
Blocking heavy users (or terminating them, as at least one cellular/wireless Internet service provider does to heavy users of its "unlimited" service) is false advertising. but it seems to be accepted all around, without so much as an asterisk and footnote.
So it all comes down to what the definition of "unlimited" is. Truth in advertising and all that. There seems to be a great unwillingness to tell the truth in our society.
Steven M. Bellovin wrote:
Personally, I see a big difference between rate-shaping and sending
RSTs. (I suppose you could view RSTs as allocating 0 bps, but that's
not a helpful distinction.)
I see a big difference as well.
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. This means that overall network availability would now be tied to a device that isn't really a proven piece of network hardware. To send TCP resets, on the other hand, all that is needed is a span session to the inspection probe to let it determine which connections to shutdown and issue the resets completely out of band. If the inspection probe kacks, everything on the network continues to function and only the P2P throttling functionality would be impacted.
As a network engineer focused on availability, I have a very clear preference in implementation.
-Eric
I recommend using ip-over-dns
If they are really that smart I'd laugh at them killing DNS
Cheers
Peter and Karin
Mark Owen wrote:
Patrick W. Gilmore 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?
It's one thing to traffic shape someone... It's quite another to meddle
in the packets that they send. people are willing to tolerate
transparent http proxies because they got good enough that their use was
non-invasive. As a comcast customer I am aware that I am purchasing an
asymetric service, there are is however a reason I got 8/768 and not 6/384.
What happens when they decide my non-comcast voice or video conferencing
service needs to be asymmetric instead of symmetric as well?
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
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.
Clinton Popovich wrote:
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
The resets are sent in both directions, so that would only work if everybody who uses BT filters reset packets (not likely). That solution does have the added benefit that it will likely break other applications though.
-Eric
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
Eric Spaeth wrote:
It's worth noting that the traffic Comcast is filtering is called out in their Terms of Use in the "PROHIBITED USES AND ACTIVITIES" section, paragraph xiv. http://www.comcast.net/terms/use.jsp
That section could be applied to every application that you would run on your computer that access the Internet. The "program, equipment or servers... that provide network content or any other services" clause is really quite laughable. Clearly, this would apply to every p2p application out there, but it would also apply to many other, such as video conference, net meeting, online games, remote access to your PC (VNC/RDP/goto-my-pc), AIM, IRC, etc. I'm sure it probably could be applied to every possible IP aware application.
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.
-Sean
(Please respond only to the list)
Martin Hannigan wrote:
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.
It's not at all hard to imagine WHY. In fact, it's almost a given.
1) Comcast is an MSO. As such, their access (last mile) is over a coax or a HFC plant.
2) HFC has limitations on bandwidth. The frequencies that most MSOs use for data give it somewhere around a DS3's worth of return traffic. The forward traffic (to the customer) is greater.
3) The HFC plant almost always includes at least a few thousand customers per leg. These customers have to share the same return bandwidth.
4) With only 45 meg of return traffic, and a few thousand customers, it is pretty easy to see how a few high capacity customers could have a negative impact on the rest of the customers.
In addition to this, you have other applications, such as voip, that rides this same infrastructure. 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.
You can add to this that in some markets, the only real bandwidth is via multiple T1 or DS3 due to it being more remote. You ever wonder why some places have cable modem but not DSL? That's usually because the telcos can't get the bandwidth there. Right or not, many MSOs will turn up markets on a handful of T1 circuits until they can get a DS3 or greater installed.
As to the SPECIFIC reason why Comcast is deploying the Sandvine instead of another architecture, or using another method of rate limiting... Well, I could probably comment on that as well, but I'm uncertain that my friends and associates at the MSOs and hardware vendors would look kindly on that. Since I no longer work for a MSO, I really no longer have any insight.
It's just a way that an MSO might manage their network in order to make 90% or more of their customers happy while reducing the need to deploy more hardware to split the plants.
-Sean