Transaction Based Settlements Encourage Waste (was Re: B

Mailman List Mirror (Read Only)
1

Transaction Based Settlements Encourage Waste

I think everyone agrees that the above statement is true in today's Internet
model, where customers are charged flat rates for their connections. But if
we change the peering model, why should we not change the model for
charging customers? If we do that, then settlements can work, and the
problem of metrics for how to charge should become much easier...

Take the aggregate traffic from A --> B, and from B--> A, and whoever receives
more bits pays the other provider. Say it is A that has to pay B, as B is a
big
content provider and A is a big dial ISP. Now, if A charges $19.95/month flat
rate to all of its dial users, A instantly loses. But if A charges its dial
customers
based on the bits received, or time connected, perhaps it becomes more even.

Network A can't win in a settlement based peering relationship unless he passes
the costs on to his customers, and at flat-rates, whether it is dial up or
leased line,
that is not happening. So, charge the content provider for outbound *and*
inbound
traffic. This can and should be subsidized by advertisers, as the more 'hits'
that
site generates, the more $$ you can charge. (Of course, this only works when
advertisers are willing to pay to be on your site, but if they aren't
willing, either
your site has content that doesn't have mass appeal or the advertiser doesn't
want to be associated with your content. For the former, you probably aren't
getting enough hits to worry about usage based costs. For the latter, find
another
advertiser or someone else to pay...) For the dialup user, charge him a lower
fixed
monthly cost of, say $5, but charge him for the traffic to and from him.
What's the
cost? Whatever it takes to make money while remaining competitive!

There are still problems with DOS based attacks, but those need to be resolved
anyway. As for writing 'fraudulant apps' that generate asymmetric flows to
try to
'even out' the peering relationship, it doesn't work anymore for creating flow
in
to your own network. Your paying the other provider because they are sending
you more traffic than you are sending them. For the opposite direction, if you
can write an app that sends more traffic out to the other network, you'll need
a
valid host to talk to. I'm sure the other provider won't have one of their own
machines doing that, so you'll need a customer of the other network to receive
that traffic. But now that they are charged for it, that won't happen. (I'm
sure
someone out there can think of ways around this, but I imagine there are
solutions to them. If its fraudulent traffic, and you face serious fines and/or
periods of time where you have to shut down your network, would you really
take the chance?)

Of course, the first ISP that starts to do usage-based charges may stand a good
chance of losing many of their customers, so this would have to be Industry
wide. And
the peering charges would have to be the same (or at least on the same order of
magnitude) between all ISPs, or peering imbalances will quickly be created.
Thus,
there will most likely have to be, at a minimum, an Independent Peering
Council, or
at worst, government regulation, to make this happen. :frowning:

DISCLAIMER: I'm not advocating this solution, and it may or may not express
the views of my employer.

I should also state that I am doing my M.S. Thesis on "The Evolution of
Peering."
Any original ideas I see on nanog (or com-priv, where this discussion really
should
be) will be quoted as such!

Sean

2

For the opposite direction, if you
can write an app that sends more traffic out to the other network, you'll need
a valid host to talk to. I'm sure the other provider won't have one of their own
machines doing that, so you'll need a customer of the other network to receive
that traffic. But now that they are charged for it, that won't happen. (I'm
sure someone out there can think of ways around this, but I imagine there are
solutions to them.

(note, his was a receiver pays system)

You appear to be missing the point that there are perfect legitimate and
non fraudulent ways of increasing the amount of traffic generated. For
example, simply pay all your web hosting clients based on the amount of
traffic generated. Then instruct them on ways to maximize their revenue
using methods that don't overly annoy users. For example:

1) implement anticaching measures (both antibrowser cache and anti
transparent proxy cache)

2) make their pages automatically reload every minute to show some dynamic
indicator (say, the temperature and humiditty outside).

3) use lots of very long streaming data. They should have sound on every
page (and the sound files should be 3 weeks of data). That way if
somebody visits your client's site and then goes to lunch or home for the
weekend the web site is still generating revenue by playing this huge
sound file because the visitor's browser was left viewing your client's
nice site.

etc...

It really is only limited by your imagination. You can generate
legitimate, non fraudulent traffic in either direction in any quantity
desired. The reason people don't do this right now is that they have to
PAY for it. In any of these transaction settlement scenarios you end up
getting PAID for it in one direction or another and this causes waste.

Mike.

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

3

Mike,

   If both ends are paying for this traffic and the receivers
   continue to participate, then they must find it worthwhile.

/John

4

I think everyone agrees that the above statement is true in today's Internet
model, where customers are charged flat rates for their connections. But if
we change the peering model, why should we not change the model for
charging customers? If we do that, then settlements can work, and the
problem of metrics for how to charge should become much easier...

