North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Fwd: Re: BBN Peering issues - FCC Notice of Inquiry on subject
- From: Einar Stefferud
- Date: Tue Aug 25 14:08:03 1998
Regarding settlement of IP packet traffic
directional differentials at peering points.
Actually, as I understand the Internet Business Model, every customer
of any ISP pays for all packet traffic in both directions between the
customer's access point and the peering point somewhere in the
"middle" between two endpoint customers, for every connection across
I know for certain that I am paying my ISP for all traffic to and from
my access point. And that all points to which I connect also pay for
all IP packet traffic between their endpoint and the "middle",
wherever that might be for any given connection.
Some of my customer fee for ISP service goes to pay transit service
providers for access to the backbone in the "middle" and some of the
transit provider's fee goes top pay for backbone service to the
"middle. And this cascade of fee payments takes care of all charges
for all end user access to the "middle." us end-users are all buying
access to the middle and for all packet transit to and from the
middle. That is what our service contracts call for. If my ISP
refuses to carry my traffic to the middle so I can reach all other ISP
customers on the net, I will find a new ISP that will.
All customers on both ends of every connection across the Interent pay
for all packet traffic to the "middle" so that there is no directional
differential to be paid for at the middle!
Thus, in my view all attempts to "get paid for traffic differentials"
at peering points is essentially bogus, and therefore is a rip off.
The Internet is not a Telephone network, where-in circuit calls are
paid for end to end by the caller, or by the receiver, with all
revenue collected at one end, except for local calls where both the
caller and the receiver enjoy "toll-free" calling between fully paid
subscribers who are in fact both paying for all traffic in both
directions to/from the central switch which is in the "middle".
The phone companies habit of collecting all "toll" revenue at one end
is what justifies "settlement" of directional differentials for toll
calls, and also causes them to do a huge amount of expensive data
collection for billing and bill collction and directional traffic
The Internet, bless its pointy little head, is not so sophisticated as
to figure out how to do end-to-end billing, with sophisitcated data
collection to support packet traffic billing, collection and
settlement. Actually, this is a very good thing for all concerned,
and I hope they never do learn how to do it, as it will no doubt cause
the cost and prices to rise by several hundred percent to pay for all
the extra work on billing and settlement. Arrrggghhh!
So, I argue that the phone company must understand this business model
very well, and must thus be trying to pull a fast one on their peering
Now, on the other hand, I can see that very large backbone service
providers might feel that little ISPs are somehow getting away with a
free ride of some sort because of the differentials in sheer size, but
I still have trouble understanding how they are suffering from any
directional traffic differential, since all traffic received is fully
paid for by some customer, and all traffic delivereed is also fully
paid for by some customer. The paying customer is decided on the
basis of which side of the "middle" the service provider is on.
BTW, the "middle" clearly shifts around depending on where the two
ends of any given connection might be. Sometimes the "middle" is in
the local ISP when both ends are local to the ISP. Soimetime sthe
"middle" is in a Transit ISP, adn sometimes it is at the perring point
between those huge Backbone ISPs. Hence I tend to speak of it as the
"mystical middle" as it is very hard to find in any general sense
because it is spread all over the net, all the time.
So, the only "differential" with any merit that I can see has to be in
the cost differences per unit of traffic for administering small
peering contracts vs large peering contracts. Thus, I can see that
large backbone service providers might very much like to shed little
peering partners, and might very well insist that smaller ISPs obtain
their IP connections via transit providers that would have to be paid
for transit service to the backbone service providers.
Or, the big backbone service providers might very well set up
different service classes with different fee structures, based on the
relatively higher costs of servicing smaller ISPs vs larger ISPs, but
this is not an argument that has anything to do with directional
traffic differentials, in spite of appearing to be very reasonable on
We all know that volume discounts are frequently offered, and are fair
in terms of the relative costs of contract excecution, so if that is
the real argument behind the GTEI "differential settlement" demands,
it would seem like a good idea to correctly say what they mean and
mean what they say, instead of blithering about directional
differentials as though they were still wearing their telephone shaped
>From your message Wed, 12 Aug 1998 16:53:24 -0700:
}It looks like an ISP finally kicked the hornet's nest. Just when the USG
}thinks it can get out of the Internet business, an ISP does this and the
}FCC may think it can step in. For those that do not follow NANOG (yes
}Michael, I know you're there) A recent announcement, from BBN, has caused a
}very large bit of churn. At the bottom-end there are the pipes that keep it
}all flowing. It's not about IP assignments, or names, at this level. It's
}about whom will talk to whom, and for how much.
}Earlier, when we went to CIDR routing, we also got stuck with non-portable
}IP addresses. This locked us into certain ISP-based routing hierarchies.
}There was a tremour, earlier this year, when Sprint began aggrigating their
}BGP announcements differently. That was only a foreshadowing of things to
}come. Regardless of how we all view the Internet, if the peering points
}stop peering, then we all get segregated into a very few large proprietary
}ponds. These ponds will be unable to communicate with each other. All of
}these peering points are in the hands of a few commercial entities, mostly
}telcos. Mostly they are "gentelmen's agreements". The problem is that this
}appears to be becoming unraveled.
}For the record, BBN claims that its new owners (GTEI) are coercing this
}announcement. Since this is a typical telco move, I'm inclined to believe
}There are really two problems here, one is the peering system and the other
}is FCC involvement. If the FCC determines that it has jurisdiction over
}these issues then it may decide that it also has jurisdiction over names
}and IP assignments. In which case the IFWP proceedings are for nought.
}Magaziner may as well pack it up and go home too. The problem is that the
}FCC only has jurisdiction in the US. How will it work extra-territorially,
}existing treaties? If so, then this is the trigger that could cause an
}internet version of the marines landing in Panama.
}I hope this reaches y'all out there in Singapore.
}>Subject: Re: BBN Peering issues - FCC Notice of Inquiry on subject
}>Date: Wed, 12 Aug 1998 16:46:43 -0400
}>From: "Nick Lordi" <email@example.com>
}>Now's your chance, the FCC just released a Notice of Inquiry, FCC 98-187,
}>"Inquiry Concerning the Deployment of Advanced Telecommunications
}>Capabilities..." available in a variety of formats via
}>Take a look at paragraph 79:
}> What can and should the Commission do to preserve efficient
}> peering arrangements among Internet companies, especially in the face
}> of consolidations of large proprietary gateways? We ask for comment
}> whether the Commission should monitor or have authority over
}> peering arrangements to assure that the public interest is served.
}>But be careful, commenting could be akin to opening "Pandora's Box" ;-)
}Roeland M.J. Meyer, ISOC (InterNIC RM993)
}Internet phone: hawk.mhsc.com
}Personal web pages: <http://www.mhsc.com/~rmeyer>www.mhsc.com/~rmeyer
}Company web-site: <http://www.mhsc.com/>www.mhsc.com/
}SecureMail from MHSC.NET is coming soon!