Talk:Asynchronous Transfer Mode
From Wikipedia, the free encyclopedia
 |
This article may be too technical for a general audience. Please help improve this article by providing more context and better explanations of technical details to make it more accessible, without removing technical details. |
What a stupid comment. This is a technical article. If you're lazy and ignorant it's your fault, not the writer's.
—Preceding unsigned comment added by 201.212.143.7 (talk) 23:29, 6 March 2008 (UTC)
Christ, this article is an extreme example of articles written way too technically. From the lead section alone, I as a layman on the subject cannot even see what the article is about (aside from the word "technology"). SalaSkan 18:08, 8 June 2007 (UTC)
To quote:
"The motivation of the small cell size was the reduction of jitter in the multiplexing of cell streams.
- At the time ATM was designed, 155 Mbits/s (135 Mbits/s payload) was a fast optical network. At this rate, a 53 byte (424 bit) cell would take 3.1 µs to transmit. Since then, networks have become much faster. Now (2001) a 1500 byte (12000 bit) full-size Ethernet packet will take 1.2 µs to transmit on a 10 Gbits/s optical network, removing the need for small cells
to reduce jitter, and greatly reducing the need for ATM."
and
" (This is much less important today (2001) given the increase in backbone speeds: see note above)."
Yes an no. Its not the only thing that affects latency (and therefore delay on voice calls). When dealing with voice traffic the time taken to fill a cell is also a factor. Standard voice band still runs at a 8Khz sampling rate. If you fill a typical 1500 byte IP packet at that rate you still introduce a lot of delay. Of course you could sub-fill a cell but then you defeat the whole point.
I've also cut out my:
"The larger the payload, the more efficent the transport of packet traffic (like IP) however the larger the latency in transport (which affects Voice telephony)."
Until we have a consensus.
I could be wrong but do I detect a slight bias against ATM?
The VoIP argument: yes, use ATM on the access ADSL link (see my comments there) - but not in the backbone.
Alas, I have extensive ATM experience (up to and including building one of the first international switched virtual circuit ATM networks, and later ripping it all out in favour of Ethernet/IP). Really, I am striving for NPOV. -- The Anome
Ok. I suggest we move the bits about Telco addopation and its intended goals etc, outside the article for now and just concentrate on consolidating the facts on ATM. Once the main article is straight we can tackle the ATM Part, present and future bit (mainting NPOV :-)
For the record I'm probably quite pro-ATM, although I can understand the headaches SVC's have caused you! Alex
SVCs were no problem - but getting telcos to understand them was more or less impossible. As you say, PVCs work (and map nicely onto the telco 'leased line' concept) but so do any of a number of other Layer 2 traffic segregation techniques (Gigabit Ethernet VLANs, MPLS, etc...) used as an under/over layer for IP - and they work just as well in the backbone (which means anywhere >= 1 Gbps nowadays) and they're cheaper. Still, I agree, we need to work together on giving ATM a good article - it's not going to go away for some time yet...
-- The Anome
I never understood why telcos had such a problem with SVCs, given that they're basically phone calls.
—Preceding unsigned comment added by 82.6.99.8 (talk) 12:00, 11 March 2008 (UTC)
I have now reedited/rewritten the article, hopefully preserving existing content and retaining NPOV on the matters discussed here (expanded and re-integrated). Let me know what you think.
-- The Anome
Added stuff about GFC, PT and NNI format. Also AALs. -- The Anome
Hi, I'm new here on Wikipedia; just wondering if it would be appropriate to add a disambiguation page for the acronym ATM? Besides this ATM, there is obviously Automatic Teller Machine and ATM; less obvious (but frequently encountered in my work): Advanced Traffic Management, and Arterial Traffic Management, both used in the Intelligent Transportation System industry.
If there is a more appropriate place for me to post such a question on Wikipedia, let me know! Harris7 09:14 28 Jun 2003 (UTC)
- How about the one at ATM? ( 09:28 28 Jun 2003 (UTC)
- I see that atm redirects to pressure. Should it go to the ATM disambiguation page instead? ( 09:35 28 Jun 2003 (UTC)
The last paragraph in Introduction mentions "SAR", but links to a disambiguation page. Normally, I would change the link to the specific meaning of "SAR", and spell out the term the first time the acronym is used, but not being an expert on the topic, I'm unsure what the meaning of "SAR" is in this context. I can only assume it refers to "Segmentation and Reassembly", but that term refers to a process while the text in the article appears to refer to a device.
ATM in professional media production Hi,
In studying the success and failures of ATM, it may well be worth looking the work being done on high performance professional media production networks. While much of this uses a file based “store and forward” approach, the live low latency requirements have been developing ATM solutions using AAL 0 (ATM in it’s native form). Within this type of environment their seems little point in passing the IP structure over ATM as well unless a wide area connection is required where it proved cost effective to do this. However, ATM still brings a type of quality of service that is essential to professional media broadcasting centres where high bandwidth IP system can only provide something close by seriously over provisioning the network capacity. Over provisioning still does not guarantee the required QoS under high volume usage as tests have found. Take a look at the new standard AES47 that has also been published as IEC 62365. You should find more references on the web to AES47 as this has been about for a year or two now. See http://www.aes.org/publications/standards/
Chris
How about phisycal layer 1?
ATM goes on fiber optical cable, copperwire? other type of connection?
DreadN
ATM goes on fibre (155 Mb, 622 Mb, 2.5 Gb and 10 Gb) and on copper (RJ45 connectors/CAT5 standard (and greater), as well as coax with a BNC connectors using the G703 standard). RJ45/CAT5 connections tend to run at 155 Mb (STM 1) or a less common 25 Mb, while BNC/G703 tend to run at 155 Mb (STM 1) as well as 45 and 35 Mb in some cases.
Chris
Also AES51 defines how to run it over anything that will carry Ethernet, including 1000Base-T. See http://www.aes.org/publications/standards/ —Preceding unsigned comment added by 82.6.99.8 (talk) 12:04, 11 March 2008 (UTC)
Why is there someone's name all over this page? Maybe i'm blind but I can't see where it is coming from... can someone remove it? Wikipedia is about contributing for the greater good; not personal recognition by stamping your name all over the page as "author"
MrHorus
There doesn't appear to be a clear reason for the statement "ATM switches can also operate at OC-192 (STM64) rates." to be part of a paragraph dealing with ATM over IP and IP routing (not ATM switching). The relevance of this statement should either be qualified with additional information, or if it is indeed dealing with an unrelated issue, put into a seperate paragraph and elaborated upon. I have removed it for the moment.
Het 02:02, 2 October 2007 (UTC)
Contents |
[edit] Multiple ATM PVCs in DSL?
The discussion of ATM in DSL makes it sound a Good Thing, but I question this.
Yes, ATM over DSL makes it theoretically possible to minimize voice latency by interleaving small, high priority voice frames with large (1500 byte) data packets. However, I have yet to find a single DSL-based ISP, at least in the US, that actually does this. Even bundled VoIP offerings (e.g., Speakeasy's) send both voice and data over a single ATM virtual circuit (usually PVC 35). Unless QoS is implemented at the IP level outside the ATM path, voice latency suffers horribly when heavy data traffic builds the transmission queue on the single PVC.
Independent VoIP offerings (e.g., Vonage) over DSL are even less likely to benefit from ATM multiplexing. It's all just FIFO data to the ISP.
This combines all of ATM's disadvantages (especially the significant 5/53 = 9.4% header overhead) with none of its advantages.
Also, the discussion says that ATM makes it possible for a common DSL infrastructure to provide services through multiple ISPs. While true, pure IP would work just as well. Since customer traffic is already entirely IP, this would eliminate the ATM "bandwidth tax" on the DSL network cloud as well as on the access link.
Unless somebody can point to at least one example of a DSL ISP that actually uses separate ATM VCs for voice and data, the article should point out that these potential benefits of ATM are not actually realized, yet the ATM bandwidth tax remains. The claimed benefits of ATM for low voice latency over DSL could alternatively be obtained with IP QoS, at least at higher DSL line speeds where the transmission time of a full-sized 1500 byte data packet is acceptably small (e.g., 15.6 ms @ 768kb/s).
Karn 20:43, 11 December 2006 (UTC)
[edit] Virtual Channel Identifiers
This article constantly refers to ATM using virtual circuits. In ATM, "VC" stands for "Virtual Channel", not "Virtual Circuit" (although of course they are an example of the generic concept of virtual circuits). LachlanA 03:15, 31 January 2007 (UTC)
[edit] Cell/payload size
This seems like a typo, but as I know next to nothing about ATM myself I'm checking here first: The para on the choice of payload size, 32 v. 64, ends with 53 bytes was chosen as a compromise between the two sides - this seems to conflate the payload and total cell size - would it better be "48 bytes was chosen..."? The following text then mentions the 5-byte routing and total of 53 - Royan 22:41, 13 February 2007 (UTC)
[edit] Jitter not the only reason for small fixed-sized packets (cells)
When engineers were developing X.25 some were already working on digital voice. They realized that time was being lost while the first codec was converting analog data into digial, and that this time loss was proportional to packet size. So the ideal packet size for voice was somewhere between one bit and one byte but the pragmatic demands of the day set it to 128 bytes. Also at that time, pressure from the computer industry demanded larger packets so packet size grew to 4096 (I don't recall it being higher but may be wrong). Jumping back to ATM, certain networks with larger variable-length packets (like Ethernet) made network environments very unpredictable. So just switching to samll fixed size packets (called cells) made ATM networks much more deterministic. Of course, engineers added lots of other stuff to the technology like non-blocking fabrics and QOS to make these networks even more useful. --Neilrieck 13:41, 4 March 2007 (UTC)قاقا باقا
[edit] P-NNI is link state but not necessarily shortest-path
The P-NNI standard specifies the exchange of link state information, similar to what IS-IS and OSPF do. It has more levels of hierarchy, and more metrics, but the basic approach is similar.
However, it does not specify the routing algorithm, i.e., the algorithm that picks the path for a particular destination. The reason is that this is not necessary; SVC setup uses source routing, so there is no need for the switches to agree on what the chosen route will be for a given destination. Connectionless switches require agreement to avoid loops, but ATM SVC setup does not. So the standard leaves this aspect open to implementers' choice.
Obviously, it's to be expected that some algorithm similar to Dijkstra's algorithm will be used to determine the path for a particular connection, but it's not correct to say that the standard "uses the same shortest path algorithm used by OSPF..." Paul Koning 17:01, 2 May 2007 (UTC)
[edit] Call admission
The article says "To admit a call first a VPC has to be established. This will guarantee the correct routing from end to end." This is incorrect. In the signaling for SVC setup, the route is specified (see my comment above on P-NNI). It does not require a pre-existing VPC, for routing or for any other purpose. A call is admitted if the admission control algorithm decides to admit the call, normally because the resources the call asks for (in the signalling messages) are available.
A network implementer can certainly use a VPC as a trunk, and route a new SVC over such a trunk if the source route allows it, but there's no requirement to do so; if a network does that, it's an internal matter that is invisible to the user. Paul Koning 17:06, 2 May 2007 (UTC)
