dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
319923
FreakyOne
join:2007-07-07
Stuart, FL

FreakyOne to NormanS

Member

to NormanS

Re: Comcast is using Sandvine to manage P2P Connections

Your suggestion is actually quite good as far as the bandwidth hogs are concerned... it would certainly make up for the loss of Recording Industry, Gaming and Movie Industries as well. Maybe they should band together and develop their own Broadband company and make a system like this so they wont care if movies or CD's or Games are transferred via the net .. they would be making too much dough to worry about that. It would also save on attorney fees. I dont believe in the agreement that is posted on that link so i am certain i wont be a customer of Comcast for long. It would make a difference if the Customer Service dept. actually admitted to something along the terms of this topic but they dont admit nor do they have to admit to this or any other kind of filtering of "Comcast" bandwidth. If i were to operate my business like this on a retail level i wouldn't last long. First rule of thumb is "The Customer Is Always Right". For those businesses that don't buy into this philosophy they wont last very long. Or maybe they are just too big for their own good and don't care about their customers. At least individually.
gregbot
join:2007-07-09
Chicago, IL

2 edits

1 recommendation

gregbot

Member

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.

jjoshua
Premium Member
join:2001-06-01
Scotch Plains, NJ

jjoshua to NormanS

Premium Member

to NormanS
said by NormanS:

said by jjoshua:

When you send a document via FedEx, do they open the package, look at the document, decide if the contents are 'acceptable' and make modifications to it? Of course not.
I wasn't aware that Sandvine modified the contents of the data being downloaded. Only that it used the contents in making a decision on packet priority.
From the OP...

- The interruption is accomplished by sending a perfectly forged TCP packet (correct peer, port, and sequence numbering) with the RST (reset) flag set. This packet is obeyed by the network stack or operating system which drops the connection.

Sounds like it to me...

funchords
Hello
MVM
join:2001-03-11
Yarmouth Port, MA

funchords to Sadimitsu

MVM

to Sadimitsu
said by Sadimitsu:

It's sure blocking me! I didn't notice it untill yesterday but I can't seed anything on bittorrent now. My ratios are horrible and now I will be banned etc etc. It's not even a slow upload, I really can't seed torrents AT ALL. I get a fat 0 kB/s.
That is not my experience at all (I started this thread, and I started it with data.) Something else is probably going on with your situation -- but your experience and my experience are not the same.
funchords

funchords to Qumahlin

MVM

to Qumahlin
said by Qumahlin:

This thread is going to garner hate towards sandvine because everyone is basing one users experiences to how things will always work and assuming Sandvine is something installed specifically to block/throttle p2p...that is not the case
No hate from me about using the technology, but the users need to be let in on it, so that we can get support when we need it.

Whoever adjusts these things has made it impossible to upload files on Gnutella. Every _single_request_ is met with an injected RST packet that drops the connection (as of about 6 weeks ago, when I last tested this). ED2K uploads are dropped a majority of the time, but there some uploading does occur. BitTorrent seems to be the least affected (see my results at the top of this thread).

How do I report this to Comcast Support, who is trained to respond that Comcast does not filter P2P?

IMHO, P2P is low-priority, passive internet use. If a customer is installing a QoS router at his house, P2P is always the thing that gets the last priority. I don't mind that Comcast uses the same prioritization as anyone else would use, but I do mind not being able to upload at all (on Gnutella) and not being able to do anything about it.
funchords

funchords to slovokia

MVM

to slovokia
said by slovokia:

I've done some more observations and reached the following conclusions. If you attempt seeding with bittorrent using encryption, Comcast will tear down the TCP connection after 30 seconds or so. I think the seeding limit is time based not bandwidth based. The heuristic appears to be if Comcast sees a TCP connection established that involves only sending data from a subscriber to another host, that connection is terminated after 30 seconds or so. I'd imagine this limit would affect any TCP flow which cannot be recognised as being "good".
Thank you!!!! Great observations.

