Dirk Harms-Merbitz <dirk@power.net> wrote:
Would you please describe any useful mechanism of traffic-based inter-backbone settelemts?
Computers (third party?) on the edges of my network count the number of packets that transit my network over a certain time period. Periodically I issue invoices.
Ok. How do you translate the number of packets into figure in $s? In a capitalist economy, price generally follows value. What is the value of a packet? It is not even clear if packet crossing from your network to my network gives _me_ any value. It can as well be for _your_ benefit. Since there's no way to determine value, the scheme is thus completely arbitrary; and therefore _is_ regressive. Economics 101.
Of course, other networks do the same. End users (including co-located computers) simply appear as connected networks that don't provide any transit, hence they pay for their connection.
They do it today. Where's the difference? You seem to forget that carrying traffic is only a part of network service; in fact, a lot of _value_ is in the _ability_ to communicate universally. That's what made Internet a killer to all those X.25 networks.
Because there is a real cost for long-haul packet transport.
Remember that I said "if the same amount of packets are transfered". The speed of my connection does not necessarily affect the number of packets that I'm transmitting.
When you lease an apartment landlord doesn't generally care if you don't sleep there six days out of seven. That's because he has (implied) obligation to provide adequate service during peak usage.
"Connection costs" is rent on transmission facilities, plus overhead (upkeep of the property, insurance, administration, etc).
No. That's "transmission cost", not "connection cost". The cost of me connecting to your network (not counting setup and so on) is the sum of the interface electronics on both ends and whatever link we need inbetween.
Connection costs are generally figured into non-recurring charges. They usually do not exceed costs of equipment and overhead.
Off on a tangent... creating bandwidth is somewhat like making computer chips. Making the first production Pentium (or whatever) processor costs billions. The second is a few cents. Here, laying the cable is expensive. Once it is in the ground, the cost for transporting another packet is almost zero.
This is an example of patently meaningless analogy. _Every_ business (even pyramid scams) has some capital costs. So what. Telcos lend money, put in fiber and than pay loans off from the resulting revenues. They can borrow capital internally, from their shareholders (in form of reduced dividends). The fact that tfiber is not loaded 100% all the time is figured in the user fees.
An interesting question is what do to with potential bandwidth/cpu cycles/free ram, i.e. what are the costs of not using available capacity? One answer is that the cost is zero until your competitor starts being more efficient then you are. See Soviet UNION vs USA.
There's no secret that the name of the game in the Internet backbones is "shove congestion back to competitor's backbone".
Back to networks... it would be logical to assume that whenever people deploy fiber they drop as much as they can afford at that moment.
You will be surprised. Sprint has 6 (six) strands of fiber in its trunks. The cost of putting in 100 strands was purely incremental, but then, some beancounters figured that those six strands will be good forever. Now, it's digging time again.
If that's true then there must be enourmous amounts of unlit fiber.
In some places. Generally, LDCs are out of capacity.
What's the total capacity going accross the atlantic or pacific?
Not much. It's not like surface cables, where the real cost is digging a tranche, and buying rights of way. It costs next to nothing to drop undersea cable off the ship; but the cable itself with all its hamstrung amplifiers costs a fortune.
How much of it is being used?
Practically all of it. BTW, it is generally priced in DS-0 chunks; i.e. when you get a DS-1, you pay the same as for 24 DS-0s.
I'd bet that there are many terabits of fiber that are not in use.
Not at all. The worst part of it, you can't just install WDM equipment at the ends, and get more capacity. Replacement of amplifiers in the existing undersea cable is about as costly as putting in new cable.
Yes, of course, the closer you get to what's technologically feasable, (the closer you move to the border to the future) the more expensive things become. I guess that's the main argument used to defend higher costs for faster connections.
Never underestimate bandwidth of 10 sq feet of fiber strands.
But we don't even need to go to that edge. Building gigabit, if not terrabit routers is amazingly simple and can be done with off the shelf technology.
Tell me about it.
Hey, a few Linux boxes interconnected with a few 100MB/sec ethernet switches in the right fashion would allow the creation of a super NAP that should outperform gigaswitches easily.
Not _that_ simple. I won't go into details on that; but so far the only known way to do that is pretty much covered by the pending patents.
Summary: I would not be surprised if the packet carrying capacity of the Internet could be increased by two or three orders of magnitude with surprisingly little investments. The real challenge is how to get people to do that.
Four orders. Then something different is needed. --vadim
Computers (third party?) on the edges of my network count the number of packets that transit my network over a certain time period. Periodically I issue invoices.
Ok. How do you translate the number of packets into figure in $s?
In a capitalist economy, price generally follows value.
What is the value of a packet? It is not even clear if packet crossing from your network to my network gives _me_ any value. It can as well be for _your_ benefit.
There's a much more simple flaw in this one. If you count packets (for TCP protocols anyway), every packet full of lovely http data doing one way tends to be matched by an equal number of ACKs. Hang on, that gives us zero settlement. Maybe not such a bad idea after all :-) Alex Bligh Xara Networks
The packets are of different size. We have been using the phrase "counting packets" in the sense of "counting the bytes in packets". Dirk On Mon, 27 Jan 1997, Alex.Bligh wrote:
Computers (third party?) on the edges of my network count the number of packets that transit my network over a certain time period. Periodically I issue invoices.
Ok. How do you translate the number of packets into figure in $s?
In a capitalist economy, price generally follows value.
What is the value of a packet? It is not even clear if packet crossing from your network to my network gives _me_ any value. It can as well be for _your_ benefit.
There's a much more simple flaw in this one. If you count packets (for TCP protocols anyway), every packet full of lovely http data doing one way tends to be matched by an equal number of ACKs. Hang on, that gives us zero settlement. Maybe not such a bad idea after all :-)
Alex Bligh Xara Networks
From what I know, routers (ciscos at least) tend to be packet-limited rather than bandwidth limited.. Isn't it a good enough first approximation to count packets rather than sum packet sizes? Ed -- On Mon, 27 Jan 1997, Dirk Harms-Merbitz wrote:
The packets are of different size. We have been using the phrase "counting packets" in the sense of "counting the bytes in packets".
Dirk
On Mon, 27 Jan 1997, Vadim Antonov wrote:
Ok. How do you translate the number of packets into figure in $s?
Lower limit would be total cost of me running my network divided by the number of packets transitting it plus my desired return on investment. Note how my lower limit changes with the usage of my network! Upper limit would be how much my competitor is charging for the same thing since meaningfull differentiation of IP transport is hard if not impossible.
What is the value of a packet? It is not even clear if packet crossing from your network to my network gives _me_ any value. It can as well be for _your_ benefit.
Nah, you originated the packet for reasons unknown to me. It transits my network which is what I charge for. There is no need to determine the value of that packet in an economic sense. You don't have to use my network, but I can put a price on it if you do.
In a capitalist economy, price generally follows value.
Scarcity creates value, hence the desire to differentiate. However, my willingness to pay your network for transit directly depends on the number of people that I can reach only (or better in some fashion, including cheaper) through your network.
You seem to forget that carrying traffic is only a part of network service; in fact, a lot of _value_ is in the _ability_ to communicate universally. That's what made Internet a killer to all those X.25 networks.
Well, you have a point in there being value in the _ability_ to communicate. That's why I'm willing to pay a limited entry fee of some sort, i.e. buy a computer and connect to you in the first place. Once I'm connected, however, transitting traffic through your network is the only thing that I'm interested in. Why else would I want to connect to your network? Of course, my desire to connect to you and my willingness to pay you for transit increases with the number of people that I can reach only or, if multi-connected, better in some fashion through your network.
That's because he has (implied) obligation to provide adequate service during peak usage.
Peak usage? I wonder how usefull that concept is when it comes to packet networks. An simplified example. Lets say I have a direct T1 between A and B. A starts to transfer 4 GBytes from B to A and uses 100% of the bandwidth. Then B starts another transfer of 4GBytes from A to B. Both now use 50% of the bandwidth and each transfer takes twice as long. I can still telnet between the two locations, even play quake - the load is hardly noticable for short transfers.
"Connection costs" is rent on transmission facilities, plus overhead (upkeep of the property, insurance, administration, etc).
No. That's "transmission cost", not "connection cost". The cost of me connecting to your network (not counting setup and so on) is the sum of the interface electronics on both ends and whatever link we need inbetween.
Connection costs are generally figured into non-recurring charges. They usually do not exceed costs of equipment and overhead.
That was my point. Why charge a higher _recurring_ fee for a faster connection?
Off on a tangent... creating bandwidth is somewhat like making computer chips. Making the first production Pentium (or whatever) processor costs billions. The second is a few cents. Here, laying the cable is expensive. Once it is in the ground, the cost for transporting another packet is almost zero.
This is an example of patently meaningless analogy. _Every_ business (even pyramid scams) has some capital costs. So what.
Why meaningless? There's no way to get the money back out once the cable is in the ground or the chip is being fabricated.
Back to networks... it would be logical to assume that whenever people deploy fiber they drop as much as they can afford at that moment.
You will be surprised. Sprint has 6 (six) strands of fiber in its trunks. The cost of putting in 100 strands was purely incremental, but then, some beancounters figured that those six strands will be good forever. Now, it's digging time again.
How do you know?
How much of it is being used?
Practically all of it. BTW, it is generally priced in DS-0 chunks; i.e. when you get a DS-1, you pay the same as for 24 DS-0s.
That pricing model is the problem. You are asked to pay for the potential of transporting data, not for transporting data. Circuit switching's heritage. Packet networks need a different pricing model.
Hey, a few Linux boxes interconnected with a few 100MB/sec ethernet switches in the right fashion would allow the creation of a super NAP that should outperform gigaswitches easily.
Not _that_ simple. I won't go into details on that; but so far the only known way to do that is pretty much covered by the pending patents.
Well, the key is some sort of any-to-any communication matrix for n routers. If n is small, even ethernet switches will do.
Summary: I would not be surprised if the packet carrying capacity of the Internet could be increased by two or three orders of magnitude with surprisingly little investments. The real challenge is how to get people to do that.
Four orders. Then something different is needed.
Hey, agreement... Dirk
--vadim
An simplified example. Lets say I have a direct T1 between A and B. A starts to transfer 4 GBytes from B to A and uses 100% of the bandwidth. Then B starts another transfer of 4GBytes from A to B. Both now use 50% of the bandwidth and each transfer takes twice as long.
I can still telnet between the two locations, even play quake - the load is hardly noticable for short transfers.
Since a T-1 is symmetric, wouldn't the transfer take approximately the same time whether A to B or B to A are both or individually transfering files (as long as they are going opposite directions??) So does the cost per byte get cut in half even though the price charged may stay the same ? If ROI is calculated on a 1-way model [ignoring ACKs] they with full duplex utilization ROI = PRICE - COST; ROI'=ROI+PRICE for full duplex operation.
That was my point. Why charge a higher _recurring_ fee for a faster connection?
Because (usually) there is a higher recurring potential traffic load from your site. What if you run one of the big Olympic or Superbowl web sites? And you get charged $1000 per month whether you have a 155Mbit connection or a 56Kbaud connection. Two months out of the year you could fill it, and the other 10 do nothing but send some email. The network you connect to has to be engineered for those peaks or they are not doing their job [IMO]. Granted, we usually talk about mid day peaks, etc, but what about convention halls that might keep a T3 or two around for big trade shows and only *really* use them on the weekends or weeknights or something. Their total (average, or even byte) traffic might not be that significant, but their bursts could be wildly high. -Deepak.
On Mon, 27 Jan 1997, Deepak Jain wrote:
That was my point. Why charge a higher _recurring_ fee for a faster connection?
Because (usually) there is a higher recurring potential traffic load from your site. What if you run one of the big Olympic or Superbowl web sites? And you get charged $1000 per month whether you have a 155Mbit connection or a 56Kbaud connection. Two months out of the year you could fill it, and the other 10 do nothing but send some email. The network you connect to has to be engineered for those peaks or they are not doing their job [IMO].
Granted, we usually talk about mid day peaks, etc, but what about convention halls that might keep a T3 or two around for big trade shows and only *really* use them on the weekends or weeknights or something. Their total (average, or even byte) traffic might not be that significant, but their bursts could be wildly high.
-Deepak.
Exactly. Current telco pricing (and engineering) focusses on _potential_ to transfer data. Like I said, this makes sense for circuit switched networks. The problem is that e are now dealing with packet networks. where there is little to no cost in having a wire plugged into your network that is not transferring packets In other words, applying circuit switching based thinking to data networks creates the wrong incentives for network operators since it may be cheaper to fire the top ten users of my network rather then increasing capacity. If you count bytes transitting your network then the incentive is to increase capacity. Dirk
On Mon, 27 Jan 1997, Dirk Harms-Merbitz wrote:
An simplified example. Lets say I have a direct T1 between A and B. A starts to transfer 4 GBytes from B to A and uses 100% of the bandwidth. Then B starts another transfer of 4GBytes from A to B. Both now use 50% of the bandwidth and each transfer takes twice as long.
T1's are bidirectional. Only the ACK's slow down the transfer a tiny bit.
That pricing model is the problem. You are asked to pay for the potential of transporting data, not for transporting data. Circuit switching's heritage. Packet networks need a different pricing model.
I think the success of the global Internet shows that packet networks don't need a different pricing model. The pricing model is part of the reason for their success. Michael Dillon - Internet & ISP Consulting Memra Software Inc. - Fax: +1-250-546-3049 http://www.memra.com - E-mail: michael@memra.com
participants (6)
-
Alex.Bligh
-
Deepak Jain
-
Dirk Harms-Merbitz
-
Edward Henigin
-
Michael Dillon
-
Vadim Antonov