BBN/GTEI

Mailman List Mirror (Read Only)
1

Dave Rand wrote:

Assuming it does matter, in which direction does the value flow?

and Michael Dillon responds:

Here's the complex part. The value is not expressed in bits and it depends
on the destination within the peer's network. I am assuming that we can
map the IPv4 address space by city and that we can set some value to each
intercity link. This means that a stream of bits entering a peers network
in San Jose with a final destination in San Jose would be free. But if the
stream of bits was destined for Santa Cruz there would be a small cost.

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?
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. I could
even imagine that responsibility for payment could be split between sender
and receiver: 50/50, 90/10, choose your favorite. If I'm downloading a copy
of sendmail, I'm probably the "owner" of those ftp packets because Berkeley
makes sendmail available as a public service and doesn't want to pay
settlement costs to reach me. If I'm downloading a product white paper,
maybe I expect the company that wrote the white paper to pay transit costs
to reach me because it's a marketing expense that they should absorb. If
somebody is sending me spam, I want the spammer to be the owner of those
SMTP packets because I'm certainly not going to pay a settlement fee so that
people can spam me.

Back to Dave Rand again:

Down this path lies madness.

Perhaps. On the other hand, there are already multiple Silicon Valley
startups whose business models revolve entirely around metering every packet.
And several well-known SF Bay area companies are already paying on a
strictly metered (per Gb) basis to deliver web and ftp content to customers
and potential customers. Metering in a multi-provider environment generally
requires settlements.

On-net facilities have made distance-sensitive pricing in most metro areas a
thing of the past. Sub $0.04 per DS0-mile long-haul rates have made long
haul circuits very affordable. High speed WDM dark fiber routes will make
long haul very, very cheap in the next 2 years.

This is the old "bandwidth is so cheap that it's free" argument. True,
bandwidth is now inexpensive enough for a single DS0 that it's becoming
counterproductive, from a marketing standpoint, for the telco to attempt to
differentiate based on distance for a voice call. But if we're ever to
arrive at the day when I can turn on my 100Mbps video-over-IP feed to my
home PC over my FTTH connection, and expect to actually get reasonable
performance, we're probably going to need both metering and inter-provider
settlements.

Bruce Hahne
hahne@netcom.com

2

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. I could
even imagine that responsibility for payment could be split between sender
and receiver: 50/50, 90/10, choose your favorite.

If your split isn't 50/50 (in other words settlement free) I guarantee
anybody with half a brain will balance out their traffic by hosting the
correct type of applications so that you owe them money.

Repeated from my earlier post: Transaction based settlements will have the
effect of subsidizing one form or another of transactions, in this case
either requesting web pages or serving web pages, and clueful providers
will act accordingly to maximize revenue by hosting the appropriate
applications (for example a web crawler).

In fact, TRANSACTION BASED SETTLEMENTS ENCOURAGE WASTE to the point where
it should be obvious to the casual observer that anybody reasonably
informed would never suggest them.

The factors that are the cause of the inherent problem with transactions
based settlements are:

1) Either party can end up paying.
2) Transactions are generated by machines.
3) Machines can generate transactions which are either positive flow or
negative flow. (web servers vs web crawlers as two simplistic examples).

Oh, and before anybody comes up with a simplistic (and flawed) rebuttal
such as banning the large web crawlers from settlements, there are plenty
of other legitimate automated methods of getting flows in either
direction.

Mike.

+------------------- H U R R I C A N E - E L E C T R I C -------------------+

3

If your split isn't 50/50 (in other words settlement free) I guarantee
anybody with half a brain will balance out their traffic by hosting the
correct type of applications so that you owe them money.

Of course if everybody does this, then the traffic will balance out. Seems
to be a good thing to create the incentive, no?

In fact, TRANSACTION BASED SETTLEMENTS ENCOURAGE WASTE to the point where
it should be obvious to the casual observer that anybody reasonably
informed would never suggest them.

Then I must be unreasonably informed because I think that some form of
exchanging money to even out imbalances would give providers more choice.

The factors that are the cause of the inherent problem with transactions
based settlements are:

1) Either party can end up paying.
2) Transactions are generated by machines.
3) Machines can generate transactions which are either positive flow or
negative flow. (web servers vs web crawlers as two simplistic examples).

OK. So now you've convinced us that network traffic shres a number of
characteristics with electric power distribution. Yet the power companies
seem to manage quite well with settlements. I wouldn't want to slavishly
imitate their system any more than I want to slavishly imitate the long
distance telcos. But these things can be made to work.

Oh, and before anybody comes up with a simplistic (and flawed) rebuttal
such as banning the large web crawlers from settlements, there are plenty
of other legitimate automated methods of getting flows in either
direction.

They aren't legitimate if the sole purpose of the method is to create
traffic; that would be fraud. A webcrawler would be fine if it was for a
search engine but not if you just ran it and discarded the data.

4

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
both directions.

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.

5

> If your split isn't 50/50 (in other words settlement free) I guarantee
> anybody with half a brain will balance out their traffic by hosting the
> correct type of applications so that you owe them money.

Of course if everybody does this, then the traffic will balance out. Seems
to be a good thing to create the incentive, no?

The point is that anybody interested in making money would make sure that
traffic didn't just balance out, they would develop a business plan where
they maximized revenue from settlements where possible.

> In fact, TRANSACTION BASED SETTLEMENTS ENCOURAGE WASTE to the point where
> it should be obvious to the casual observer that anybody reasonably
> informed would never suggest them.

Then I must be unreasonably informed because I think that some form of
exchanging money to even out imbalances would give providers more choice.

