>Date: Wed, 21 Mar 2001 23:37:15 -0500
>From: Jerry Sobieski <[log in to unmask]>
>Subject: Re: [P2P] How much bandwidth is reasonable?
>To: [log in to unmask]
Hi Jerry,
[some stuff snipped here]
>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....
Absolutely true.
>Here is a carrot versus the stick scenario:
>Try this assertion: I2 links are less expensive than commodity links.
It is generally true that I2 links will be less expensive than other links,
but that's not always true, and that monotonicity and non-transitivity can
cause some real problems. For example, consider some trivial cases:
-- multiple I2 schools in the same state, all connected by an intrastate
network, but not all connecting to Internet2 via the same connector...
It is an interesting question to argue over a beer what's the "right"
or "optimal" thing to do with traffic between those schools.
Obviously the intrastate network would be a strong candidate to carry
that intrastate traffic, but you can also make a pretty strong argument
that it is cleaner to send that traffic over the I2 links instead
(obvious example of a scenario where it might "make sense" to do so
would be uncongested OC12 Internet2 connectivity, and congested DS3
intrastate network connectivity; another example would be if the I2
link was providing some advanced service that wasn't available via the
generic intrastate network link).
-- Two I2 schools, each of which has a relationship with a common network
service provider. Assume I2 school "Alpha" peers with the NSP, paying
nothing in the way of settlements, and assume the other I2 school, "Bravo",
buys commodity transit from that same NSP.
To Alpha, the I2 school that peers with the NSP, traffic in or out that
peering connection is (arguably) cheaper than traffic going out I2; of
course, to Bravo, the I2 school that's buying commodity transit from
the NSP, seeing traffic traversing their expensive commodity link is a
cause for dismay (they'd obviously prefer the traffic to have gone via
Abilene). Of course, one option is for traffic to be sent asymmetrically,
but that has issues of its own, as Hank Nussbacher so well illustrated in
his paper.
>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.
Interesting assertion, however I'm not sure it holds. We looked at the traffic
distribution associated with one particular P2P server which had I2 and non-I2
connectivity, and just didn't see that hypothesis play out.
The problem, of course, is that for every user who has I2 connectivity, there
are 10's or 100's (if not thousands) who do not, particularly lots of folks
connected via DSL or cable modems from home. Hell, even our own students,
when they connect from a DSL or cable modem provider, don't look I2 eligible
to us (because in fact they're not -- they're connecting via some third party
commercial ISP such as @Home, etc.).
>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.
But again, you run into the issue that users just can't tell/don't bother to
find out how they're connecting. Here's my favorite example for that issue:
Tucows.
Tucows has archives ALL over the place, and the first thing you do when you
go to Tucows is pick out a server to use. How do you pick it out?
Geographically.
For example, suppose you live in Oregon (yeah, I know that this causes
shudders among some of you, much in the way Boeing appears to be shuddering
at the thought of keeping its headquarters in Seattle), but bear with me
for a moment.
When Tucows shows me my choices for Oregon servers, I have my choice between
one in LaGrande (Eastern Oregon Net), or Preferred Communications (Lakeside).
Neither of them are I2 connected... Okay, let's assume that I'm persistent,
and poke around further... I backup a link and check t see if I recognize
anything I2-connected from California... nope again... Washington State...
nope.
Turns out that my best choice (from a use-I2-if-I-can point of view) is
probably to go to the Tucows mirror at the University of Oklahoma... but
who'd think to look there, right? (I only found it one day when I was
bored and looked alphabetically at each state)
Moreover, there's absolutely NOTHING that advertises the fact that the
University of Oklahoma's Tucows mirror has Internet2 connectivity. I knew
it did, because I work with Internet2 and folks at Oklahoma, but that's
not going to be true for most folks.
I believe I even went so far as to suggest to Tucows that they might
consider showing network connectivity (pipe size and provider) in
addition to location for each of their mirrors, but they disregarded that
suggestion. (and frankly, they were probably right to do so -- most users
wouldn't care and couldn't make effective use of the information if they
were to be given it)
And unless you think I'm picking on Tucows, I'm not. Look at any other
well-mirrored software archive, e.g.:
-- GNU (http://www.gnu.org/server/list-mirrors.html)
-- CPAN (http://www.cpan.org/SITES.html)
-- CTAN (http://www.ctan.org/tex-archive/CTAN.sites?action=/index.html)
-- X11 (http://www.x.org/download.htm#mirror)
-- FreeBSD (http://www.freebsdmirrors.org/FBSDsites.php3?release=4.2-RELEASE)
-- NetBSD (http://www.netbsd.org/Sites/net.html#ftp)
etc., etc., etc.
NONE of them show ANY indication of whether or not a site is Internet2
connected, and some of them (such as the freebsd.org mirrors) actually
obscure institutional affiliation by overlaying a freebsd.org DNS entry
on top of the hosting institution's address). It is a BIG problem.
>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.
Either the app needs to be able to analyze and automatically select the
best server (from among multiple possible servers) based on connectivity,
or we need to do a far better job of helping users to know what is and
what isn't I2 connected.
Users won't pick I2 connected servers if they can't tell what is and isn't
connected via I2.
Regards,
Joe
|
