Talk:Asynchronous Transfer Mode/Archive 1
- This is an archived talk page from Talk:Asynchronous Transfer Mode.
- Dates: November 2001 through December 2006, plus uncategorized miscellaneous comments that were interspersed within the date sequence.
- BEGIN ARCHIVE
I've cut some bits out of the main article for discussion as we try and get it straight :-) Alex 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)
- 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
Multiple ATM PVCs in DSL?
editThe 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)
- END ARCHIVE