BigISP<-->SmallISP peerings

Sat Oct 26 05:32:09 UTC 1996

>I.e. each small ISP's customer derives 99.9% of benefit from the peering,
>while large ISP's customer derives only 0.01%.  Hence, the large ISP
>can force small ISP to pay up -- without connectivity to a large ISP the
>small ISP will be dead pretty soon.  This is exactly like grocery chains
>which can (and do) force consumers to pay up for food -- although you
>can grow your own tomatoes in your backyard and probably sell them to
>those grocery chains.  Good chances are, they're not interested.

Hrm.  Does it matter if the small ISP already has transit with someone else?
In such a case, peering does nothing but shorten the path from SmallISP to
BigISP in order to no longer make it go through SmallISPs transit provider.
The 'value' delta is no longer so large; in fact is it possible that it could
benefit BigISP by keeping their customers-who-are-local-to-SmallISP from 
transiting to the nearest BigISP-TransitISP peering point by keeping the
traffic local and using the new SmallISP-BigISP peering.

So the main objection to free peering is the offloading of SmallISPs traffic
onto BigISPs expensive backbone.  So if it were possible to have a form of
'local peering' where BigISP could 'locally peer' with SmallISP, meaning that
BigISP would allow SmallISP to deliver traffic that was destined for 
BigISP-customers-local-to-SmallISP directly to BigISP instead of going first
through TransitISP and then through the nearest TransitISP-BigISP peering point,
then that would seem to make both nice-guy as well as economic sense, assuming
that SmallISP is big enough to meet other requirements (like minimal 
problem-response-time and cluefulness tests, perhaps)

To illustrate:

    SmallISP========TransitISP===================TransitISP/BigISP Peering
     \\                                            \\
      SmallISP/BigISP_Local_Peering                 \\
         \\                                          \\
          BigISP_POP_local_to_SmallISP===============BigISP Backbone
         //                                           \\ 
        BigISPcustomerlocaltoSmallISP                  RemoteBigISPCustomers

and in the above illustration realize that the 'local peering' doesn't let
SmallISP talk to RemoteBigISPCustomers without going through TransitISP.

Now, wait, this is the Internet of the 90s - all the Real Big ISPs use a technique
of routing called 'closest exit'.  Which, I think, means that they try and
get the packets off of their backbone and one step closer to its destination
as soon as possible.  So, if we further add the condition that both
peering sessions above are located at one place (the LocaltoSmallISP Nap, for instance)
then the picture starts looking like:

    SmallISP========TransitISP===================TransitISP/BigISP Peering===TransitISP Backbone
     \\                                         / \\                        //
      SmallISP/BigISP_Local_Peering------------+   \\                      //
         \\                                         \\                    //
          BigISP_POP_local_to_SmallISP===============BigISP Backbone=====BigISP/TransitISPPeering
         //                                           \\ 
        BigISPcustomerlocaltoSmallISP                  RemoteBigISPCustomers

with the -- link being the (presumably fast) NAP/MAE media. Now, if TransitISP is
in fact using closest-exit (aka 'hot potato') routing, then the route to even
RemoteBigISPCustomers is the same distance through BigISPs Backbone whether
it goes through TransitISP or the SmallISP/BigISP_Local_Peering connection.
Outbound.  Hrm. So the only extra cost (not insignificant, I realize) is that
of the traffic outbound from RemoteBigISPCustomers to SmallISP across BigISPs 
backbone, which goes that way since SmallISP is peered with BigISP and is
therefore 'closer' that way than via TransitISP.  Hrm.  Is there no metric
that can be set to offset this?  I admit ignorance of teh finer points of BGP.

It's been interesting.

 --Zachary