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


  • From: Richard Irving
  • Date: Fri Aug 21 20:26:39 1998

Oops, intended for Nanog as well....
--- Begin Message ---
I'll play Dave...
Don't take this too seriously... Just hypothesizing...

Financial Model for Internet:

Origin fee, Termination fee, then "mileage bands" costing.

Origin Fee to Origin ISP,  (Dial up ISP's make money on this...)
Termination Fee to terminating ISP,  (Hosters with lots of hosts make $$
on this)
mileage fee = ds0 miles/s consumed .... 128K *2 miles * 1 second = 4
ds0/S miles.... ('Bone's make their money on this)

(All fee's *paid by* originator of syn..)

[ There is a joke in that..... ;) ]

***As the originator of syn, *actively requested* content.***

(No passive bill generation for *me*, thank you..)

Mileage fee paid to owners of circuit(s) in path based on
DS0 Mile/Seconds

Example, [ignore numbers, just BS'n it for now....]

   BBN customers clicks on "" hosted at Exodus. (2cents
BBN *if* completed)

   BBN opens a path to exodus... 

   100 ds0 miles across BBN at 64K, 800DS0 miles to Verio, 100 Miles to

   And terminates to Exodus server... (Origin of ACK) (2 cents Exodus)

    Transmission consumes 64k , transmitted over 1 second.

    Total Mileage/Seconds Consumed = 1000 Ds0 M/S

    1 cent BBN, 8 cents Verio, 1 cent Exodus.

    Collection falls on BBN, dispersal as follows:

    BBN collects from customer,
    Pays Self (Original SYN, Mileage) , Pays Verio (Remaining
    Verio Pays self (Mileage - [Exodus Mileage + ACK]),
    Verio Pays Exodus (Mileage + ACK).
    Or, maybe BBN Collects: Pays Verio, and Exodus... 

    End of transaction:

       BBN = 3 cents
       Verio = 8 cents
       Exodus =  3 Cents.

So, Why have lots of dialup ?    Origin Fee's.
So, Why have lots of Hosts ?     Termination Fee's
So, Why have lots of Circuit ?   Mileage fee's.
Slow Host, Slow Path ?           Reduced transmission speed, 
                                 less DS0/Seconds per mile.
                                 Same cost, longer time.
                                 Less Acks per second. 
                                 Less users serviced......
Fast Host, Fast Net              More DS0/Seconds Per Second.
                                 Same cost, less time.
                                 More Ack's per second.
                                 More users serviced.

  Dialup's quit getting *all* the money from users who consume someone
*elses* circuits....

  Hosters have motivation to host. (Lots of ACK's)

  'Bones quit trying to figure a way to make hosters, and dialups, pay
bandwidth consumed in *any* direction... 

   (X)SP's with lots of all the above, make money on *all* the above.


   I see a lot of 'Bone's [I won't mention big names] who did designs
based on the original 9:1 (7:1,etc) aggregation ratio's 

 [remember "can't *really* fill a T days" ?, Erlangs, this was *NOT*]
(This all changed when "Slow Start" started making more effective use
 of the bandwidth, buffers deepened, 
 edges increased in capacity.. 14.4 vs 52k vs ISDN,
 and "Continental Latency" dropped from typical 250ms to typical 80ms)

 who are now being creamed with congestion and are trying to declare
*NOT* part of the internet, and want money to even PEER with your
..... trying to generate enough revenue to pay for their
network.... (As they are only charging enough to make money on the
 9:1 model)

  Rather than raising their prices so they can afford enough network 
 to actually *service* their customers, (IE get them *to* and *from*
 the internet)  and losing market share,
 they figure they have enough market share
 to make us pay for their own networks shortcomings.... (the 9:1 Model)
 IE: Too many  customers, not enough bandwidth, nor margin, to fix it..

  With this change "Lots of Circuit = Lots of DS0 Mileage Miles...."
It might motivate more backbone, instead of more aggregation...


Out flow != In flow ? Doesn't matter. Mileage DS0 seconds determined by
adding both IN and OUT END-TO-END *completed* flows together and divide
by 2.

 127K In 1 second, 1K out over 1 second = 64K seconds. Or, 1 DS0 second.

(Lost traffic ? Not end to end... Proof ? Thoughts ?)

 Now, I am *not* recommending this... This is just a parallel
to the telco fabric pricing. (An already proven model)
 But, anything you do with respect to this
eliminates the "Surf all you can" attitude, and I am not sure that 
would facilitate the internet
that we are all trying to encourage....

Changes for multicast ???? (Leaf Join initiation fee, 
split by origin and termination, plus mileage bands?
 even works well for aggregation, 
as multiple users can consume same "Mileage Band" flow)

Thoughts ?


PS:   800 Service  = Host Payed Pathway



Dave Rand wrote:
> [In the message entitled "Re: BBN/GTEI" on Aug 21, 13:48, Michael Dillon writes:]
> >
> > If such scalable peering already existed, I'm convinced that the current
> > situation between Exodus and BBN would not have developped. So while those
> > two companies figure out how to handle their relationship, maybe we could
> > all learn from this and figure out a way to make peering work in a more
> > scalable manner.
> >
> I'm all for this.  What metric(s) shall we use?
> Traffic is an obvious one.  Is that measured in packets per second, or bits
> per second?  Since, in the USA (where the vast majority of traffic
> originates) circuits are provisioned as full duplex, _does it matter_ which
> direction the bits are flowing in?  You _should_ have provisioned adequately
> for the flow, in any event.  That is, if you care about how much bandwidth
> your customers can use.
> Assuming it does matter, in which direction does the value flow?  Towards
> the recipient, because the infrastructure for provisioning hundreds of DS3s
> costs more, and the provider is not billing correctly for it?  Or is it
> towards the content provider, because the infrastructure for provisioning
> hundreds of web servers costs more, and the provider is not billing correctly
> for it?
> Another one is route-miles.  A provider with 1,000 route-miles of circuits
> 'obviously' has less value than a provider with 10,000 route-miles of
> circuits.  How does speed of those circuits factor in?  Perhaps the metric
> should be DS0-route-miles (64K-circuits per mile).  Of course, one WDM dark
> fiber run of 250 miles would nuke this metric.
> How about dollar value of the network, in total bills paid to the telcos?
> Does this mean that networks that are owned by telcos have an almost-zero
> cost, or an "full retail price" accounting cost?  Are networks that
> have reciprical agreements with telcos unduely penalized, or do they
> benefit?
> Another good metric might be number of customers.  As a fine point, does an
> ISP transit customer of a network count as one customer, or does it count as
> 30,000 customers (the number of dialup customers serviced by that ISP).
> Does a web content provider count as one customer, or as 5,000 customers
> (the number of his hosting customers).  What about special cases that offer
> free email accounts and/or web pages, that have thousands or millions of
> customers?
> How about number of network advertisments, or routes?  Would this lead
> to silly announcements (de-aggregation) to 'equalize' the number of
> routing announcements?
> We haven't even got to the hard points, which is *how much* each of
> these metrics are 'worth'.
> We also haven't begun to address sites like,
>, and the like.  Nor networks with plently of suck bandwidth
> (but not much content) such as MSN and AOL.
> It's harder than it looks on the surface, folks.  Clues appreciated.
> --
> Dave Rand
--- End Message ---

Discussion Communities

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

Merit Network, Inc.