| WIKI | FAQ | Tech FAQ | |
 http://csua.com/feed/ | |
| ||||||
| 5/24 |
| 2002/2/20 [Computer/SW/P2P, Computer/SW/Security] UID:23921 Activity:high |
2/19 Tom posts an intelligent comment on usenet:
http://groups.google.com/groups?hl=en&selm=a4u5df%241uvv%241%40agate.berkeley.edu
\_ Charging is one possibility except then you get into the problem
of exactly who to charge. Do you charge the student assigned to a
workstation? Ok, another user logs in from another local machine
and uses the other student's machine for external access. Do you
charge the whole department or sub-unit and "let God sort it out"?
That just means rich departments stay on the net and poorer ones
take the net away from most of their users. You can't charge by
IP address because IP != unique user and packets don't have user
names on them. There's still no answer short of simply cutting off
a lot of people from external net access and I don't think anyone
wants that.
\_ "tragedy of the commons" problems usually have no easy solution.
The issue of access to national parks is a good example; you
can't restrict access to Yosemite Valley in a way that's
pleasing and fair, but you have to restrict access if you want
Yosemite Valley to retain its value. At some point you have
to make some decisions about tradeoffs. A campus phone isn't
equivalent to a unique user, either, but we manage to bill
people for phone service. -tom
\_ I don't have a problem with the basic concept of billing for
usage but it isn't the same as phones. Most people aren't on
the phone all day. Most aren't making LD calls. And it is a
bit difficult to login to your phone from my desk without your
knowledge and rack up a huge bill to 976-hotsex. $300 in
calls on my phone to my office mate's mother in Tokyo is easy
to track down and bill properly. With the technology at hand
I only see raising bandwidth or cutting a lot of people off
from the public net. I don't see the latter as a good choice
for a research/educational institution. It also wouldn't fly
politically.
\- i think this is naive.
\_ How are you planning to pay for this increased bandwidth?
\_ I don't think anyone wants to cut people off the net,
but providing a certain amount of "free" service, and
charging if you go over a certain amount of traffic, is
probably a tenable model. Buying bandwidth indefinitely
so kids can fill it up with more kazaa is untenable. -tom
\_Just raise tuiton. Make net access a line item that
people can elect not to pay for if they don't need it.
\_ "Every complex problem has a solution that's
simple, elegant, and won't work." -tom
\_ isn that ken lindahl's or msinatra's quote?
\- Why doesnt "disallow P2P except on certain
subnets/via prior arragement" [say for people
using gnutella for collaboration or maybe some-
body in cs doing something researchy] solve the
problem as long as someone in the dorms can
get their own isp access [i am not sure if this
is possible]. are students on the dormnet
allowed to run WEEB servers? yes, a lot of the
http is garbage but you have to attack what is
viable and cost-effective. the comment about
running the p2p server on port 80 to "hide" is
not a real issue. at least with napster,
gnutella, kazza, we can detect it on any port
[although not in real time, although that doesnt
seem important]. Also, the TotC comparison isnt
quite right since the Commons is a natural
endowment while bandwidth is sort of a "weakly-
rival" good paid for by somebody. Say I build a
lighthouse for my shipping company along my
shipping lane. I dont care if some people use
my lighthouses, however if this makes for "my
shipping lanes" too crowded for me to use,
well, i'd be better off switching technologies.
it seems like if you throttled the dormnet
traffic onto the routed internet but allowed
significant bandwidth to campus, people could
do their school work. [i assume most of the
p2p sharing isnt local]. --psb
[the lighthouse example is a little off because
it is not a divisible but a binary good but that
wasnt the point i was getting at. someone does
own the bandwidth].
\_ dorm traffic is already handled under
a separate cap. You can do things to
discourage P2P sharing, but that only
solves 25% of your problem, and the
more you discourage it, the more incentive
there is to find ways around it. -tom
\_ MOTD WANKERY! None of you people are in position to do anything.
\_ actually, I am. -tom
\_ A chill falls across the room...
\_ wanking is precisely what they are in the position to do. |
| 5/24 |
|
| groups.google.com/groups?hl=en&selm=a4u5df%241uvv%241%40agate.berkeley.edu Certainly instruction and research is being hurt by )hitting the 70Mbps limit. Unfortunately, throwing more bandwidth at the problem only postpones the problem, whether or not P2P clients are dealt with. At last week's NAG meeting, Cliff Frost showed us some graphs based on network usage over the past three months, and they were revealing. The summary: * P2P clients consume 20-30% of the 70Mbps pipe from the main campus. Total campus traffic, including the dorms, is more like 50% P2P, but much of it is under the dorms' separate 40Mbps cap. The other big bandwidth usages on campus are SETI@Home, NNTP, and FTP. The first two aren't as important, because they both are configured to use mostly excess bandwidth. What this means is, killing all the kazaa/gnutella users, even if it were possible, wouldn't solve the problem for long. In six months, our http traffic will have swelled by 150-250 gigabytes per day--the trend line is obvious. And what percentage of the http traffic is any more appropriate than kazaa/gnutella? There are rarely technological solutions to social problems. Let's say we do try to place significant technical restrictions on kazaa/gnutella traffic. Maybe we use the plan suggested here of "whitelisting" http, ssh, and ftp traffic, and sectioning off everything else. The first thing that happens is we spend a lot of time and effort troubleshooting things, like IPSEC, or Corporate Time, that we missed on the initial whitelist. Then, some kid comes up with the bright idea of using port 80 for gnutella, and then what do we do? And even if everything works perfectly, 6 months down the road we'll be hitting the cap with whitelisted traffic alone. I think eventually the campus will be forced to start charging users for bandwidth usage over a certain baseline. There are provisions for that in the network funding model which spawned the node bank. CNS is now capable of tracking traffic down to a single IP, but they need quite a bit more data before they can start billing down to a single IP; It's really similar to phone billing, but people aren't used to the idea of network billing, and it will take a while before usage habits change. The example of a communal pastureland for grazing is instructive to our case. |