US Cable Support > Comcast HSI > Comcast is using Sandvine to manage P2P Connections

reply to NormanS

Re: Comcast is using Sandvine to manage P2P Connections

As an entrepreneur as well as someone who has a lot of experience in the Computer Services industry I must say the customer is not always right.

That's a very common saying among customers, especially difficult ones, but it just wouldn't make sense to do business with that assumption.

Its easy to say that a big company should bend down towards the customer and satisfy them no matter the cost, but we are not given access to their cost structure or network limitations so we don't know how big their sacrifices would be if they did give unlimited bandwidth.

I am sure Comcast would rather piss off the top 1% of its bandwidth hogs or even bully them into downloading less than risk losing 25% or 50% of its less consuming customers to competing services because their connections are running too slow because of the bandwidth hogs (afterall, they all pay the same monthly bill so its easier to rid of 1% of your customers than 50%).

The point is the customer is not always right and in my field (computer repair) the customer is very seldom right (If I could have a nickel for every customer who insisted the problem is the hard drive or motherboard when it was just a case of limewire downloaded spyware or for every customer who insists that their hardware warranty should cover virus removal I'd have my own OC3 line by now).

With that said, I agree that bandwidth limits should be posted so that people don't live in fear of the dreaded letter or phone call. The bandwidth limits should also be high enough so that casual users who like YouTube and download some movies (Amazon.com's Unbox service movies are as much as 2GB each) don't come dangerously close to or over the limit on a consistent basis. I myself fear getting into trouble with Comcast in the future even though I am a new subscriber and don't have the service hooked up yet which would be alleviated if I just knew the limit.

With the internet increasingly being multimedia I am in shock that bandwidth limits or caps today are the same as they appear to have been in 2002 or 2003 when posts online first started appearing about them since SO MUCH has changed since then on the internet especially in the direction of everything taking up more bandwidth.

As far as people always downloading just under their cap to avoid being terminated while it is a valid concern there are work arounds.

They could introduce what some universities do for their access as in the first 100GB are your regular speed and the more you download after that the slower your speed gradually gets which minimizes the impact your downloads after that speed have on other users.

(Ex. first 100GB are downloaded at rated speed of 8mbps, the next 25GB are 4mbps, the next 25 are 1.5mbps, and everything after that is 768kbps - a speed which should not dent users around you).

This would be favorable to just terminating users.

reply to NormanS

reply to Sadimitsu

reply to Qumahlin

reply to slovokia

reply to NormanS
Upon reflection, I do not wish to post. (my point was was covered by another poster)

reply to funchords

Yep I'm confused as well.

After reading this thread i fired up utorrent, and with and without encryption i was able to upload to a single peer at about 230 KBytes per second for at least 5-10 minutes, then changed to encrypted, and had the same exact result. During this time i consistently received 1MByte per second from the lone seeder uninterrupted.

Based on how much torrenting i do (150-300GB a month) I just have not seen anything like what is being suggested in this thread

I wonder if these are just regional issues that affect mostly those on busy nodes or something.

reply to jjoshua

Like I hope I mentioned at the top of the thread, BitTorrent seems to be the least affected overall of the protocols that I tested. I was able to hit and maintain my top requested speed and number of connections with BitTorrent. However, in reviewing the packets I received using Comcast vs. non-Comcast, the number of RST-driven drops was multitudes higher with Comcast.

With Sandvine, the goal isn't to prevent P2P. The goal is to reduce the cost of your P2P connections. If Sandvine can cause your client to drop an expensive connection, your client will seek a new connection -- and hopefully find one that is either within the Comcast network or one that takes a less expensive or congested route outside of the network.

Tip: For some reason, the injected RST triggers the WINSOCK error 10053, which is (Connection Aborted by local software) and not the 10060 (Connection Reset by Peer.) So if you're not looking at packets, but you are looking at logs from your P2P client -- look for 10053.

Edit: I see that I didn't mention that BitTorrent seemed the least affected of the protocols that I tested. In my tests: Gnutella uploading was completely stopped. ED2K uploading was heavily affected. And BitTorrent uploading was the least affected. Interestingly, that list tends to inversely follow the current popularity of each protocol.

--
Robb Topolski -= funchords.com =- Hillsboro, Oregon USA
~ Keeper of the D-Link FAQ ~ Did you Search? ~ More features, Free! Join BBR! ~

reply to kaila

reply to NormanS

reply to gregbot

reply to funchords
Hi Funchords,

Thanks for your observations as well!

I have not been able to test any more since I have left Comcast and switched to DSL. However I saw bittorrent connections being ripped down during active seeding - i.e. the leecher was not being choked at the time.

I would also like to point out that it seems clear that these limitations do NOT seem to affect all Comcast customers uniformly. I have seen other Comcast seeders behave the same way when I was their leecher.

What is interesting is that if I disabled encryption the seeding TCP connections seemed to be terminated instantly. With encryption enabled they would be terminated after 30 seconds or so. I did not test using other P2P programs or random upload TCP streams.

Has anyone tried configuring their firewall to block incoming RST packets? While this may lead to a lot of stale TCP connections hanging around until they time out (typical timeouts are 5-10 minutes), it may alleviate some of the problems Robb has reported. Alternatively, if the bogus RST packets could somehow be characterized (e.g. empty message body), then perhaps the firewall could be configured to block only these types of RST packets.

I guess the next question is whether or not there are any software firewalls with sufficient flexibility to allow this type of filtering?