8/23    Will network performance suck again, now that the semester is
        starting?  Or has something been done about it?
        \_ it sucked before?
           \_ you didn't notice?
              \_ guess not :)
           \_ yes.
        \_ If you can't beat them, join 'em.  dl kazaa.
           \_ Make sure to get the fully spyware enabled trjoan horse version.
        \_ Some things have been done.  SETI@@@@@@@@Home now has its own ISP
           connection.  The cost of bandwidth has come down, so our
           bandwidth cap is now 90 megabits/sec instead of 70 megabits/sec.
           Within the next week or two, it will be raised to 100 megabits/sec
           once some new hardware is installed.
           My guess is that there will still be performance issues, if not
           at the beginning of the semester, then at least by the end of the
           calendar year.  I'm currently writing up a report requesting
           immediate emergency funding for bandwidth charges, with longer-
           term plans to do more with managing KaZaa, and managing or
           charging high-bandwidth users in general.  -tom
           \_ That's how it starts.  Next you'll be putting KaZaa users
              into camps.  And people using KaZaa _and_ SETI@Home will be
              put to death.  Heil Tom!
              \_ I don't know tom or his personality, but I think his
                 idea above is good.
                 \_ Sure, until someone decides *your* traffic isn't a priority
                    and you should be charge or 'managed'.
           \_ and just how do you plan to put a stop to Kazaa users when the
              Kazaa topology is dynamic?
                    \- you can because the "protocol isnt dynamic"
              \_ I don't think you can "put a stop" to peer-to-peer file
                 sharing; certainly not by technical means, on a campus like
                 Berkeley.  But the effects of KaZaa can be measured, and
                 the people using KaZaa can be managed.  (As in, "stop doing
                 that").  Remember, we're talking about on-campus machines,
                 not the dorms (which have their own separate cap).  Note
                 that the problem with KaZaa on campus is files being
                 downloaded by people from off-campus; campus people
                 using KaZaa to download files don't contribute to the
                 problem due to the current algorithm for bandwidth
                 charging.  -tom
                 \_ stopping p2p pirary on college campuses is VERY easy.
                    All you need to do is to adopt a new university policy
                    that sez if you're caught pirating stuff you'll be
                    expelled.  No appeals.  then you start the random search
                    in the dorms and start expelling some of the incoming
                    freshman.  You'll see the p2p traffic drop to NIL once
                    the pictures of expelled freshmen gets on Daily Cal.
                    Remember the naked guy?  After the law against nudity
                    at Berkeley and on campuses, and he got expelled, nobody
                    dared to show up naked.  Enforcement is the key.  Expell
                    the little fuckers without due process and you'll see
                    \_ Or as they say, "try and then execute them!"
                    everybody marching in line.
                 \- stopping kaza, gnutella, napster and a couple of other
                    p2p piracy programs is solved problem technically.
                    it is fairly strightforward to detect them in real time
                    and blast them with RST packets. it is an open question
                    what the policy should be and it is slightly involved
                    attempting to "whitelist" some users who are allegedly
                    using it for "real work". the "dynamic topology" and
                    configurable ports dont matter. of course there are
                    more involved ways to hide, but 99% of the users at
                    the moment dont do that ... although the number of
                    evaders may increase *some* if the "kazka obliterator"
                    code were deployed. ok tnx.
                         \- actually to do this 100% on a large scale isnt
                            that simple technically, but it is pretty simple
                            to deploy something that fucks up enough
                            p2p programs so that it is effectively unusable.
                            and this is a case where you dont need 100%
                            coverage to change behavior.
                            \_ The problem is, the more you fuck it up, the
                               more incentive you provide to find ways
                               around the blocks.  It will always be easier
                               to hide file sharing than to block it.
                                  \- thus far, untrue. or only true with
                                     very sophisticated users and very
                                     unsophisticated detectors ... but not
                                     inherently true. --psb
                               But certainly there are measures which could
                               be taken which would make an impact, if it's
                               decided that it's a good idea to take such
                               measures.  (The other problem is, once you
                               make people hide their P2P usage, you have
                               a harder time finding them to rap their
                               knuckles).   -tom
                               \-as i said above, most attempts to hide
                                 do not work against a good detection
                                 system. if you are doing something stupid
                                 like looking for a static port or a
                                 list of src/dst addresses like in the
                                 case of the napster "metaservers" it is
                                 easy to get around by just punching in a
                                 different number somewhere ... but at this
                                 point setting up a fancy proxy or encrypted
                                 tunnel is beyond the ken of most of the
                                 community ... perhaps something canned will
                                 emerge soon that gets around the current
                                 generation of our detectors, but at the moment
                                 this is not a technical but a political/
                                 resource allocation problem. this is based
                                 on many months of experience at a decent
                                 sized institution with a fair number of
                                 sophisticated users. --psb
                               \_ Is this the point where we start talking
                                  about The Tragedy Of The Commons?  I miss
                                  those threads....