 |
|
|
|
 |
St_Andrew
I <3 NYC

Registered: May 2003
Location: Stockholm, Sweden
|
|
|
| quote: | Originally posted by rabbitjoker
You pay your ISP for access to the network - that's it.
When you send data from point A to point B it traverses many, many networks (most of which are not your ISPs). Yes, the ISP also pays for access to the network - but belive me, data flows across many, many networks with little or no money changing hands.
What I believe they are trying to do with a data-levy to "guarantee quality and speed" is recoup the cost of network investment and ensure they have capital to invest in future networks.
I do not suspect that this levy will have consumers directly charged. However as the internet migrates more and more to a data-intensive network, with commercial entities using most of this data (the original internet was military, educational - non-revenue based) - it is fair to levy these data-dependent commercial entities for use of networks (networks that currently aren't taking part in the transaction from an economic perspective).
Again: I'm not certain if this is good or bad - it will very much depend on how it's rolled out (the devil is -always- in the details). |
As you already said (and as loconet pointed out), our ISPs pay to get connected to the Internet backbones, so there is your innitiative to maintain and expand networks, MONEY... As I understands it, most of the traffic that is in a certain ISP's network is also going to that ISP's network; Almost all inter-ISP traffic nowadays goes through backbones (contrary to the principles of the Internet, which is a big concern to terror attacks and such but anyway...).
Besides, (I think?) a system where every node on the internet got paid for every single byte you download would be close to impossible to implement. And it would be ineffective as shit and it's nothing we should strive for at all imo.
|
|
Jan-17-2006 21:13
|
|
|
 |
 |
malek
drinks your milkshake!

Registered: Nov 2001
Location: Montréal
|
|
|
Technologically its possible to enforce rules, on file types, origin, destination, size, protocols, etc etc etc...
But it'll be a hell managing all this bs.
Agreement for this site, for that site, heck, there's millions of sites, hundreds of ISPs.
Billions of agreements??
I don't think so.
Its a pandora box that will result in a loose-loose situation for both content vendors and ISPs.
___________________
[/IMG]http://i54.tinypic.com/ngycqo.png[/IMG]
|
|
Jan-18-2006 01:28
|
|
|
 |
 |
rabbitjoker
aural sadist

Registered: Aug 2002
Location: Toronto, ON, CANADA
|
|
|
I'm too tired to get into this in detail, because who knows - this is pure speculation, but to keep it simple, the way I'd see this type of thing working is (and I could be wrong):
1) Consumers will never be directly charged a levy since their data transfer involves SPENDING money (not MAKING money). Corporations who MAKE money via a product or service that involves significant data tx will be charged the levy (i.e. iTunes, Vonage, Google Video, etc).
2) 1000s of agreements for "priority"/"guaranteed" data tx service level would not be necessary. Agreements will only need to be reached with the backbone (which in reality is a handful of major fiber owners). Since fragmentation of the fiber happens so close to consumer - the fragmentors (consumer ISPs) will be large (the few phone/cable companies) *or* small. The large fragmentors will have clout to demand levy, the small fragmentors will not. Backbones plus large fragmentors still probably does not number over 50 companies.
3) The levy will not be for USAGE, but for service level (guaranteed quality levels). The charge is NOT for access (which is a business model we already have and all use), the charge will be for GUARANTEED LEVEL of service (once already accessed) when data is traveling on provider's network (provider being a traversed network, not main connective network).
Scenario: Currently iTunes has no service level guarantee with the 2nd, 3rd, Nth-hop networks that iTunes's MP3's travel along to get to the consumer. If iTunes's direction connection is via UU, UU providers service level guarantees to iTunes - but once the data leaves UU, it's a blackbox.
If during a transaction (purchase of MP3) iTunes's data travels to the consumer via iTunes-->UU-->Verio-->ISP-->Consumer, Verio has the opportunity to say to iTunes "Listen, your business is dependent on smooth data flow. We'll prioritize/guarantee service level your data when it crosses our network for a fee.". iTunes then works with UU on routing to ensure that iTunes data stays on "prioritized" backbones as long as possible.
The above scenario is not all that complex from an execution or technology standpoint. Frankly I'm surprised that it's taken this long for the major fiber owners to figure this out. Time to recoup costs baby!
Opportunity: If someone was smart they’d go out right now and sign priority agreements (not access/usage agreements) with the major fiber owners – strike good deals before the model is totally figred out. Package/build an (relatively) out of the box data routing system and license it to companies with main revenue streams are dependent/relying on prioritized data rx/tx. Cut the fiber layers in on a % of the license; allow smaller companies to get similar QoS as the big guys. I’m certain that there is/will be a 2nd or 3rd tier (companies smaller than the iTunes, Vonage) market for this type of service.
So much for being tired, LOL! Feel free to punch holes in this. The more holes we can plug, the better the business plan will be... 
___________________
- rabbit.joker [funny¿rabbit] | www.rabbitjoker.com |www.ddtt.org
Dark Dirty Tech Tribal. | Hands in air (trance) and feet on the floor (house).
Last edited by rabbitjoker on Jan-18-2006 at 03:39
|
|
Jan-18-2006 03:27
|
|
|
 |
 |
|  |
All times are GMT. The time now is 02:47.
Forum Rules:
You may not post new threads
You may not post replies
You may not edit your posts
|
HTML code is ON
vB code is ON
[IMG] code is ON
|
|
|
|
|
|
Contact Us - return to tranceaddict
Powered by: Trance Music & vBulletin Forums
Copyright ©2000-2026, Jelsoft Enterprises Ltd.
Privacy Statement / DMCA
|