Maybe someone could enlighten my ignorance on this issue. Why is there a variable charge for bandwidth anyways?
In a very simplistic setup, if I have a router that costs $X and I run a $5 CAT6 cable to someone elses router which cost them $Y, plus a bit of maintenance time to set up the connections, tweak ACLs, etc... So now there's an interconnect between two providers at 1 gigabit, and the only issue I see is the routers needing to be replaced within Z years when it dies or when it needs to handle a 10 gigabit connection. So it seems I should be able to say "Here's a 1 gigabit connection. It will cost $Q over Z years or you can pay $Q/Z yearly", etc... And wouldn't the costs go down if I had a bunch of dialup/DSL/cable/fiber users as they are paying to lower the costs of interconnects so they get content with less latency and fewer bottlenecks? -A On Thu, Jun 20, 2013 at 4:18 PM, Leo Bicknell <bickn...@ufp.org> wrote: > > On Jun 20, 2013, at 5:47 PM, Robert M. Enger <na...@enger.us> wrote: > > > Perhaps last-mile operators should > > A) advertise each of their metropolitan regional systems as a separate AS > > B) establish an interconnection point in each region where they will > accept traffic destined for their in-region customers without charging any > fee > > C) Buck up and carry the traffic their customers are paying them to carry. > > Least I just sound like a complainer, I actually think this makes rational > business sense. > > The concept of peering was always "equal benefit", not "equal cost". No > one ever compares the price of building last mile transport to the cost of > building huge data centers all over with content close to the users. The > whole "bit-mile" thing represents an insignificant portion of the cost, > long haul (in large quantities) is dirt cheap compared to last mile or data > center build costs. If you think of a pure content play peering with a > pure eyeball play there is equal benefit, in fact symbiosis, neither could > exist without the other. The traffic flow will be highly asymmetric. > > Eyeball networks also artificially cap their own ratios with their > products. Cable and DSL are both 3x-10x down, x up products. Their TOS > policies prohibit running servers. Any eyeball network with a asymmetric > edge technology and no-server TOS need only look in the mirror to see why > their aggregate ratio is hosed. > > Lastly, simple economics. Let's theorize about a large eyeball network > with say 20M subscribers, and a large content network with say 100G of > peering traffic to go to those subscribers. > > * Choice A would be to squeeze the peer for bad ratio in the hope of > getting them to pay for, or be behind some other transit customer. Let's > be generous and say $3/meg/month, so the 100G of traffic might generate > $300,000/month of revenue. Let's even say you can squeeze 5 CDN's for that > amount, $1.5M/month total. > > * Choice B would be to squeeze the subscribers for more revenue to carry > the 100G of "imbalanced traffic". Perhaps an extra $0.10/sub/month. That > would be $2M/month in extra revenue. > > Now, consider the customer satisfaction issue? Would your broadband > customers pay an extra $0.10 per month if Netflix and Amazon streaming > never went out in the middle of a movie? Would they move up to a higher > tier of service? > > A smart end user ISP would find a way to get uncongested paths to the > content their users want, and make it rock solid reliable. The good > service will more than support not only cost recovery, but higher revenue > levels than squeezing peers. Of course we have evidence that most end user > ISP's are not smart, they squeeze peers and have some of the lowest > customer satisfaction rankings of not just ISP's, but all service > providers! They want to claim consumers don't want Gigabit fiber, but then > congest peers so badly there's no reason for a consumer to pay for more > than the slowest speed. > > Squeezing peers is a prime case of cutting off your nose to spite your > face. > > -- > Leo Bicknell - bickn...@ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > > > > > >
