[c-nsp] BCP for save B/W when transit links are full

[Ted Mittelstaedt]

"sharing" music files and porno is illegal by federal standards, and
also just about everywhere (I think maybe only 2-3 countries in the world
haven't signed off on the Berne convention)  Porno shots invariarbly
are copyrighted material so even the legal porno is illegal to "share"
Of course amateur porn is legal and unencumbered by copyrights - but
there is very little amateur porn worth looking at on the Internet,
anyone doing it who has any kind of body at all is charging money for
it, and thus they don't allow redistribution.  I don't know if it's
embarassment or whatever, but we have never had any kind of pushback
from a user we've caught distributing porno and threatened to shut
down if they didn't abide by copyright and knock it off.

The heavy p2p users are heavy simply because they are illegally
sharing copyrighted material.  While p2p can be used to share
content that is created by the users, nobody generally gives a
damn about user-created content so that is never bandwidth consumptive.
It doesen't take a rocket scientist to run kazza and view a directory
listing of an open server and see "starwars.mpg" and figure out
what is going on.

It is impossible to write a contract that PERMITS illegal activity,
we don't even have to explicitly disallow file sharing, the infraction
is covered in the general contract boilerplate.

As for rate-limiting, I wouldn't go down that path.  What is
important/legal
in one person's eyes isn't so in anothers, such a judgement call would
be highly arbitrary and undoubtedly would backfire.  Anyway, as I've
said several times, p2p isn't a bandwidth problem.  What is the bandwidth
problem is p2p that is used to share pirated stuff.

As for the technical end of it, that is easy.  ALL our DSL users are
STATICALLY numbered.  (in fact, all of our users are bridged, not PPPoE)
We have various processes we run periodically to discover if someone
has decided to use an IP address that doesen't belong to them, and
such behavior gets them kicked off the network, until they call in
complaining that their DSL isn't working and we give them a tongue
lashing.  (figuratively, of course)  Of course, most of our DSL users
assume that they are dynamically numbered, this farce is aided and
abetted by the fact that we use DHCP on our DSL bridges and all our
new user documentation implies that they are dynamically
numbered.  (They actually are, for about 24 hours after they first
plug in, then we capture their MAC and move them to their real number)
Since all the national providers make a big hue and cry about charging
extra money for static IP numbers, people have grown accustom to
the assumption that unless they are paying extra, their IP address
is dynamic.

The nature of DSL is such that new users screw around with it for
a week or so after they first turn it on, from then on if everything
is working they are contented to leave things be.  You would think
that tying IP addresses to the MAC would mean for constantly changing
MACs but in reality the inertia of "leave it the fuck alone it's working"
means that there is actually very few changes that happen.  This is
helped even further by the fact that all DSL modems that the ILECS
we use supply today have NATS in them, and come out of the box with NAT
on,
so the user's DSL MAC address only changes if their modem goes tits up.

Since all our customers are statically numbered, it makes it very easy
to view the bridge list and see who the heavy users are.  What is
also helpful is that both MPAA and RIAA have constant programs
running to identify and shut down illegal p2p and quite often we
get the notices from them even before we identify the (ab)users
ourselves.

Honestly, this stuff really isn't rocket science.  What you have to
do though is quit thinking like a user when you engineer your DSL
network.  Unlearn, unlearn!!  Too many ISPs out there have DSL
backends that were designed with moronic assumptions - like the
ass-umption that somehow, dynamically numbering your DSL network
"saves you IP numbers"  And the assumption that even if this were
true, that it's something you as an ISP would think is a good thing.

Ted

>-----Original Message-----
>From: Kim Onnel [mailto:karim.adel at gmail.com]
>Sent: Tuesday, August 30, 2005 3:56 AM
>To: Ted Mittelstaedt
>Cc: Cisco-NSP Mailing List
>Subject: Re: [c-nsp] BCP for save B/W when transit links are full
>
>
>I am more interested with the technical part of doing this, but, are
>you supposed to just give them the connectivity and they do anything
>with it as long as it doesnt break their contract, or are you
>authorized to rate limit anything on their traffic that u dont see as
>(important/legal) ?
>
>On 8/30/05, Ted Mittelstaedt <tedm at toybox.placo.com> wrote:
>>
>>
>> >-----Original Message-----
>> >From: cisco-nsp-bounces at puck.nether.net
>> >[mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of Kim Onnel
>> >Sent: Monday, August 29, 2005 12:31 AM
>> >To: Cisco-NSP Mailing List
>> >Subject: [c-nsp] BCP for save B/W when transit links are full
>> >
>> >
>> >Hello,
>> >
>> >Our transit links MRTG is up to the roof, ADSL users are doing a fine
>> >share of p2p, we would like save some b/w, we started with peering
>> >with local ISPs, but that didnt save much, the p2p is all out to the
>> >internet,
>> >
>> >Our case is that we would like business customers to have more
>> >priority than residential ones,    we could rate limit based on p2p
>> >apps ports from 8 AM to 5 PM and then let it free, how does that
>> >sound, how do you guys do it, that idea didnt have much acceptance
>> >here, policy as we give customers internet, they do what
>they want, if
>> >we want to rate limit, we limit it all, not per app. ?
>> >
>> >i would like to push the p2p idea further, can anyone provide a
>> >list of ports ?
>> >
>> >Any other ideas ?
>> >
>>
>> Well, actually one way to do it is to analyze who your
>biggest offenders
>> are in the p2p realm, then run a p2p client yourself and
>connect to their
>> server and see what they are doing.  Our experience is that with this
>> kind of traffic 95% of the users are not the bandwidth hogs,
>and the 5%
>> that are hogs are hogs specifically because they are doing
>vast amounts
>> of copyrighted file swapping.  When we find that out we warn them to
>> turn it off, and if they don't we close their account.  (since sharing
>> copyrighted
>> files, basically music and movies, is a AUP violation for us)
>>
>> Once you get rid of the teenagers who are putting their entire 500 CD
>> music collection online, and the porno swappers, (and you
>don't want to
>> know what kind of porno they are swapping) you will find this
>> kind of traffic will fall off quite rapidly.
>>
>> Ted
>>
>> --
>> No virus found in this outgoing message.
>> Checked by AVG Anti-Virus.
>> Version: 7.0.344 / Virus Database: 267.10.17/84 - Release
>Date: 8/29/2005
>>
>>
>
>--
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.0.344 / Virus Database: 267.10.17/85 - Release Date:
>8/30/2005
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.17/85 - Release Date: 8/30/2005