IP packets are not mapped one to one with ATM cells.
One arbitrary length IP packet, whose size is chosen by the source device, is mapped over the top of a number of ATM cells, using the AAL5 or ATM Adaption Layer 5 method.
Some people say there is nothing wrong with NAT. To them, I'd propose the following analogy.
Imagine you had only ever seen the world through empty toilet rolls - ie. without your peripheral vision. If that is all you knew, that is as good as you'd think the world was. IPv6, restoring full and unique device addressing, restores the Internet's "peripheral vision" - it removes the Internet's empty toilet rolls.
We may have already missed out on the next "killer app" after the WWW, as it required unique, end-to-end addressing, and the prevalance of NAT prevented it from being deployed.
Isn't javascript open source ? I mean, you download the javascript source to run it.
Why do you distrust javascript so much, when it is open ? You can review the code to determine what it is doing, and, if you are happy, enable it temporarily just for that web site.
The warning follows several incidents in the city after midnight on Friday night when a busload of up to 50 Finks motorcycle club members bombarded venues, assaulting staff and refusing to pay for drinks.
Boring ? Just got to know where to go.
An eyewitness, who refused to be named, told the Sunday Mail the Finks first went to Heaven nightclub on West Tce, then to Cargo in Hindley St, Traffic in North Tce, and The Garage, in Waymouth St - where a violent brawl involving the Finks occurred in October.
The bar manager who suffered serious facial and head injuries in that incident was again punched in the face early yesterday, resulting in stitches to his mouth.
Was introduced to this guy a week ago, and he bought me a drink. He is a good guy. Hope he gets better soon.
Of course there must be SCO IP in Linux, because the bz2 tarball is over 35 MB.
Golly, there probably is *shitloads* of SCO IP in Windows XP - it's supposed to be over 60 million lines of code. I'm sure the bz2 tarball of the XP kernel is over 35 MB too !
Unfortunately, unless you buy a cert from one of the officially blessed cert authorities, your users get this ugly-looking "security warning" popup from their browser. While this is fine for clued individuals, or internal sites and so on, things that are public-facing are more sensitive to that sort of thing.
It galls me every time I have to give someone on the officially "blessed CA" list money to do something I can do for myself in less time, but I don't know of an alternative that allows the public users of a secure website to not get alarming messages on their browser when they try to give us money.
The public at large don't understand seriousness of the dialog box security alert, so they don't want to see it. How do you get rid of it ? You get your Certs signed by Verisign or some other CA your browser automatically trusts. So you aren't paying Verisign or another CA because you trust them, you are paying them to get rid of an annoying dialog box, and that is all.
I did see one posting that may be more accurate... it said that ISPs have neglected to impliment it (are blocking it) and their staffs just don't have the understanding to enable it (and politics get in the way as well at this point).
That was more what I was getting at, and, as a result of that, it probably cause the first problem you mentioned.
Because there isn't all that much demand for, or availability of, multicast based applications, the general networking population don't necessarily have knowledge or skills, or even awareness of it, so they either don't enable it if their equipment supports it, or don't know to ask for it when buying equipment.
There is at least one existing commercially available ATM switch with 10Gbit/s (STM-64c) native ATM interface that I'm aware of: Cisco's MGX 8950 and it's AXSM-1-9953-XG module:
http://www.cisco.com/en/US/products/hw/switches/ps 1938/products_configuration_guide_chapter09186a008 017a4e1.html#1529475
Not knowing all that much about ATMs use in Telco network (well, I probably know a bit more than the person), would I be right in guessing that this type of interface would be used to aggregate up VCIs under a VPI or multiple VPIs ? As you can't generate or receive ATM traffic at these speeds, aggregation is the only use I can see for this type of equipment, and I'm a bit curious as to how it is done or used.
To deploy multicast fully and usefully across the Internet, all of the routers in the Internet would have to be upgraded or enabled to support multicast networking and protocols.
The cost of doing this is just way too much, when compared with the costs of operating unicast media streams.
Further more, because the Internet is really a network of networks, and not just owned by one entity, it would not be possible to ensure, and may never be possible to achieve 100% multicast capability across it. Which means that a portion of your customer base is only likely to have unicast connectivity. If that unicast potion is in the minority, then the impetus to fully deploy multicast may be created.
Of course, that becomes a chicken-and-egg problem. At this point in time, there is no reason to deploy multicast, as unicast is working acceptably. Until unicast stops working acceptably, there will not be enough demand for multicast. No demand means there will be no inertia to deploy it widely.
Well, Australia is probably considered a Western country:-)
in New Zealand, for example, there isn't bandwidth to throw at the problem. Upstream providers want around $115 USD/month per 64kb channel for CIR bandwidth.
I'd suggest a significant part of the reason for that relatively high cost is the requirement for an end-to-end CIR.
The efficiency and economics of a packet switched network is based on the fundamental assumption of fair and equal sharing of available bandwidth, where everybody suffers if there isn't enough capacity. If you want priority handling pr dedicated bandwidth, you need to expect to have to pay for it.
As an analogy, we all share the road, and, as long as there is enough capacity in the system, we all get to where we need to go in a reasonable and acceptable timeframe, constrained by the speed limits in place.
Of course, for some (rich) people, the inherent delays in a shared road infrasture, as well as the possiblity of encountering congestion are not acceptable. So they buy a helicopter instead, which gives them their own "dedicated" channel to their destination (forgetting for the momement they also have to share airspace).
Your 64 Kbps CIR link is the equivalent to the helicopter solution. If you truely need it, you are likely to be willing to pay for it. If you don't need it, or can't afford it, maybe an IPsec VPN over the Internet will be sufficient, yet still provide acceptable performance.
Other expensive markets include parts of Russia, South America, Africa... all places with millions of Internet users.
Are you saying there are actually (today) millions of Internet users in these countries, or are you saying there are potentially millions of Internet users in these countries ?
If you are saying there are actually millions of Internet users in these countries, then the carriers providing Internet bandwidth should be already be reaping enough revenue to ensure that their core bandwidth grows quickly enough to support their edge bandwidth growth. If they aren't, then it isn't a networking problem, it is a business problem - they aren't charging enough for their product to continue to be in a financial position to provide it.
I'm not necessarily saying you are wrong about the IP claim, but it always comes up, and I'm yet to see any authoritive statement that it is actually true.
I also think there is confusion about what "the open source community" are asking for. They are not asking for the IP that is embedded in the driver to be revealed. This seems to be a common assumption. That IP would be revealed if Nvidia open sourced their driver code. The open source community like vendors who open their driver code, because it saves time, but that certainly isn't what is being asked for.
What the open source community are asking for is how to ask the hardware to perform a particular task, where the steps to perform that task is already embedded in the hardware ie. open hardware programming specifications. They feel that it is their right to be able to have that information, as they own, rather than license, the equipment. As an analogy, if you buy a car, would you be happy if the vendor then told you where you could or couldn't drive, or how you were to drive. You would turn around and say "Its my car, I'll do with it what I like!". Just like Nvidia shouldn't care if you buy one of their video cards, and then use it to stir paint in a can. They have already made their profit, as they sold it to you. They won't get any more revenue from you if you use it to display graphics, or use it to stir paint.
You could say that how to get the card to perform a task is where the IP is. That may be the case, although consider this; the PCI / AGP bus is an open specification, with commands going across it in clear text ie. there is no encryption. Anybody who can afford a PCI / AGP bus analyser ($100K maybe?) could easily reverse engineer what the Nvidia drivers are doing.
Of course, you typical individual can't afford a PCI / AGP bus analyser, so your IP is protected from them. But is that who you need to protect your IP from ? Shouldn't you be more worried about protecting your IP from your competitors eg NVidia need to protect it from ATi ? Wouldn't a company like ATi easily be able to afford a PCI/AGP analyser, easily be able to pay engineers who know how to use one. In summary, the openness of the PCI/AGP bus doesn't protect the programming techniques very well, if at all, from the people you may most want to protect it from.
BTW, you don't necessarily need an PCI/AGP bus analyser to reverse engineer a driver. Recently, a GPL driver was developed for the NVidia ethernet network cards, for which NVidia only published a binary driver. What did NVidia achieve by only releasing a binary driver ? The only thing they achieved was to possibly reduce the number of people who might buy their hardware. forcedeth: A new driver for the ethernet interface of the
NVIDIA nForce chipset, licensed under GPL.
That is why I can't see any sense in the IP claim, unless people (and Nvidia themselves) are confused between a request for open hardware programming specs, and a request for open sourcing the proprietory driver source code.
But I'd consider additional bandwidth to be an operational expense. Sure, the capital expenses are also going to be higher, but unless you *own* the bandwidth (i.e. you're a backbone provider) you'll have a monthly lease on it.
And I do too, forgot about it, until I re-read my post, after it was posted.
Still, the only "opex" cost associated with pure bandwidth, other than the expense of the bandwidth itself (which you are fundamentally getting your customers to directly pay for), is to have your accounting section send off a monthly, quarterly or some other periodic cheque (check if you are in the US). Much simpler (and cheaper) than having techos who understand QoS, networking, packets and all the other complicated networking stuff watching the network, prodding and playing with it to keep it running optimally.
cheaper to just throw bandwidth at the problem, and then avoid the operational costs of futzing around with proxy servers, with their inherent disk space, OS patch, proxy software patch, hardware failure, etc. etc., problems.
As commonly in life, in networking, complexity is the enemy.
They can't build it, as the cell per second processing load is too high for current technology
They can't afford to build it, as the customer won't pay, as it will be too expensive, caused by the cost of coming up with a solution to the first point.
They don't even go to OC48c or 2.5 Gigabits speeds with ATM.
ATM is being phased out of carrier backbones because it is overly complicated, and therefore overly expensive for what carriers need. Packet Over Sonet/SDH (POS) or Ethernet is taking over.
Just because a technology is being used doesn't make it successful, in particular when compared to its original design goals. It may only mean that there was not alternative at the time. As soon as something cheaper, yet as or more effective comes along (eg POS, 10Gbps Ethernet), the less effective technology will be replaced and / or avoided.
I think you are saying that "QoS" is necessary to VoIP, because if VoIP is flakey, the end users won't use it.
I then think you are really saying that VoIP is a latency sensitive application, so the network has to be engineered to meet the latency requirements of VoIP.
The issue then is how you meet those latency requirements ?
There are a couple of ways you can do that:
Ensure that there is enough capacity in the network such that it very rarely gets congested to the point where VoIPs latency requirements cannot be met.
Provision less capacity in the network, and then use various managed QoS mechanisms, such as CBQ, etc, to manage the congestion in the network when it occurs. Congestion in this network will occur much more often than the network with the additional capacity.
So which solution do you choose ?
As a rule, simplicity usually wins out. Maybe not in the first instance, but eventually, over time, things tend towards simplicity. Simplicity tends to be cheaper, and everybody aims for cheaper. There is always a demand in the market for cheaper, and commonly, the only way to achive cheaper is to go simpler.
Costs of running a network are broken into two areas - Capital Expenses (ie. usually initial, setup costs), and Operational Expenses (ie. ongoing running costs).
Comparing the above solutions, the one thing the second has that the first doesn't have is a lot of active bandwidth management and measuring. This can be very expensive to do, when you consider the number of devices and links within the network. It can also be very complicated, as it increases the number of protocols running in the network, and the number of people who need to be paid to watch and operate the network. The QoS solution is not the simpler of the two solutions. The second solution has higher operational expenses than the first.
Comparing the two solutions using capital expenses, I'd suggest the initial set costs of the first solution would only be in the order of about 20% more than the second, accounted for by the additional bandwidth expenses incurred.
The question to ask then is "how long will the 20% cheaper start up cost of the second solution be absorbed by the higher operational expenses of the second solution ?"
My answer is "not all that long". Which indicates that the "throw bandwidth at it" solution, in the longer term, is both simpler and therefore will be cheaper.
As further evidence, consider the Internet. There is very little QoS management on the Internet, with the exception of a recommendation of a default queuing alorithm -
Random Early Detection. The Internet solution is to "throw bandwidth at it". Yet most of the time Internet provides good enough "QoS" to allow people to make voice and video calls across it. Certainly good enough to sustain voice calls that are equivalent or better than mobile or cell voice calls eg GSM. Based on that evidence, you don't need to implement QoS technology inside the network to sustain the latency required for typical VoIP applications.
Because I have glossed through it (a number of months ago), and none of the comments up until now show any evidence of people actually understanding Prof Odlyzko's arguments.
The goal of ATM was to replace network stacks such as TCP/IP, as evidenced by all the different QoS options available (VBR, CBR, UBR etc), as well as all the AAL layers (1 - 5, I've heard a AAL6 might be coming). Switched Virtual Circuits were supposed to be the dominant way connections were set up.
Why has it failed ? There are primarily two reasons:
It is primarily deployed, if not always deployed, by telco customers as Permanent Virtual Circuits. The Telco's love SVCs, as they can then charge per connection setup. Customers love PVCs, as it is then a fixed price service. The customer won. So the SVC mechanisms within ATM are somewhat redundant, as well as the SVC signaling mechanisms.
The dominant application of ATM is to run TCP/IP over it. This is a waste of resources, as TCP is providing a lot of the facilities ATM was intended to provide. ATM is incredibly over engineered for the most common service it is being used for, namely, link layer or layer 2 point to point, best effort connections.
Another technical restriction ATM has is due to the 53 byte Cell size. As bit rates increase, the number of cells per second increase, which increases the number of cell headers per second the ATM device has to process, which then increases the computational requirements of the ATM device. This is putting huge demands on CPU/ASIC technology, such that it is becoming impossible to build an ATM interface that can operate fast enough. For example, you can already get 10Gbps SONET and Ethernet interfaces, but I'm not aware of any 10Gbps ATM interfaces. They may exist, but they are "late to market", and very expensive, when compared to alternative 10Gbps techologies.
On a related note, the header per second processing issue is also going to be a problem with ethernet in the near future, which one of the reasons why jumbo / 9000 byte ethernet frames is slowly being adopted.
Finally, a note to those who think ATM is successful just because it is being used. You really need to consider and compare the original goals of the technology verses how it is commonly been used. As ATM typically isn't used at all for what it was designed for, then it is a design failure, and an over engineered one at that.
We all complain about how much our broadband Internet access costs. Unfortunately, ATM has contributed significantly to those high costs, because the vendors who have sold ATM want to re-coop all their R&D costs for most of the features of ATM that are never used, so they charge high prices for ATM technology. There are a few things ATM does that other technologies don't, and there haven't been any alternatives, so we have been stuck with ATM, and have been stuck paying for its over engineering.
I like Cringely too - I think his "Accidental Empires" book is an excellent read.
My only suggestion is that if you are going to say his predictions are vague, you need to provide a few more examples than just one. That tends to suggest that is other 14 aren't !
Being very conservative, let's say each hardware device supported by Linux requires two.c source files. Using that assumption, that calculates out to 1109 open source drivers in the current Linux kernel. That is a lot !
Of course, most drivers are only contained within one.c file, and in a number of cases, multiple devices from different vendors may be supported by a single.c file, as the they have used underlying chipsets from the same third party. So the current Linux kernel would support say 3/4 of that 2218 figure, or 1663 devices, which all have fully open source drivers. The figure is probably significantly higher, possibly even greater than the 2218, but we'll stick to 1663 for this example.
Let's divide that 1663 devices by 10 to get the number of manufacturing vendors. Of course, the figure is likely to be much lower than 10 devices per vendor, probably 5 or less, maybe with an average of 2. However, let's assume 10. That indicates that 166 vendors have 'got' the open source idea, and published their programming specs, or even contributed GPL licensed drivers.
Linux driver support may appear to be broken because the two major graphics card vendors don't publish programming specifications. However, 2 vendors holding out, compared at least 150 or more who get open source, doesn't make Linux driver support broken.
The Linux development model has succeeded, as has the Linux philosophy on driver development. It is only the few, high-profile "bad apples" that make it appear to have not been successful.
Slashdot Mirror
IP packets are not mapped one to one with ATM cells.
One arbitrary length IP packet, whose size is chosen by the source device, is mapped over the top of a number of ATM cells, using the AAL5 or ATM Adaption Layer 5 method.
I don't think this author understands the Internet architecture, nor IPv6's design goals. Perhaps he should before he critiques it.
Here are the essential URLs :
RFC 1958 - Architectural Principles of the Internet The end-to-end argument demands that all communicating devices each have a unique network layer address.
RFC 1752 - The Recommendation for the IP Next Generation Protocol The design goals of IPv6, including a critque of the proposals for it, including TUBA - TCP and UDP with Bigger Addresses.
He may also be interested in learning why NAT is not so "perfect" or even "good enough" solution :
RFC 2993 - Architectural Implications of NAT
Things that NATs break
Some people say there is nothing wrong with NAT. To them, I'd propose the following analogy.
Imagine you had only ever seen the world through empty toilet rolls - ie. without your peripheral vision. If that is all you knew, that is as good as you'd think the world was. IPv6, restoring full and unique device addressing, restores the Internet's "peripheral vision" - it removes the Internet's empty toilet rolls.
We may have already missed out on the next "killer app" after the WWW, as it required unique, end-to-end addressing, and the prevalance of NAT prevented it from being deployed.
Isn't javascript open source ? I mean, you download the javascript source to run it. Why do you distrust javascript so much, when it is open ? You can review the code to determine what it is doing, and, if you are happy, enable it temporarily just for that web site.
for non-commercial use, and non-commercial sharing.
Bikie warning at nightclubs
The warning follows several incidents in the city after midnight on Friday night when a busload of up to 50 Finks motorcycle club members bombarded venues, assaulting staff and refusing to pay for drinks.
Boring ? Just got to know where to go.
An eyewitness, who refused to be named, told the Sunday Mail the Finks first went to Heaven nightclub on West Tce, then to Cargo in Hindley St, Traffic in North Tce, and The Garage, in Waymouth St - where a violent brawl involving the Finks occurred in October.
The bar manager who suffered serious facial and head injuries in that incident was again punched in the face early yesterday, resulting in stitches to his mouth.
Was introduced to this guy a week ago, and he bought me a drink. He is a good guy. Hope he gets better soon.
Of course there must be SCO IP in Linux, because the bz2 tarball is over 35 MB. Golly, there probably is *shitloads* of SCO IP in Windows XP - it's supposed to be over 60 million lines of code. I'm sure the bz2 tarball of the XP kernel is over 35 MB too !
IP version numbers Damn, this isn't lame, hope it isn't lame enough now.
Unfortunately, unless you buy a cert from one of the officially blessed cert authorities, your users get this ugly-looking "security warning" popup from their browser. While this is fine for clued individuals, or internal sites and so on, things that are public-facing are more sensitive to that sort of thing.
It galls me every time I have to give someone on the officially "blessed CA" list money to do something I can do for myself in less time, but I don't know of an alternative that allows the public users of a secure website to not get alarming messages on their browser when they try to give us money.
The public at large don't understand seriousness of the dialog box security alert, so they don't want to see it. How do you get rid of it ? You get your Certs signed by Verisign or some other CA your browser automatically trusts. So you aren't paying Verisign or another CA because you trust them, you are paying them to get rid of an annoying dialog box, and that is all.
I call that money for jam.
Linus Torvalds on 64bit desktops
Linus Torvalds on 64bit desktops
I did see one posting that may be more accurate... it said that ISPs have neglected to impliment it (are blocking it) and their staffs just don't have the understanding to enable it (and politics get in the way as well at this point).
That was more what I was getting at, and, as a result of that, it probably cause the first problem you mentioned.
Because there isn't all that much demand for, or availability of, multicast based applications, the general networking population don't necessarily have knowledge or skills, or even awareness of it, so they either don't enable it if their equipment supports it, or don't know to ask for it when buying equipment.
There is at least one existing commercially available ATM switch with 10Gbit/s (STM-64c) native ATM interface that I'm aware of: Cisco's MGX 8950 and it's AXSM-1-9953-XG module: http://www.cisco.com/en/US/products/hw/switches/ps 1938/products_configuration_guide_chapter09186a008 017a4e1.html#1529475
Not knowing all that much about ATMs use in Telco network (well, I probably know a bit more than the person), would I be right in guessing that this type of interface would be used to aggregate up VCIs under a VPI or multiple VPIs ? As you can't generate or receive ATM traffic at these speeds, aggregation is the only use I can see for this type of equipment, and I'm a bit curious as to how it is done or used.
Because you then have to retransmit the other 100 or more cells that were carrying the single IP packet.
To deploy multicast fully and usefully across the Internet, all of the routers in the Internet would have to be upgraded or enabled to support multicast networking and protocols.
The cost of doing this is just way too much, when compared with the costs of operating unicast media streams.
Further more, because the Internet is really a network of networks, and not just owned by one entity, it would not be possible to ensure, and may never be possible to achieve 100% multicast capability across it. Which means that a portion of your customer base is only likely to have unicast connectivity. If that unicast potion is in the minority, then the impetus to fully deploy multicast may be created.
Of course, that becomes a chicken-and-egg problem. At this point in time, there is no reason to deploy multicast, as unicast is working acceptably. Until unicast stops working acceptably, there will not be enough demand for multicast. No demand means there will be no inertia to deploy it widely.
You're showing a very Western bias there...
Well, Australia is probably considered a Western country :-)
in New Zealand, for example, there isn't bandwidth to throw at the problem. Upstream providers want around $115 USD/month per 64kb channel for CIR bandwidth.
I'd suggest a significant part of the reason for that relatively high cost is the requirement for an end-to-end CIR.
The efficiency and economics of a packet switched network is based on the fundamental assumption of fair and equal sharing of available bandwidth, where everybody suffers if there isn't enough capacity. If you want priority handling pr dedicated bandwidth, you need to expect to have to pay for it.
As an analogy, we all share the road, and, as long as there is enough capacity in the system, we all get to where we need to go in a reasonable and acceptable timeframe, constrained by the speed limits in place.
Of course, for some (rich) people, the inherent delays in a shared road infrasture, as well as the possiblity of encountering congestion are not acceptable. So they buy a helicopter instead, which gives them their own "dedicated" channel to their destination (forgetting for the momement they also have to share airspace).
Your 64 Kbps CIR link is the equivalent to the helicopter solution. If you truely need it, you are likely to be willing to pay for it. If you don't need it, or can't afford it, maybe an IPsec VPN over the Internet will be sufficient, yet still provide acceptable performance.
Other expensive markets include parts of Russia, South America, Africa... all places with millions of Internet users.
Are you saying there are actually (today) millions of Internet users in these countries, or are you saying there are potentially millions of Internet users in these countries ?
If you are saying there are actually millions of Internet users in these countries, then the carriers providing Internet bandwidth should be already be reaping enough revenue to ensure that their core bandwidth grows quickly enough to support their edge bandwidth growth. If they aren't, then it isn't a networking problem, it is a business problem - they aren't charging enough for their product to continue to be in a financial position to provide it.
I'm not necessarily saying you are wrong about the IP claim, but it always comes up, and I'm yet to see any authoritive statement that it is actually true.
I also think there is confusion about what "the open source community" are asking for. They are not asking for the IP that is embedded in the driver to be revealed. This seems to be a common assumption. That IP would be revealed if Nvidia open sourced their driver code. The open source community like vendors who open their driver code, because it saves time, but that certainly isn't what is being asked for.
What the open source community are asking for is how to ask the hardware to perform a particular task, where the steps to perform that task is already embedded in the hardware ie. open hardware programming specifications. They feel that it is their right to be able to have that information, as they own, rather than license, the equipment. As an analogy, if you buy a car, would you be happy if the vendor then told you where you could or couldn't drive, or how you were to drive. You would turn around and say "Its my car, I'll do with it what I like!". Just like Nvidia shouldn't care if you buy one of their video cards, and then use it to stir paint in a can. They have already made their profit, as they sold it to you. They won't get any more revenue from you if you use it to display graphics, or use it to stir paint.
You could say that how to get the card to perform a task is where the IP is. That may be the case, although consider this; the PCI / AGP bus is an open specification, with commands going across it in clear text ie. there is no encryption. Anybody who can afford a PCI / AGP bus analyser ($100K maybe?) could easily reverse engineer what the Nvidia drivers are doing.
Of course, you typical individual can't afford a PCI / AGP bus analyser, so your IP is protected from them. But is that who you need to protect your IP from ? Shouldn't you be more worried about protecting your IP from your competitors eg NVidia need to protect it from ATi ? Wouldn't a company like ATi easily be able to afford a PCI/AGP analyser, easily be able to pay engineers who know how to use one. In summary, the openness of the PCI/AGP bus doesn't protect the programming techniques very well, if at all, from the people you may most want to protect it from.
BTW, you don't necessarily need an PCI/AGP bus analyser to reverse engineer a driver. Recently, a GPL driver was developed for the NVidia ethernet network cards, for which NVidia only published a binary driver. What did NVidia achieve by only releasing a binary driver ? The only thing they achieved was to possibly reduce the number of people who might buy their hardware. forcedeth: A new driver for the ethernet interface of the NVIDIA nForce chipset, licensed under GPL.
That is why I can't see any sense in the IP claim, unless people (and Nvidia themselves) are confused between a request for open hardware programming specs, and a request for open sourcing the proprietory driver source code.
But I'd consider additional bandwidth to be an operational expense. Sure, the capital expenses are also going to be higher, but unless you *own* the bandwidth (i.e. you're a backbone provider) you'll have a monthly lease on it.
And I do too, forgot about it, until I re-read my post, after it was posted.
Still, the only "opex" cost associated with pure bandwidth, other than the expense of the bandwidth itself (which you are fundamentally getting your customers to directly pay for), is to have your accounting section send off a monthly, quarterly or some other periodic cheque (check if you are in the US). Much simpler (and cheaper) than having techos who understand QoS, networking, packets and all the other complicated networking stuff watching the network, prodding and playing with it to keep it running optimally.
Radia Perlman, in her book "Interconnections, 2nd ed" goes into a small amount of detail about the 48 byte payload decision.
cheaper to just throw bandwidth at the problem, and then avoid the operational costs of futzing around with proxy servers, with their inherent disk space, OS patch, proxy software patch, hardware failure, etc. etc., problems.
As commonly in life, in networking, complexity is the enemy.
Cisco aren't
Juniper aren't either
Neither of them are because either
They don't even go to OC48c or 2.5 Gigabits speeds with ATM.
ATM is being phased out of carrier backbones because it is overly complicated, and therefore overly expensive for what carriers need. Packet Over Sonet/SDH (POS) or Ethernet is taking over.
Just because a technology is being used doesn't make it successful, in particular when compared to its original design goals. It may only mean that there was not alternative at the time. As soon as something cheaper, yet as or more effective comes along (eg POS, 10Gbps Ethernet), the less effective technology will be replaced and / or avoided.
I think you are saying that "QoS" is necessary to VoIP, because if VoIP is flakey, the end users won't use it.
I then think you are really saying that VoIP is a latency sensitive application, so the network has to be engineered to meet the latency requirements of VoIP.
The issue then is how you meet those latency requirements ?
There are a couple of ways you can do that :
So which solution do you choose ?
As a rule, simplicity usually wins out. Maybe not in the first instance, but eventually, over time, things tend towards simplicity. Simplicity tends to be cheaper, and everybody aims for cheaper. There is always a demand in the market for cheaper, and commonly, the only way to achive cheaper is to go simpler.
Costs of running a network are broken into two areas - Capital Expenses (ie. usually initial, setup costs), and Operational Expenses (ie. ongoing running costs).
Comparing the above solutions, the one thing the second has that the first doesn't have is a lot of active bandwidth management and measuring. This can be very expensive to do, when you consider the number of devices and links within the network. It can also be very complicated, as it increases the number of protocols running in the network, and the number of people who need to be paid to watch and operate the network. The QoS solution is not the simpler of the two solutions. The second solution has higher operational expenses than the first.
Comparing the two solutions using capital expenses, I'd suggest the initial set costs of the first solution would only be in the order of about 20% more than the second, accounted for by the additional bandwidth expenses incurred.
The question to ask then is "how long will the 20% cheaper start up cost of the second solution be absorbed by the higher operational expenses of the second solution ?"
My answer is "not all that long". Which indicates that the "throw bandwidth at it" solution, in the longer term, is both simpler and therefore will be cheaper.
As further evidence, consider the Internet. There is very little QoS management on the Internet, with the exception of a recommendation of a default queuing alorithm - Random Early Detection. The Internet solution is to "throw bandwidth at it". Yet most of the time Internet provides good enough "QoS" to allow people to make voice and video calls across it. Certainly good enough to sustain voice calls that are equivalent or better than mobile or cell voice calls eg GSM. Based on that evidence, you don't need to implement QoS technology inside the network to sustain the latency required for typical VoIP applications.
In the Internet, simplicity has won.
Because I have glossed through it (a number of months ago), and none of the comments up until now show any evidence of people actually understanding Prof Odlyzko's arguments.
The goal of ATM was to replace network stacks such as TCP/IP, as evidenced by all the different QoS options available (VBR, CBR, UBR etc), as well as all the AAL layers (1 - 5, I've heard a AAL6 might be coming). Switched Virtual Circuits were supposed to be the dominant way connections were set up.
Why has it failed ? There are primarily two reasons :
Another technical restriction ATM has is due to the 53 byte Cell size. As bit rates increase, the number of cells per second increase, which increases the number of cell headers per second the ATM device has to process, which then increases the computational requirements of the ATM device. This is putting huge demands on CPU/ASIC technology, such that it is becoming impossible to build an ATM interface that can operate fast enough. For example, you can already get 10Gbps SONET and Ethernet interfaces, but I'm not aware of any 10Gbps ATM interfaces. They may exist, but they are "late to market", and very expensive, when compared to alternative 10Gbps techologies.
On a related note, the header per second processing issue is also going to be a problem with ethernet in the near future, which one of the reasons why jumbo / 9000 byte ethernet frames is slowly being adopted.
Finally, a note to those who think ATM is successful just because it is being used. You really need to consider and compare the original goals of the technology verses how it is commonly been used. As ATM typically isn't used at all for what it was designed for, then it is a design failure, and an over engineered one at that.
We all complain about how much our broadband Internet access costs. Unfortunately, ATM has contributed significantly to those high costs, because the vendors who have sold ATM want to re-coop all their R&D costs for most of the features of ATM that are never used, so they charge high prices for ATM technology. There are a few things ATM does that other technologies don't, and there haven't been any alternatives, so we have been stuck with ATM, and have been stuck paying for its over engineering.
Start reading here
groklawI like Cringely too - I think his "Accidental Empires" book is an excellent read.
My only suggestion is that if you are going to say his predictions are vague, you need to provide a few more examples than just one. That tends to suggest that is other 14 aren't !
In the Linux 2.6.0 kernel, under the "drivers" directory, there are currently 2218 ".c" files :
/usr/src/sys/kernel/linux-2.6.0/drivers
.c source files. Using that assumption, that calculates out to 1109 open source drivers in the current Linux kernel. That is a lot !
.c file, and in a number of cases, multiple devices from different vendors may be supported by a single .c file, as the they have used underlying chipsets from the same third party. So the current Linux kernel would support say 3/4 of that 2218 figure, or 1663 devices, which all have fully open source drivers. The figure is probably significantly higher, possibly even greater than the 2218, but we'll stick to 1663 for this example.
--
> pwd
> find . -name "*.c" | wc -l
2218
>
--
Being very conservative, let's say each hardware device supported by Linux requires two
Of course, most drivers are only contained within one
Let's divide that 1663 devices by 10 to get the number of manufacturing vendors. Of course, the figure is likely to be much lower than 10 devices per vendor, probably 5 or less, maybe with an average of 2. However, let's assume 10. That indicates that 166 vendors have 'got' the open source idea, and published their programming specs, or even contributed GPL licensed drivers.
Linux driver support may appear to be broken because the two major graphics card vendors don't publish programming specifications. However, 2 vendors holding out, compared at least 150 or more who get open source, doesn't make Linux driver support broken.
The Linux development model has succeeded, as has the Linux philosophy on driver development. It is only the few, high-profile "bad apples" that make it appear to have not been successful.
do you trust ./'ers to only write innocent, good willed code ?