Something for you to be aware of, and check if you feel so inclined: 30 seconds is also the slot time for a BitTorrent "Optimistic Unchoke." My tests showed that they did not send the RST during an actual data transfer, but during the more passive conversation that happens while the peers are CHOKED. During this time, BitTorrent sends HAVE and NOOP messages. And the time between the start of the first transmission, and the point where that transmission is stopped by a CHOKE message, happens to be 30 seconds.

Wireshark should be able to confirm that for you, and a great program to use is Azureus -- it seems to have the best logs for diagnostics like this.
funchords

1 edit

funchords to NormanS

MVM

to NormanS
Upon reflection, I do not wish to post. (my point was was covered by another poster)
kaila
join:2000-10-11
Lincolnshire, IL

kaila to funchords

Member

to funchords
said by funchords:

said by slovokia:
....The heuristic appears to be if Comcast sees a TCP connection established that involves only sending data from a subscriber to another host, that connection is terminated after 30 seconds or so. I'd imagine this limit would affect any TCP flow...
Thank you!!!! Great observations....
Sorry I'm confused now... Does this effect only p2p/bt connections or *any* TCP based connection (uploading photos to print labs, online backup sites, ftp sites, etc.)?

confused too
@comcast.net

confused too

Anon

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
gregbot
join:2007-07-09
Chicago, IL

gregbot

Member

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

NormanS
I gave her time to steal my mind away
MVM
join:2001-02-14
San Jose, CA
TP-Link TD-8616
Asus RT-AC66U B1
Netgear FR114P

NormanS to jjoshua

MVM

to jjoshua
said by jjoshua:

From the OP...

- The interruption is accomplished by sending a perfectly forged TCP packet (correct peer, port, and sequence numbering) with the RST (reset) flag set. This packet is obeyed by the network stack or operating system which drops the connection.

Sounds like it to me...
Where is the "content" that is being modified? I take "content" to be the content of the file, not the packet header details.

Cabal
Premium Member
join:2007-01-21

Cabal

Premium Member

said by NormanS:
said by jjoshua:

From the OP...

- The interruption is accomplished by sending a perfectly forged TCP packet (correct peer, port, and sequence numbering) with the RST (reset) flag set. This packet is obeyed by the network stack or operating system which drops the connection.

Sounds like it to me...
Where is the "content" that is being modified? I take "content" to be the content of the file, not the packet header details.
While I'm the first to support any form of traffic shaping to get the best utilization out of one's network, it's kind of tough to argue that man-in-the-middle attacks, which are what these RST injections are, are appropriate ways to control bandwidth. I wouldn't be surprised if it was a misconfiguration issue, though. I'm seeding successfully now with no issues, as usual.

funchords
Hello
MVM
join:2001-03-11
Yarmouth Port, MA

1 edit

funchords

MVM

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.
funchords

funchords to kaila

MVM

to kaila
said by kaila:
said by funchords:
said by slovokia:
....The heuristic appears to be if Comcast sees a TCP connection established that involves only sending data from a subscriber to another host, that connection is terminated after 30 seconds or so. I'd imagine this limit would affect any TCP flow...
Thank you!!!! Great observations....
Sorry I'm confused now... Does this effect only p2p/bt connections or *any* TCP based connection (uploading photos to print labs, online backup sites, ftp sites, etc.)?
My testing was specific to P2P protocols, and my own experience is that Comcast is not interrupting TCP connections simply based on larger outgoing ratios. I think Slovokia's conclusion was incorrect, but his 30 second observation is on the right track as it applies to BitTorrent.
funchords

funchords to NormanS

MVM

to NormanS
said by NormanS:
said by jjoshua:

From the OP...

- The interruption is accomplished by sending a perfectly forged TCP packet (correct peer, port, and sequence numbering) with the RST (reset) flag set. This packet is obeyed by the network stack or operating system which drops the connection.

Sounds like it to me...
Where is the "content" that is being modified? I take "content" to be the content of the file, not the packet header details.
Without arguing semantics, your understanding is correct.

In the RFCs, the use of the RST flag was never intended to be changed enroute. It was intended for the endpoints of a connection to avoid a lingering open TCP socket condition when connectivity was interrupted. So there is alteration, but not of the payload.

