Peering versus Transit

Tue Oct 1 00:59:09 UTC 1996

On Mon, 30 Sep 1996, Vadim Antonov wrote:

> You should always add "without consent of the said ISP".
> 
> It is no different from dumping a pile of bricks at somebody's property.
> 
> Are bricks useful?  You bet.  Will it get you dragged in court on
> charges trespassing and defacing the property?  Sure as hell.

What if you are FlyBite Couriers Inc. and you have a parcel for Bigco
Inc's art department. The sign on the door at BigCo says "No deliveries,
go to the back door, this means you!". But you are to lazy so you walk in,
argue with the receptionist for a minute and dump your package on the
floor. She has to call in one of the mailroom people from the far end of
the building complex to deliver the package.

> It is not a "theft", it is more like trespassing.  It is illegal and
> covered by codes related to unauthorized use of equipment.

FlyBite Couriers has caused Bigco to spend their own resources in order to
deliver the package to teh art department. Is FlyBite Couriers guilty of
theft? No. Are they guilty of trespass? I don't think so. Even though the
sign did seem to indicate that they are not authorised to deliver their
package at the front door, I think you would have a hard time convincing a
court that they made unauthorised use of the front door and reception
area.

Of course, this is just *ONE* possible scenario. Some other scenarios
mentioned here are much clearer than this one.

> One technical reason is pretty obvious -- it is called "traffic engineering".
> Large ISPs often use nudged routing advertisements as means to balance
> load between peering points.  That assumes that nobody is sending
> unsolicited traffic.

This makes good sense too. However, there are always two sides to every
traffic engineeriung question...

WebbFarms ----Sprint--------+--------------------- Exchange ---FlyBitNet
                            |                                      |
                            +----MCI-------------------------------+

Although I am using the names Sprint and MCI here I do not mean to imply
anything about those specific comapnies; they are just a handy way of
referring to Big NSP A and Big NSP B without getting things too mixed up.

Now FlyBit Networks has a T1 to MCI and a DS3 to the XP. From their
traffic engineering point of view it makes sense to send the traffic for
WebbFarms straight into Sprint at the XP. But Sprint's traffic engineers
want to offload traffic from the XP and get it through a private
interconnect with MCI.

>From Sprint's viewpoint their plan makes perfect sense. From FlyBitten's 
viewpoint, *their* plan makes perfect sense.

Of course, FlyBit Networks has no bilateral agreement with Sprint. They
are connected to the XP and Sprint is too. FlyBit sees the XP as a sort of
public resource like the realworld highways and feels that they should be
able to choose their route to deliver packets. In the realworld if Sprint
had a complex with two Sprint-owned accesspoints they would install a
guard and a gate to prevent FlyBite Couriers from using that access.

In the network situation, is there any good reason why Sprint should be
absolved from the responsibility of filtering the traffic coming in from
the exchange? IMHO, the only good such reason would be that the exchange
is doing the filtering itself, whether by contractual agreement or by some
technical means.

I know some XP operators would like to stay right out of the relationships
between XP-connected companies but I don't think this is realistic in the
long run. In particular, it makes a lot of sense to prohibit companies
from connected to the XP's switching fabric unless they have already
negotiated peering arrangements with all other companies currently
connected. This would tend to keep the number of connected peers fairly
small which is a good thing IMHO. For most ISP's it makes more sense to
be in some sort of connectivity farm hanging off the XP using zero-mile
DS3's or similar.

Michael Dillon                   -               ISP & Internet Consulting
Memra Software Inc.              -                  Fax: +1-604-546-3049
http://www.memra.com             -               E-mail: michael at memra.com