different thinking on exchanging traffic

Mailman List Mirror (Read Only)
1

From: "Sean M. Doran" <smd@clock.org>
Subject: Re: different thinking on exchanging traffic
Date: Fri, 22 May 1998 17:38:12 -0700
  [...]
Meanwhile, you might find the Sprint response to the NSFNET
NAP solicitation ("National Virtual NAP") hanging around somewhere
online. You should read it and imagine why it didn't fly.

I believe that all four of the winning NSFNET NAP submissions proposed
nationwide "NAPs". I believe that the reason they didn't happen is that
the NSF asked for and assumed it would get four geographically-focused
solutions. I suspect that the notion of awarding four NAPs, all of which
covered all of the country, provided the NSF a certain amount of heartburn.
I believe that the nationwide NAP concept died, (or was killed), at the
time for administrative, not technical, reasons. But, this is all
speculation on my part...

I have two conflicting notions about the the interesting possibilities
offered by nationwide layer-two services:

o Layer-two services with distance-insensitive pricing, such as
  ATM, create some interesting opportunities. If it doesn't cost
  any more to get across the country than to get across town, why
  should I build a local NAP rather than a nationwide NAP? (Unless,
  of course, I am a RBOC and am administratively constrained from
  offering inter-LATA service.) (I am also ignoring a comparison
  of a NAP-in-a-closet/POP/parking ramp versus a
  NAP-in-a-metropolitan-area; this is e-mail to nanog, not a
  paper for Sigcomm.) Perhaps more relevant today, why should I
  build a regional Gigapop, _if_ my ATM pricing is truly
  distance-insensitive? (There might be an answer to the last
  question, I really don't know. But, I keep asking.)

  In other words, if pricing is distance-insensitive, why do I
  need local exchanges?

o Distance matters. It is easy to configure an IP network over
  a large layer-two service that bounces packets around the country,
  (because IP routing protocols generally think in terms of hop
  count, not [physical] distance). It would be nice if
  routing protocols thought about [physical] distance, rather
  than require the network designer to be responsible for
  designing the network such that considerations of physical
  distance were implicit in the network design. Of course, in the
  good old days before distance-insensitive-priced services, this
  wasn't such an issue.

(I don't know whether there are very many copies of Sprint's "National
Virtual NAP" proposals hanging around. I had to nearly sign my life
away to get a copy at the time...)

-tjs

2

I have two conflicting notions about the the interesting possibilities
offered by nationwide layer-two services:

o Layer-two services with distance-insensitive pricing, such as
  ATM, create some interesting opportunities. If it doesn't cost
  any more to get across the country than to get across town, why
  should I build a local NAP rather than a nationwide NAP? (Unless,
  of course, I am a RBOC and am administratively constrained from
  offering inter-LATA service.) (I am also ignoring a comparison
  of a NAP-in-a-closet/POP/parking ramp versus a
  NAP-in-a-metropolitan-area; this is e-mail to nanog, not a
  paper for Sigcomm.) Perhaps more relevant today, why should I
  build a regional Gigapop, _if_ my ATM pricing is truly
  distance-insensitive? (There might be an answer to the last
  question, I really don't know. But, I keep asking.)

  In other words, if pricing is distance-insensitive, why do I
  need local exchanges?

Forgive me, but kee-rist! Haven't I bung this drum enough this month?

Because, more and more as the net penetrates, the traffic is more and
more _local_. Geographically local. My point about MAE-East-in-a-garage
was that there was only _one_ of them; where it _was_ was only thrown
in for spite.

Especially as the net becomes more used for telecommuting, there is
absolutely _no_ sense in my having to telnet from St Pete 30 miles to
Tampa via a router in Maryland or San Francisco, "just" because the two
sites in question decided to buy their connectivity from different
backbones.

o Distance matters. It is easy to configure an IP network over
  a large layer-two service that bounces packets around the country,
  (because IP routing protocols generally think in terms of hop
  count, not [physical] distance). It would be nice if
  routing protocols thought about [physical] distance, rather
  than require the network designer to be responsible for
  designing the network such that considerations of physical
  distance were implicit in the network design. Of course, in the
  good old days before distance-insensitive-priced services, this
  wasn't such an issue.

I don't know if it's _possible_ to push this into the routing layer --
even if the routing protocol decides not to ship those 30 mile packets
3000 miles... it doesn't _matter_ if there's no link to _put them on_.

It's obvious that it's time for my nap (no pun intended), my underscore
quotient has shot through the roof.

Cheers,
-- jra

3

The moving finger of Jay R Ashworth, having written:

      <SNIP>

    > Because, more and more as the net penetrates, the traffic is more and
    > more _local_. Geographically local. My point about MAE-East-in-a-garage
    > was that there was only _one_ of them; where it _was_ was only thrown
    > in for spite.

    > Especially as the net becomes more used for telecommuting, there is
    > absolutely _no_ sense in my having to telnet from St Pete 30 miles to
    > Tampa via a router in Maryland or San Francisco, "just" because the two
    > sites in question decided to buy their connectivity from different
    > backbones.

Yup. Especially in places with a high-density of high-tech, lousy
commutes and a high penetration of "home" Internet access and many
ISPs.

Currently there are at least 60 ISPs serving the San Diego county
area. There are LOTS of packets from "home" to "office" that make a
round-trip via MAE-West. Some people have decided that this is
silly. Even if it is "cost-effective", it *squanders* bandwidth at
MAE-West that could best be used for other traffic.

I wonder how much bandwidth at the MAEs could be saved if more areas
built local low-cost NAPs just for local traffice exchanges?

See this URL for details on the SD-NAP project:
http://www.caida.org/Caida/caidaix.html

4

I think there's a lot of merit to this proposal. When I first signed on with
a local Internet provider, the owner explained to me that GEOGRAPHIC
proximity does not always equal INTERNET proximity. Back then (1991-92)
there was not a lot of infrastructure, so often that couldn't be helped. It's
quite different now, though.

5

No it's not.

There's still little confluence between the two distance metrics. :slight_smile:

You're correct in noting that the infrastructure will support it now,
though.

Gotta go find me a vulture capitalist...

Cheers,
- jra

6

> I think there's a lot of merit to this proposal. When I first signed on with
> a local Internet provider, the owner explained to me that GEOGRAPHIC
> proximity does not always equal INTERNET proximity. Back then (1991-92)
> there was not a lot of infrastructure, so often that couldn't be helped. It's
> quite different now, though.

No it's not.

There's still little confluence between the two distance metrics. :slight_smile:

That wasn't my argument; my argument was that there wasn't a lot that could
be done about the lack of confluence. :slight_smile: Now, with medium-sized cities like
Cleveland covered by several different national NSP's as well as regional
NSP's and ISP's, there isn't much of a reason that things should stay that
way.

You're correct in noting that the infrastructure will support it now,
though.

Thank you. :slight_smile: