--=-=-= Content-Transfer-Encoding: quoted-printable "Edmund Cramp" <[EMAIL PROTECTED]> writes:
> Basically ADSL is hardware limited to about 20kB/s out so with ADSL the > supplier can figure out exactly what their upstream bandwidth limits are > (worst case) - given the relatively low stream rate they can allow > (tolerate?) users to run servers without putting a lot of overhead into > "terms enforcement". A "connect and forget" installation is cheaper to > setup and maintaine than a "connect and enforce" installation. Cable has a similar "hard" limitation on the upstream. The upstream bandwidth available to a given cable segment (node or group of nodes) works out to a max of about 10mbps. Of course this is shared so providers have to work out a formula to figure out typical amount of homes per segment. Grow too much, they've got to chop up the segment and recombine -- which can get expensive. So the argument (one of anyway) they give is that heavy upstream users skew their math. The strategy of blocking ports is a "fire and forget" dumb strategy. They believe they'll get the majority of the server users this way and save the bandwidth (I've been on conference calls where this was said). Policy enforcement is largely impossible. It's only done when there is a complaint. Complaints usually come in the form of DMCA warning letters from the RIAA, SBA and the like. Providers are obligated to respond to these. If you're an abuse@ account for a cable ISP, you're gonna get a ton of these things ;) (I was). Email form letter warning to customer, try and explain it to them when they call since it's usually their kid, lather, rinse, repeat. I actually measured upstream bandwidth utilization per day at one point during my tenure with Charter using Cisco netflow tools (ie. standard stuff). What I found was that 95%+ of all upstream utilization was due to kazaa, morpheus, etc. ports 80, 25, and 22 were all below 1%. 21 was roughly 2%. The rest was probably Outlook virus related ;). That P2P stuff doesn't fall under the 'no servers' policy so 'no servers' and port blocking gains them nothing in real terms. I shared this up to regional and higher staff (I was in charge of LA). I made pretty graphs from netflow aggregators demonstrating this over many months on the cable systems in Alabama (a much larger sample). These were ignored.=20=20 My argument was and is that they need to restructure their pricing and bill users for overage provided there is ample warning, clearly stated policies, and an online way for users to view their usage stats. Furthermore getting in to the game of blocking ports creates unnecessary complication. Just sell the pipe. Perhaps offer port blocking services as a value add to those who request it. This is all doable. I could make a lot of money implementing the tools for a willing vendor ;). =2D-=20 Scott Harney<[EMAIL PROTECTED]> "...and one script to rule them all." gpg key fingerprint=3D7125 0BD3 8EC4 08D7 321D CEE9 F024 7DA6 0BC7 94E5 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA+ib3Z8CR9pgvHlOURAjYyAJ9YfWBV5mUtw4Lq4umZMb8G59LsLQCeNbMN Xn5ILVMVyMzr8jCoQWM+p2o= =kXwG -----END PGP SIGNATURE----- --=-=-=--
