dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
58

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

1 edit

koitsu to funchords

MVM

to funchords

Re: Comcast is using Sandvine to manage P2P Connections

I wanted to take a moment to address the never-ending battle regarding the " don't allow servers" clause in customer TOS.

Almost every provider I've used (and that's quite a few, across different states as well) has had that clause, and it pretty much describes what I like to refer to as a "common sense" scenario -- which is, you can't do things like run an FTP server, an HTTP/HTTPS server, yadda yadda. It isn't a clause that says "you can't run a program that listens on a port" (which is what many people claim the TOS refers to - see below). It's the fact that they don't want you pushing tons of upstream traffic (that is, traffic from your PC to another user; e.g. other user is downloading data from you), because they're very likely billed on a 95th-percentile use on their circuits.

Here's some common applications that you use every day that *do* listen on a port (and most have never taken the time to figure out why or what purpose it serves):

* AIM -- when client A sends client B a file, client A listens on a dynamically-allocated port which client B connects to
* ICQ -- identical to AIM, but in reverse (the recipient opens the listening port, negotiates, then individual sending the file connects to that)
* IRC DCC -- same methodology as AIM
* MSN Messenger/Windows Live Messenger -- same methodology for AIM, and also does the same for Remote Assistance, Voice Chat, Webcam, and games
* Remote Desktop (Microsoft Terminal Services) -- listens on TCP port 3389
* SSH server -- TCP port 22
* SSH tunnelling -- usually binds the listener to 127.0.0.1, but that's entirely up to the tunnel configuration
* Yahoo Messenger -- same methodology as AIM

Comcast doesn't consider your use of these protocols as you "running a server". BitTorrent clients (as described by n2f See Profile) work the exact same way as above. Thus, I grow tired of people arguing "BitTorrent makes you violate your TOS 'cuz it listens on a port!", because there's a bazillion other protocols that are fair-use that work the exact same way.

The clause is about upstream bandwidth usage, plain and simple.

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 koitsu:

I wanted to take a moment to address the never-ending battle regarding the " don't allow servers" clause in customer TOS.
...
...
The clause is about upstream bandwidth usage, plain and simple.
As somebody who runs an MTA, an IM client, and a BiTorrent client, I can assure you that the BT client uses far more of my upstream bandwidth than anything else I run, even my MTA. I suspect that Comcast cares less about whether their customers run low up B/W consumers, such as MTAs and IMs, than they do about high up B/W consumers; and BT tops that list.

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

1 edit

koitsu

MVM

said by NormanS:

I suspect that Comcast cares less about whether their customers run low up B/W consumers, such as MTAs and IMs, than they do about high up B/W consumers; and BT tops that list.
I completely agree with your statement, but it induces a question about Comcast's practises from a bandwidth utilisation perspective. Here's what I mean:

We all know that Comcast is concerned about bandwidth usage, particularly a) heavy upstream use, and b) extremely heavy downstream use. Comcast doesn't disclose what the bandwidth limits are (a separate problem, but let's save that for another thread), but regardless, they're concerned about usage. When BBR or the press or anyone asks them about the bandwidth concerns, Comcast's response is always the same: "we're trying to hinder the minority who are bandwidth hogs". Fair enough -- I have no qualms with that, and I support it.

However, injecting falsified packets (which is, point blank, a form of man-in-the-middle attack) hurts those who aren't responsible for Comcast's concerns in the first place. Now every time I see a TCP connection that gets reset, for any reason, I'm going to be asking myself "did I really send the RST? Did the remote end really send it? Or is Comcast injecting packets again?" The fact that sequence numbers are properly forged makes it (for me) even more uncomfortable. There's now *no way* to effectively determine who sent what.

So I'm trying to figure out exactly what Comcast's line of thinking is here.

Honestly, it seems to me that they need something that (ideally) is very simple: a real-time way to monitor all of their customers' network usage (such as being able to monitor network I/O on a CMTS head, etc.), down to the individual coax/port/whatever that identifies a customer, and then spawn an alert or a "FYI" notice to whoever at Comcast shuts these customers off or sends letters to them demanding their usage be curbed -- something more real-time than what they have already.

Otherwise I'm left to believe that the Sandvine is intended for other purposes yet to be deployed (or discovered).

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 koitsu:

So I'm trying to figure out exactly what Comcast's line of thinking is here.
Comcast is first, and foremost, a TV entertainment provider. I would not be surprised if P2P is targeted on behalf of some cozy relationship with **AA companies. Protecting the interests of the **AA would, in the long run, benefit Comcast.

Considering corporate statements from AT&T, and their betting the bank on U-Verse, I wonder if they are just holding back to see how things work out, PR-wise, for Comcast.

The bottom line seems to be that the **AA owns the U.S. Congress, and the hardware manufacturers; and they are so big that Bill Gates quakes before them. (Microsoft DRM, and all that goes with it.)

When did the Hellers(¹) get so much power over us? We need to stuff them back into their pink tights.

NOTE¹: From the movie, "Heller in Pink Tights", based on the Louis L'Amour western novel, "Heller with a Gun". Refers to an old west term applied to the actors in traveling troupes, "heller". Acting was, once upon a time, a dubious profession, about two steps removed from the world's oldest. When did actors and actresses become more respectable than lords and ladies; and more powerful than kings and queens?

SpaethCo
Digital Plumber
MVM
join:2001-04-21
Minneapolis, MN

SpaethCo

MVM

said by NormanS:

said by koitsu:

So I'm trying to figure out exactly what Comcast's line of thinking is here.
Comcast is first, and foremost, a TV entertainment provider. I would not be surprised if P2P is targeted on behalf of some cozy relationship with **AA companies. Protecting the interests of the **AA would, in the long run, benefit Comcast.
I started out thinking that as well, but Comcast's actions thusfar don't seem to support that position. If they were really interested in curbing P2P from that aspect they would most likely start mitigating download traffic as well as upload. This really looks like they're trying to find a way to control upstream traffic to buy them some time until they can relieve contention with DOCSIS 3.0.

Without managing the exception traffic through something like their current solution, the only way they're going to be able to get around this is to do something they've never done before: bandwidth reduction (though somewhat counterbalanced with Powerboost).

-Eric