Re: Transaction Based Settlements Encourage Waste (was Re: B
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. :-( 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 ___________________________________ Sean Butler, CCIE #3897 IBM Global Services -- OpenNet Support Phone: 8-631-9809, 813-523-7353 Fax: 8-427-5475 813-878-5475 Internet email: sebutler@us.ibm.com
On Mon, 24 Aug 1998, Sean Butler wrote:
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 -------------------+ | Mike Leber Direct Internet Connections Voice 408 282 1540 | | Hurricane Electric Web Hosting & Co-location Fax 408 971 3340 | | mleber@he.net http://www.he.net | +---------------------------------------------------------------------------+
At 01:33 PM 08/24/1998 -0700, Mike Leber wrote:
You appear to be missing the point that there are perfect legitimate and non fraudulent ways of increasing the amount of traffic generated. ... It really is only limited by your imagination. You can generate legitimate, non fraudulent traffic in either direction in any quantity desired.
Mike, If both ends are paying for this traffic and the receivers continue to participate, then they must find it worthwhile. /John
On Mon, 24 Aug 1998, John Curran wrote:
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 -------------------+ | Mike Leber Direct Internet Connections Voice 408 282 1540 | | Hurricane Electric Web Hosting & Co-location Fax 408 971 3340 | | mleber@he.net http://www.he.net | +---------------------------------------------------------------------------+
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. :-(
-Deepak.
participants (4)
-
Deepak Jain
-
John Curran
-
Mike Leber
-
Sean Butler