Hi Joe-

Your Chris Rock impersonation is grweat:-)  Image the analogy of everyhouse in the
neighborhood has a driveway that enters/exits a 6 lane Interstate highway.  But all
the shopping malls are 20 miles down a dirtroad in the next town...

 The interesting issue is the fact that in a lot of ways, if we didn't push so hard
to impede these P2P servers, we might actually move ourselves into a more
advantageous position - assuming lawyers don't screw the pooch....

Here is a carrot versus the stick scenario:
Try this assertion:  I2 links are less expensive than commodity links.  Therefore, if
we allowed our campuses to be hotbeds of anrachy and allowed the students to set up
servers, then more of the [student] P2P traffic would be routed over I2
infrastrucutre.  The comodity links would (in theory) require that much less
bandwidth, and a higher percentage of that  P2P traffic would be I1 sites requesting
access to I2 based server files.  Throttling that commodity traffic would be less
objectionable then since it would be I1 sites trying to reach servers in I2 land, and
I2 [dorm] students would be happier, and would access the better performing I2
servers before I1 servers.

Sure...this is a bit contrived, but I would be curious - for the sake of argument -
to hear discussion about how we might encourage the placement of such services to
better meet the needs of the entire community (students AND faculty), rather than
just trying to make new "demonized" apps conform to outdated budgeting processes.

Its late...gonna go to bed now...no more meandering comments for now:-)

Jerry



Joe St Sauver wrote:

> >Date: Wed, 21 Mar 2001 14:49:13 -0500
> >From: Jerry Sobieski <[log in to unmask]>
> >Subject: Re: [P2P] How much bandwidth is reasonable?
> >To: [log in to unmask]
>
> Hi Jerry,
>
> >I agree whole heartedly with the sentiment.  In fact, we had a rather spirited
> >conversation at the Internet2 meeting over this topic.  And fundamentally it
> >came down to the cost of provisioning the the campus connection(s) to the "rest"
> >of the Internet.
>
> Yep, commodity Internet connectivity is key (and has been basically ignored).
>
> Envision Chris Rock (the great comedian, who does that deadpan delivery of
> bites from the reality sandwich of life):
>
>    "If you're going to go fast to Internet2, you're going to have to
>     go fast EVERYWHERE. You CAN'T just go fast to Internet2."
>
> Tried to make this point at the Minnesota Joint Techs (see:
> http://www.ncne.nlanr.net/news/workshop/2000/000515/Talks/sauver-jt05152000/ ).
>
> Tried to make this point at the UCSD Meeting on Campus Focused Networks
> (see: http://darkwing.uoregon.edu/~joe/how-to-go-fast.ppt ).
>
> Tried to make this point during discussions of a possible role for the
> proposed I2 Scavenger Service (see, for example:
> http://archives.internet2.edu/guest/archives/i2ss-dt/log0102/msg00003.html ).
>
> Tried to make this point during the peer to peer discussion at the recent
> members meeting in DC (you can see my brief summary at:
> http://darkwing.uoregon.edu/~joe/peer2peeronepager.pdf )
>
> and so on, and so on, ad infinitum. I'm a broken record, what can I say. :-)
>
> Because users do NOT know when they are using I2 or some other sort of
> connectivity, you can't just provision a big pipe to I2, and a small or
> medium sized pipe to the commodity Internet and expect it to work.
>
> And why can't university's deploy large (OC3 class) commodity transit pipes?
> Because they're expensive... So if buying commodity transit won't scale,
> what will? Settlement free exchange-point based peering solutions.
> Unless you're fortunate enough to be able to buy give-it-away-priced
> commodity connectivity from one of the Cogent Communications or Yipes
> of the world, Universities really need to be moving toward a settlement
> free peering-based solutions... and many of them are.
>
> The question then really becomes, "Is this anything that Internet2 can
> help facilitate for the rest of 'em, assuming it wanted to do so?" and
> clearly the answer is yes...
>
> >So, in order to solve this problem, we need to recognize that Internet access is
> >not free.
>
> And yet, of course, Internet access has many characteristics that make people
> behave as if it is costless.
>
> Users get no report telling them how much they've used (unlike filling up
> the gas tank, where the pump tells you how much you're using, as you
> pump the gas).
>
> Charges (if any) aren't usage sensitive -- this isn't like having dim sum
> or sushi at places where you pay per plate, and you better stop when the
> plates start piling up high. The current Internet model is more like Bob's
> "Eat All You Want" Smorgasbord.
>
> For many sites (and particularly for Internet2 connectivity),
> overprovisioning means that usage has no direct incremental cost until
> capacity reaches a step boundary (OC3 to OC12, say).
>
> etc., etc., etc.
>
> And who can blame users? Users think of network access the same way they
> think of the campus library. They don't get charged to check out a book or
> look at a journal, right? Of course, there are still costs associated with
> offering campus a library (or network connectivity), those charges just
> aren't usage sensitive (with rare exceptions).
>
> >And as long as campuses provide free access, they are in fact
> >subsidizing this sort of activity.  Maybe that is a good thing, or at least is
> >consistent with the philosophical search for knowledge we espouse.
>
> My experience has been that most campuses do NOT provide free access, they
> just don't employ usage sensitive pricing. For example, students pay
> educational technology fees, departments may pay per-port installation fees,
> etc. We just don't have per-port (or per-IP or per-MAC address) usage
> monitoring and usage-senstive charge back.
>
> >What would happen when the Web100 project gets really moving and starts
> >automatically tuning TCP stacks for high speed links?  UltraFTP...even
> >legitimate users will be able to oversubscribe the link:-)
>
> Conventionally deployed systems can do it today, using uncopywritten content,
> and using already-well-known protocols (such as regular FTP). Web100's key
> contribution will be in facilitating near-100Mbps *single* flows. If you
> assume multiple flows, you can already get there today. :-)
>
> >I agree with Rene.  We really need to put at least part of our efforts to
> >exploring ways to make bandwidth a non-issue.
>
> Commodity internet settlement-free peering based solutions could do that for
> you....
>
> If you aren't building out a local exchange point (or peering at an
> established exchange point), you're headed down the wrong road. And of
> course, the only way major carriers will be willing to peer with you is
> if you either individually have "a lot" of traffic for them, or if you
> collectively are part of some aggregate that has "a lot" of traffic for
> them. So anytime people choke back the traffic they're seeing their users
> produce, they are (perversely) reducing their attractiveness as a
> potential peering partner, not increasing it.
>
> >Perhaps, such [illegitimate] over use of best effort networks will push campuses
> >to explore and more agressively deploy advanced technologies to manage these
> >resources such as usage based charging, QoS/CoS, line rate policy routing, etc.
>
> I'm QoS skeptical. Edge policing issues, billing issues, and a host of
> other practical problems makes deploying premium service awfully hard,
> particularly on the commodity internet. And, of course, QoS/Cos can't
> manufacture additional bandwidth; etc.
>
> If the goal is to offer less-than-best effort services, there are
> issues there, too, I think (largely associated with incenting people
> to use that less-than-best effort service; see the discussion at:
> http://archives.internet2.edu/guest/archives/i2ss-dt/log0102/msg00019.html)
>
> I'm also of the belief that billing is a huge pain with only marginal
> returns for most users (that's why we don't track and charge back water
> usage at most campuses);
>
> The only thing that does scale is to deploy settlement-free peering based
> commodity connectivity.
>
> Regards,
>
> Joe