Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Transaction Based Settlements Encourage Waste

  • From: David Diaz/I.P.O.F.-Netrail, Inc.
  • Date: Mon Aug 24 19:53:36 1998

hmmm

In a way aren't we doing this with CIR etc etc.

How about paying for differing levels or QoS.  This seem to offer better
utilization of the lines.  During off peak times EVERY packet would get
through even RED frames.  Maybe a "free" site like a shareware site would
have every frame tagged Red.  During heavy loads these sites would suffer
however customers paying for their traffic to be all green or mostly
green/ambre would be paying the brunt of the costs.

Obviously ATM offers tons of QoS features.  The drawback here is Im not
sure the salesmen in the backbones would understand the concept much less
explain it to the poor customers effectively.

If I have a personal web site I would not going with all RED frames (or
equivalent). If I were Fidelity Brokerage obviously I would bite the bullet
and pay for an all GREEN service since my customers are doing live time
sensitive transactions.  Isn't this more fair?  It would allow a greater
use of resources.  The issue then runs into QoS is easy to handle on the
ingress but not egress especially if it is to a different network over an
exchange point.

Dave


At 9:37 PM -0000 8/24/98, Sean Butler wrote:
>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.  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.
>
>
>My argument was that in addition to the peering settlement charges,
>each network would charge their customers for the traffic they generate.
>So, if you ask your web hosting customers to add traffic, and actually
>pay them for that, then my customers that request content from yours
>get a bigger bill than they used to.  My customers stop going to your
>customers site.  (I'll provide them with an itemized bill that lets them
>see what cost so much and why.)  Your customers figure out they are getting
>a free  internet connection from you (since you are now subsidizing their
>connection/traffic cost), but they are no longer getting any business
>from their customers.  I imagine they take off the extra traffic real
>quick.
>
>And the numbers I am talking about would be quite small.  Enough for the
>average dial user to retain a bill that is near $20/month.  However, for
>those that generate much more, they'd get billed more.  Now at the peering
>points, when you have thousands of dial in users requesting content, and
>you are on the short end of the traffic exchange in terms of byte count,
>so you'll have to pay the large content ISP, you can pass that on to
>your many dial customers.  It would be similar on the content size --
>you can charge based on the traffic they generate, but most likley, this
>will be a small small amount, since you be getting money from your peers.
>
>Again, this requires all ISP's to do per usage based fees -- not just one
>or two ISPs could start to do it, or they'd lose all their customers.
>I'm not saying to use the current flat rate costs *and* charge for
>usage, but lower the flat rate (or make it nothing or next to nothing)
>and then charge for usage.  Shouldn't those users that generate the most
>traffic on your network pay for it?
>
>For number 3, if you are paying for traffic you receive, you no longer
>get up and go to lunch with your internet connection running!
>
>One thing I hadn't thought about, that your post brought out...  If
>I cache, I am charging my customers for traffic they request, even though
>I only had to pay for it once... Not sure that passes the ethics
>committee.
>
>I know settlement based peering and usage based charges for your
>customers is not without many problems, but I think they can be
>worked out.  I think settlements without usage based charges has
>no chance, as traffic generators can then run free.  But when someone
>is paying for the traffic, bogus traffic would stop.  There may
>be some period of instability as all Internet customers get used
>to it, but I think it could come around.
>
>And it is my take that you can catch non-legit traffic, and if the
>penalties for creating such traffic are high enough, it would happen
>infrequently.  I know others feel that you can always generate
>bogus traffic that is not tractable, but if the technology is not
>there today, it is not far away.
>
>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


Thank you,
David Diaz
Chief Technical Officer
Netrail, Inc

email:   davediaz@netrail.net
pager: 888-576-1018
office: 888-NETRAIL


Colo facilities: Atlanta-NAP, Miami, Arlington, Chicago, San Francisco
888-NETRAIL for further information






Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.