However, it is unexpected to have an RST flag on a data packet, and it is unclear in the RFCs what the receiver is supposed to do with the data payload at that point.

I did notice that empty (no data payload) RST packets were also received, apparently forged to appear that it came from the endpoint.

In short, the RST TCP/IP flag is being modified on some data packets. Also, in some cases a packet is forged to appear like it came from the endpoint with the RST flag set.
funchords

1 edit

funchords to gregbot

MVM

to gregbot
said by gregbot:

I wonder if these are just regional issues that affect mostly those on busy nodes or something.
I'm wondering that, too.

Sandvine was designed for the network gateways -- where Comcast meets the backbone or other non-Comcast peers. It follows that it would apply not to the local nodes, but to the perimeter of the Comcast network (affecting everyone). But given the vastness and fragmentation of the Comcast network (given the acquisitions), I am wondering if there is a more regional implementation.

Unfortunately, I can only test from here.
slovokia
join:2005-01-31
Belmont, CA

slovokia to funchords

Member

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.

funchords
Hello
MVM
join:2001-03-11
Yarmouth Port, MA

funchords

MVM

said by slovokia:

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.
(in my case, after the CHOKE). But I definitely remember seeing something to that effect, too -- encrypted connections lasted longer, but I did not dig deeper to characterize it. I remember wondering at the time if it had anything to do with how encryption was negotiated in the handshake. My goal at the time, however, was just to record under what conditions RST interference happened.

Anonymous Coward
@tttmaxnet.com

Anonymous Coward

Anon

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?

NormanS
I gave her time to steal my mind away
MVM
join:2001-02-14
San Jose, CA
TP-Link TD-8616
Asus RT-AC66U B1
Netgear FR114P

NormanS

MVM

said by Anonymous Coward :

I guess the next question is whether or not there are any software firewalls with sufficient flexibility to allow this type of filtering?
The two non-Windows firewalls I worked with could filter by TCP, or UDP, by IP address and by port number; but I don't recall that either could check for RST packets.

I haven't played with the Windows firewall. My router firewall can't check that low.

Cabal
Premium Member
join:2007-01-21

Cabal to Anonymous Coward

Premium Member

to Anonymous Coward
said by Anonymous Coward :

Has anyone tried configuring their firewall to block incoming 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?
I have not (since I haven't seen this behavior), but any of the UNIX-based firewalls can filter using TCP header, as can OS X (FreeBSD's ipfw), and I'm sure any of the enterprise-grade hardware firewalls. It can probably be done with the Linux-based Linksys routers through the commandline interface. I'd be interested to hear of any others.

anonymim
@comcast.net

anonymim

Anon

If anybody figures out how to try this firewall filtering with a DD-WRT firmware-flashed Linksys, please post instructions here. I'm about to get kicked off several **legal** (live-music-sharing) torrent trackers for my piss-poor ratio.

no oper
@comcast.net

no oper to Anonymous Coward

Anon

to Anonymous Coward
said by Anonymous Coward :

Has anyone tried configuring their firewall to block incoming RST packets?
Yes!
On linux, if you're using a static port for bittorrent, the following command drops incoming reset packets to that port.
iptables -A INPUT -p tcp --dport PORTNUMBERHERE --tcp-flags RST RST -j DROP
 

I also noticed, that bit 6 of the IP TOS field was set on all these reset packets.
As per the ipv4 rfc, bit 6 is "Reserved for future use". tcpdump shows these packets with
tcpdump -n "ip[1] & 0xff == 0x40"
 
Since that field is not in use, tcpdump should never show any packets with that filter. But it does on comcast! Could someone else on comcast plese verify that they can see these too?

iptables 1.3.5
tcpdump version 3.9.4
libpcap version 0.9.4
linux 2.6.20.1

Anon
@comcast.net

Anon to funchords

Anon

to funchords
Can anyone tell if the RSET packets are sent in both directions, to the comcast user and the other peer, or just to the comcast users?

funchords
Hello
MVM
join:2001-03-11
Yarmouth Port, MA

funchords to Anonymous Coward