Ok, so that was gratuitous. Let me put it this way, transaction based
settlements encourage creative minded people to go out and create
businesses based on this new revenue source you have created. Ultimately,
traffic would be generated for traffic's sake, and this would be waste.

Evening out imbalances isn't what would happen. Businesses don't exist to
even out their profit and loss statement.

Understand, for the sake of argument I'm not saying that anybody would
necessarily generate traffic destined for the bit bucket, I am saying you
incentivize bad behavior with transaction based settlements. See examples
below.

They aren't legitimate if the sole purpose of the method is to create
traffic; that would be fraud. A webcrawler would be fine if it was for a
search engine but not if you just ran it and discarded the data.

Ok, so how about if you have a big dialup pool, or a R&D department is
developing a new type of web index, or somebody is studying word frequency
occurance of written english in web pages, or any one of half a dozen
other perfectly legitimate uses that suck traffic instead of pulling
traffic (and these two are just what I thought of in the second when I got
to the period in your sentence, I could come up with hundreds much better
uses based on what people are already doing as legitimate businesses
online).

Ok, now think about what happens if a provider earns revenue from any of
these applicatons. Instead of charging for the bandwidth a provider could
actually pay the users that generate this type of traffic.

Ok, now see how easy it would be to attract legitimate users. People
would run ads to the effect of "Are you a dialup provider? We'll pay you
to get an OC3 from us!" Or "Are you a web crawler? We'll pay you to
host with us?" Or any one of several other examples...

Michael, I've met and talked with you several times and have the general
impression you're a relatively creative guy. I find it hard to believe
that you are myopic to the extent of not being able to imagine these and
other uses... unless the actual goal of your proposal is to have dialup
providers and web crawlers get paid for existing.

At first glance that might be your impression as to what happens.
However, can't you see how this type of settlement encourages web crawlers
to generate more traffic.

Again, as just one of hundreds of ideas, imagine that a web crawler house
has the choice of updating their database once every 30 days or once every
15 days. Now imagine they make the decision about this in light of the
fact they get paid for additional traffic. So now they have an incentive
to update their database more frequently. Wow, what a great service for
the customer! And as a kicker, they make more money from settlements!

And web crawlers are just one application, and not the only one that sucks
traffic from web servers. And I can think of many more perfectly valid
uses for other protocols. Again, if you use your imagination, you can
create a legitimate business based on currently existing online businesses
and get the desired traffic flows.

Ultimately, in all of these cases less efficient algorithms and uses will
be chosen in the direction that results in positive revenue, and waste
will occur.

Mike.

+------------------- H U R R I C A N E - E L E C T R I C -------------------+

6

In fact, this already happens with telco termination charges. For example,
there are CLECs that call up dialup ISPs and offer free PRIs. They plan
to make more on termination charges than they could possibly get from the
ISPs in a competitive environment. Aside from the fact that they don't
have copper in the ground, this is the reason CLECs don't want residential
customers, since they would be the ones paying termination fees on originated
calls. When enough CLECs are concentrating on businesses that only have
incoming calls (ISPs, tech support centers, 900-style services, etc), Bell
will scream to the FCC that termination charges need to be reevaluated.
With this approach, eventually *no one* will want customers that make lots
of outbound calls -- let the other providers have them and then collect the
money when they call your customers.

The point is it is an unstable environment. Unlike capitalism where our
innate greedy nature serves to balance the system, in this case the greedy
nature serves to unbalance the system by promoting inefficient use of
resources.

John Tamplin Traveller Information Services
jat@Traveller.COM 2104 West Ferry Way
256/705-7007 - FAX 256/705-7100 Huntsville, AL 35801

7

Michael, I've met and talked with you several times and have the general
impression you're a relatively creative guy.

*blushes*

I find it hard to believe
that you are myopic to the extent of not being able to imagine these and
other uses... unless the actual goal of your proposal is to have dialup
providers and web crawlers get paid for existing.

Well, I can imagine them but I can also imagine solutions to them. For
instance, rate-limiting can be applied on either side of the peering
interface. And if both peers try to attract legitimate sucking users then
chances are that both peers will get some of them and the traffic flows
will even out somewhat. Also, if it does not make economic sense for peer A
to have an interconnect with peer B in a specific city, then they won't do
it. This greatly reduces the incentive for peer B to sign up customers to
suck from A because all of a sudden, those customers will either lose
connectivity or that traffic load will suddenly shift to peer C who sells
transit to peer A.

I think that most companies will think through these issues before acting
rather than just taking the simplistic view that it is good to suck huge
amounts of traffic from a peer. Also, this is an entirely hypothetical
scenario so the actual implementation could differ considerably.

Consider the fact that in order to make this work, both peers need to
supply a settlement arbiter with a full city-to-city link map with
route-miles and with a price list to determine the value of transit
consumed. We could just as easily say that if the traffic is out of
balance by a ratio of more than 2:1 then we will examine the transit
consumed on both peer's networks based on the maps and the
source/destination addresses. Then those numbers will be balanced against
one another and the peer who uses more transit than they contribute will
pay a settlement fee. Now it becomes a lot harder to sign up legitimate
sucking customers that you know will create a settlement imbalance.

Ultimately, in all of these cases less efficient algorithms and uses will
be chosen in the direction that results in positive revenue, and waste
will occur.

I don't think that the future is as deterministic as you believe it would
be. For instance, what if you sign up a webcrawler, and then once they
have a good database, they host a search engine for multimedia content
with thumbnail pictures, video and audio clips. All of a sudden they
become a net sender of traffic. You can't control what your customers do
with their net connections.