michael at memra.com
Sat Aug 22 14:02:49 UTC 1998
On Fri, 21 Aug 1998, Bruce Hahne wrote:
> I don't see that you've answered his question about value flow. You're
> describing how to set a value on a stream of packets without answering the
> question of who should pay. Should we charge the sender or the receiver?
Neither. We charge the peer whose traffic is incoming and who uses our
transit resources, a.k.a. intercity links. The peer always has control
over the traffic because they can route it differently if they choose or
build network infrastructure to avoid excessive use of the other company's
intercity links. We don't care about the peer's customers at all and have
no idea what is in the data packets. They are just bitstreams flowing in
> Back at the 1995 APRICOT conference there was a mention of an IETF WG
> (likely now dissolved) which was specifically working on the settlements
> issue, and their answer to this question was "it depends". For every packet
> you have to determine a packet owner who is responsible for paying. The
> owner could vary per application, per site, and/or per end user.
Much, much too complex. If the packet comes into my network, I note which
peer it came from, what is it's destination address and how many bytes in
the packet. At my leisure, I count the bytes and compare with outgoing
bytes. If it exceeds a predetermined ratio of free balanced peering, I
apply a selection algorithm to look at destination addresses and byte
counts and calculate a transit value. This is what I bill. Of course, in
the real world the collection of data and the billing would be audited or
even performed by a 3rd party settlements council.
> If I'm downloading a copy
> of sendmail, I'm probably the "owner" of those ftp packets
I don't care about you; you're just a customer. The peering relationship
is strictly between the two backbone providers.
Michael Dillon - Internet & ISP Consulting
Memra Communications Inc. - E-mail: michael at memra.com
Check the website for my Internet World articles - http://www.memra.com
More information about the NANOG