MVM

to Anonymous Coward
said by Anonymous Coward :

Has anyone tried configuring their firewall to block incoming RST packets?
Yes, I tried this with linux iptables, and got really excited when it seemed to thwart the problem. But then I realized that the connections were dead, but they simply weren't being removed from the active list.

I believe this means that the RST is sent both ways. The response to an RST is not a FIN so the TCP/IP stack doesn't know the connection has been dropped.

Good thinking, though.
said by no oper :

I also noticed, that bit 6 of the IP TOS field was set on all these reset packets.
I hadn't noticed. They could have been set, or not. Are you directly connected? -- or could your router be adding that bit for use on the LAN?

no oper
@comcast.net

no oper

Anon

said by funchords:

I hadn't noticed. They could have been set, or not. Are you directly connected? -- or could your router be adding that bit for use on the LAN?
I'm not directly connected, there's a router on the way, but this bit is set only on the reset packets I'm receiving on the bittorrent connections and nowhere else.

Descent
Wrap It Up
Premium Member
join:2000-11-10
Hoboken, NJ

Descent to funchords

Premium Member

to funchords
I'm not sure if this is related, but I've been having some really crappy luck with seeding torrents as of late. I was away for about a month earlier in the summer and just returned home about a week ago.

Since returning home, I haven't been able to seed a torrent for the life of me, and whenever I have my bit torrent application open (Azureus) on either of my 3 different computers (wired or wireless, UPnP, regular port forwarded, DMZ host you name it i've tried it) I get a considerable amount of packet loss in general as I've tested for hours pinging speakeasy speed test locations with Azureus open and with it closed from every computer on my network.

I have been reconfiguring and testing and doing everything I can think of trying to get a torrent to seed but even leaving Azureus open anymore makes it a pain to even surf the web or maintain a stable connection to MSN messenger. I'm getting 20% packet loss on average with Azureus open on any one of my PC's. The highest I've been able to seed in the past week is like 300B/s...and i don't even think its actually seeding the file (probably just advertising it to the tracker).

I have gone to work with Azureus open back home, and from my laptop at work I've watched my desktop sign on and off MSN about 3 times per minute for an entire work day. Guess what the results were with Azureus closed... no drops whatsoever.

I am absolutely stumped as to why I cant seed and why I get horrible packet loss only when Azureus is open. Are the bit torrent days over? What if I must use a bit torrent client for something legit? Say.. one of Blizzard's world of warcraft patches. Torrents aren't all bad and i don't see how comcast can completely shut them down like this.

koitsu
MVM
join:2002-07-16
Mountain View, CA
Humax BGW320-500

koitsu to funchords

MVM

to funchords
said by funchords:

I believe this means that the RST is sent both ways. The response to an RST is not a FIN so the TCP/IP stack doesn't know the connection has been dropped.
Correct . See the below stateful diagram (PDF):

»www.cse.iitb.ac.in/perfn ··· diag.pdf

funchords
Hello
MVM
join:2001-03-11
Yarmouth Port, MA

1 edit

funchords to Descent

MVM

to Descent
said by Descent:

Are the bit torrent days over? What if I must use a bit torrent client for something legit? Say.. one of Blizzard's world of warcraft patches. Torrents aren't all bad and i don't see how comcast can completely shut them down like this.
I read your whole post -- and you're certainly seeing something different than what I have observed. For example, I never had any packet loss, and I can seed torrents at full speed -- even while Comcast is resetting certain connections.

Someone else has pointed out that things might be different in different parts of the country, but your story sounds more like upload saturation to me. To test this, set Azureus to 16 KB/s upload limit running on one of your computers. If the symptoms go away, then your problem was upload saturation. Your router/modem was getting data faster than it could put it on the line.

telcolackey5
The Truth? You can't handle the truth
join:2007-04-06
Death Valley, CA

3 edits

telcolackey5

Member

Question:

1) How important is your upload file sharing ability. i.e. are you very concerned that the world must download from your PC 7x24 while you are not using your computer?

2) How much of your non-copywrited content is in high demand that would help your P2P ratio?