Take the aggregate traffic from A --> B, and from B--> A, and whoever receives
more bits pays the other provider. Say it is A that has to pay B, as B is a
big
content provider and A is a big dial ISP. Now, if A charges $19.95/month flat
rate to all of its dial users, A instantly loses. But if A charges its dial
customers
based on the bits received, or time connected, perhaps it becomes more even.

In a model where dial ISP A already pays some transit provider X for all
transit that isn't already carried by a peering relationship, it is
possible that settlement based peering will allow ISP A to peer with networks
that they wouldn't have been able to peer with earlier.

This may in fact reduce A's operating costs significantly over paying X
for shall-we-say "unoptimized" transit. Which in turn means A could (in
theory) reduces its costs to its customers and gain market share.

Obviously widely-peered transit provider X would be the big loser if A
could talk to
all of X's peers and pay them for the traffic they are transiting which
may represent the majority of the traffic that X was carrying. These new
peers may be glad to peer with A because A's settlements typically mean
more money in their pockets. In an environment where X's flows typically
balanced out payments X would make to peers, the loss of A and other
customers like A might mean that X is either a) saving settlement fees
(and losing revenue from customers A, etc) , or b) has to pay additional
fees because their flows don't even out the way they did before.

Network A can't win in a settlement based peering relationship unless he passes
the costs on to his customers, and at flat-rates, whether it is dial up or
leased line,
that is not happening. So, charge the content provider for outbound *and*
inbound
traffic. This can and should be subsidized by advertisers, as the more 'hits'
that
site generates, the more $$ you can charge. (Of course, this only works when
advertisers are willing to pay to be on your site, but if they aren't
willing, either
your site has content that doesn't have mass appeal or the advertiser doesn't
want to be associated with your content. For the former, you probably aren't
getting enough hits to worry about usage based costs. For the latter, find
another
advertiser or someone else to pay...) For the dialup user, charge him a lower
fixed
monthly cost of, say $5, but charge him for the traffic to and from him.
What's the
cost? Whatever it takes to make money while remaining competitive!

There are still problems with DOS based attacks, but those need to be resolved
anyway. As for writing 'fraudulant apps' that generate asymmetric flows to
try to
'even out' the peering relationship, it doesn't work anymore for creating flow
in
to your own network. Your paying the other provider because they are sending
you more traffic than you are sending them. For the opposite direction, if you
can write an app that sends more traffic out to the other network, you'll need
a
valid host to talk to. I'm sure the other provider won't have one of their own
machines doing that, so you'll need a customer of the other network to receive
that traffic. But now that they are charged for it, that won't happen. (I'm
sure
someone out there can think of ways around this, but I imagine there are
solutions to them. If its fraudulent traffic, and you face serious fines and/or
periods of time where you have to shut down your network, would you really
take the chance?)

I don't think many systems bill customer fraud into their billing model.
Credit cards for example typically eat 1-3% in fraud, but its typically
predictable and their business model supports it. The cost is split
amongst all customers, almost never born solely by the customer that
experiences the fraud. I don't think the occassional SMURF attack from a
university or other customer should be considered the norm rather than a
very low percentage of the traffic a typical large network carries (say
over 100MBit/s of sustained traffic) at any moment of the day.

How hard would it be to have access/portal-type customers be required to
disable directed-broadcast on their router interfaces on their contract
renewals? How many people would object? It seems like there is a
collective disinterest in addressing the problems of SMURFing at the
source, when nowadays virtually every university or access provider is
paying someone for their connectivity. And whomever is collecting those
fees can have their downstreams add that to their configuration settings
easily (just like when the same upstream has to call the customer to tell
them a circuit is being reterminated, or a router interface is changing
-- in theory).

Even providers who make more money (in theory) from usage-based pricing
typically try to stamp out SMURFing at the source end because it doesn't
look good to be carrying a zillion SMURF packets per second.

With the exception of a few networks who aren't very excited about
helping track down SMURF originators, most everyone is willing to filter
and provide whatever information they trap today.

Of course, the first ISP that starts to do usage-based charges may stand a good
chance of losing many of their customers, so this would have to be Industry
wide. And
the peering charges would have to be the same (or at least on the same order of
magnitude) between all ISPs, or peering imbalances will quickly be created.
Thus,
there will most likely have to be, at a minimum, an Independent Peering
Council, or
at worst, government regulation, to make this happen. :frowning:

-Deepak.

5

   If both ends are paying for this traffic and the receivers
   continue to participate, then they must find it worthwhile.

Don't you mean senders here? (You seemed to be proposing a senders pay
system.) If not, of course receivers would continue to participate, they
earn money under your scenario for each bit they receive!

If you did mean senders, the point was that the senders don't have control
because high volume legitimate non fradulent receivers would suck as much
data as possible from their sites in such a way to be indistinguishable
from any other legitimate use. Receivers would sit around all day
thinking of fun new legitimate nonfraudlent undetectable ways to do this.

Mike.

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