Jump to content

Talk:Asynchronous Transfer Mode/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2

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)قاقا باقا

Golden Standards

ATM is based on the efforts of the International Telecommunication Union-Telecommunications Standards Section (ITU-T) Broadband Integrated Services Digital Network (B-ISDN) standard. It was originally conceived as a high-speed transfer technology for voice, video, and data over public networks. The ATM Forum extended the ITU-T's vision of ATM for use over public and private networks. The ATM Forum has released work on the following specifications:

•User-to-Network Interface (UNI) 2.0

•UNI 3.0

•UNI 3.1

•UNI 4.0

•Public-Network Node Interface (P-NNI)

•LAN Emulation (LANE)

•Multiprotocol over ATM —Preceding unsigned comment added by Mohanchander (talk • contribs) 06:22, 17 August 2008 (UTC)

Archive

I have archived the pre-2007 discussion to Talk:Asynchronous Transfer Mode/Archive 1, not so much because of the volume of the material, but because the discussion was outdated, and the loose format might tend to discourage focused discussions on this talk page. --Bejnar (talk) 20:26, 4 January 2009 (UTC)

Hatnote

Currently this page has a hatnote which reads: Not to be confused with Automated Teller Machine. Since ATM no longer redirects here, is this hatnote still useful, or is it a distraction? --Bejnar (talk) 20:29, 4 January 2009 (UTC)

physical layer

Other than being multiplexed into SONET, what other choices exist for a PHY layer for ATM? I couldn't find out what standard the NIC in that pic of an ATM NIC follows. I sorta read the ATM standard (UNI 3.1) and it talks about ATM running over STP 150 ohm Token Ring cabling @ 155 with 9 pin DIN connector, FDDI fiber @100, "DS3" at @45, MM fiber with ST connector (BFOC/2.5) @155, and "SONET" STS-3c @ 155 (ANSI T1E1.2/94-002R1) with a reference to ANSI T1E1.2/94-002R1 for what PHY layers those are. Next issue, many things are defined in standards, whether they were commercialized and ever used is a different story, so what are the most common ways to the move an ATM stream other than a DSL modem and multiplexing into SONET? What about P2P non-SONET situations? Patcat88 (talk) 23:48, 14 June 2009 (UTC)

One, I think you're confusing layers 1 and 2. Two, talk pages are for discussing ways to improve the article, not a general forum for conversation about the topic. //Blaxthos ( t / c ) 01:15, 15 June 2009 (UTC)

This article needs help.

I added a few references and starting adding inline citations supporting the copy, but didn't make it past the lede. Much of the first part of this article is charged with diverging non-neutral points of view unsupported by the secondary sources I have. Other passages read like an attempt to justify its design. Further passages read like a tutorial or instruction manual for designing networks. Once past those there is a diagram and a few passages and it stops. This article needs a major rewrite from a neutral point of view. It is just too much for me to engage in on my own at the moment. In the mean time, if anyone can clean up some of these passages, I can contribute some secondary sources for them. — Dgtsyb (talk) 14:15, 2 January 2010 (UTC)

IBM Turboways ATM NIC PHY

Could anyone please tell me what is the PHY (physical layer) protocol used by the depictured IBM Turboways ATM NIC and similar cards by FORE Systems? Could it even be SDH STM-1? (The speed of 155 Mbit/s matches STM-1 exactly.) —Preceding unsigned comment added by 95.220.176.115 (talk) 01:37, 1 November 2010 (UTC)

I don't know this NIC, but there are two 155 Mbps (155 520 kbps) PHY standards given in ITU-T Recomendation I.432.2. One is SDH STM 1 (Sonet STS/OC 3c) and the other is the cell based phy, sometimes called the native ATM phy. This cell based phy has exactly the same cell throughput as STM 1 (149.760 Mbps), because an (extra) idle or PHY layer OAM cell is added after each 26 ATM layer (data) or idle cells. Graham Fountain 14:12, 1 December 2010 (UTC)

Lost sentence

At the end of section Why Cells?, there's an open ended sentence: 

5-byte headers were chosen because

Does anyone know where the rest of this sentence has gone, or what it should mean? -- 80.136.127.209 (talk) 12:53, 27 January 2009 (UTC)

No, but as a developer I really want to know, because the 5-byte headers are a pain from a word-alignment point of view! 195.188.241.12 (talk) 15:40, 3 February 2009 (UTC)

Well the sentence now ends, but this whole section needs better citations, especially this 10% claim. W Nowicki (talk) 17:07, 6 May 2011 (UTC)

ATM (Another Technical Mistake)

This is to put some humour into the article. I sometime back remember reading a technical magazine and the author called ATM Another Technical mistake. I found it funny and think it could make the article interesting, at least mentioning that people in the technical industry do refer it by that name

ATM (Asynchronous Transfer Mode) or (Another Technical Mistake) - An attempt by the phone industry to turn your networking problem into something they know how to tariff

See this link [[1]] gathima (talk)

Yes, there needs to a section at the end about where it is now in its life cycle. Needs to be well-cited and neutral of course. The source you point out might be included, although it specifically says "Gigabit ATM" and is 12 years ago. But its main point about how packet sizes should scale up is very relevant. Need to link to subsequent technologies that might have been influenced by ATM, perhaps HIPPI, various switched Ethernets over SONET-like PHYs, certainly Ipsilon Networks and Multiprotocol Label Switching. W Nowicki (talk) 17:07, 6 May 2011 (UTC)

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)

I think it depends on the exact acronym being used. For instance: VCC = Virtual Channel Connection, while PVC = Permanent Virtual Circuit/Connection. The standalone "VC" even seems to be "Virtual Connection" - *smirk*. But you are right, in the case of VCI, it is "Virtual Channel Identifier". (All claims) Based on this Cisco ATM guide. -> See section "VC Merge" 11-8 for a "VC" definition. Regarding "connection" vs "circuit", see page 21: "over virtual connections, sometimes called virtual circuits", so it seems both terms "virtual circuit" and "virtual connection" are ok. However it is highly confusing, the article should use only one style and explain it. Of course claims to abbreviations make only sense when founded on a reliable source.--Methossant (talk) 01:08, 2 June 2011 (UTC)

Requested move

The following discussion is an archived discussion of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

No consensus to move. Vegaswikian (talk) 06:26, 24 September 2011 (UTC)

Asynchronous Transfer Mode → Asynchronous transfer mode –

Per WP:CAPS and WP:TITLE: this is a generic, common term, not a propriety or commercial term, so the article title should be downcased. In addition, WP:MOS says that a compound item should not be upper-cased just because it is abbreviated with caps. Matches the formatting of related article titles. Tony (talk) 04:01, 16 September 2011 (UTC)

So now we've flushed out another OWNER, who seems to think rudeness is the way to go. Sorry, it is counterproductive. In case you were wondering, WP's house style is not at all unusual:
I trust you will drop the insults and rudeness. Tony (talk) 06:20, 16 September 2011 (UTC)
WP house style is to capitalize proper nouns, of which Asynchronous Transfer Mode is one. It is interesting to note that your ngrams show it capitalized in 1907! It looks like the tool mistakes '07 for 1907, which would skew the results about 2007. Nevertheless, during the mid-90's when it was being developed, we (telecommunications engineers) talked much of the general aspects of the asynchronous transfer mode before it was specified, standardized, and named the Asynchronous Transfer Mode (we might have named it something else). The earlier usage was widely published in working papers of the ITU (that were made into books) and in patent applications anticipating the standard. But, if you read the previous discussion, above, you would have discovered that. Also, as another editor noted, above, even common usage can be in error, so it is better to look to the context of the usage in the article to determine whether it is a proper noun or not. In this case, as it is used in the article, it is a proper noun: it refers to the name of a specific protocol standard and not a generic class of operation. This was identified by most of the editors in the last discussion. Being a proper noun, it must be capitalized according to WP policy. — Dgtsyb (talk) 08:10, 16 September 2011 (UTC)
Thanks for your post: is it owned by a particular company or individual, and is it used by more than one agent, without license, in telecom services? Proper noun says "A proper noun or proper name is a noun representing a unique entity (such as London, Jupiter, John Hunter, or Toyota), as distinguished from a common noun, which represents a class of entities (or nonunique instance[s] of that class) ...". Tony (talk) 08:32, 16 September 2011 (UTC)
In the article it is used predominantly to refer the specific protocol specified in ITU-T Recommendation I.361 (amoung others), and not the general aspects, class of techniques, nor broad technology. The article is about the specific ITU-T standard and therefore the title is a proper noun. In general, all sequences of descriptive words that are used as proper nouns in technology can be used both as a proper noun and as a general description. From one of your ngram hits: "The asynchronous transfer mode (ATM) protocols are still in the process of being "fleshed out" but are anticipated to be of considerable importance in the future." In the quote it is used as a description of a class of protocols using the asynchronous transfer mode technique (as opposed to the synchronous transfer mode approach that the proposals replaced). However, this WP article talks of the bits (specified in ITU-T Recommendation I.361) in the header, such as the HEC bit-field used for error correction, the cell size, and layout, which are specific to the ITU-T Recommendation I.361 standard adopted by the ITU. As such, the article is about the specific ATM protocol adopted by the ITU-T and does not actually describe any of the competing asynchronous transfer mode proposals that led up to the adoption of this specific standard.
You will find this is true of many descriptive phrases which are also the proper names of specific standards. I can talk of the Broadband Integrated Services Digital Network as specified in the ITU-T Q.2900-Series recommendations, or I can talk of the emergence of broadband integrated services digital network technologies, such as the asynchronous transfer mode technique. I can talk of the need for a high-level data link control procedure, or talk of the High-Level Data Link Control (ISO/IEC Standards 3309:1988 and 4335:1988). In general, many articles on WP refer to the specific standard as a proper noun, and experts in a domain that watch these documents for inaccuracy and vandalism get upset when someone (usually with no domain-specific knowledge) tries to down-case them. There are, however, some articles, like Asynchronous communication which are general and don't describe a specific standard. Knowing which, sometimes requires a technology expert, or at least someone that has often used the name in a sentence. — Dgtsyb (talk) 09:33, 16 September 2011 (UTC)
  • Support – although it usually refers to a specific protocol, there's little evidence in sources that it's a proper name. About half of good sources use it in lower case in sentence context. WP style is to do similarly. The lead says ATM is "a technique"; it it's also the name of a specific protocol, we can mention that, and capitalize when we do if there's evidence that it's a proper name, but the article should be kept more general than that. The ITU doc, ref 1, does not capitalize it. Dicklyon (talk) 16:54, 16 September 2011 (UTC)
  • Oppose although this is borderline. The lead implies the article is talking about the general concepts of modes for transfer that are asynchronous. But the article and almost all uses of the term do refer to a specific standard of the ITU-T. Actually a large family of standards, but they are all unified in the 53-byte cell size for example defined in specific documents for B-ISDN. I just downloaded the I.150 document of ref 1. Although it does not use capitals in the title for some reason, it does consistently capitalize in the text (along with all other nouns defined in it, but that is another point). So I would contrast this with digital subscriber line for example, which is the general concept of frequency modulation in bands above voice on telephone lines. I would call the generic technique "cell switching" and indeed that redirects to Cell relay, a generic article in lower case. Put another way, one could argue that the "transfer mode" of Ethernet is not synchronous, so an article about all "asynchronous transfer modes" (lower case) would have to include all those other protocols as well. The specific protocol layer defined in I.150 deserves its own article, and deserves to be a proper name to denote it is this specific one. W Nowicki (talk) 20:48, 16 September 2011 (UTC)
The only places that doc capitalizes "asynchronous transfer mode" is where it is defining the acronym ATM (which it does in 3 places); I'd go with the title. Dicklyon (talk) 21:39, 16 September 2011 (UTC)
  • Oppose. Although asynchronous transfer mode may refer to a general technique, telecommunication folks (including myself) generally refer to it as a specific protocol using the well-known 53-byte cell sizes that is still widely used as a data transport mechanism in the backbone of traditional telephone providers, and which is also implemented in other networks such as satellite communication systems when intended for telephony. As such, it is a proper noun and by our rules should be capitalized. Nageh (talk) 20:51, 20 September 2011 (UTC)
  • Support This is not a proper name, just a term that is commonly up-cased to match the acronym. The MoS does not support that style. Use lower case. Jojalozzo 02:28, 21 September 2011 (UTC)
And what exactly is your rationale? Are you a telecom engineer? Do you have qualification to state this? Or is it just your opinion that you weigh in? I have provided arguments for why this needs to be upper-cased. Where are your arguments? Sincerely, Nageh (talk) 07:42, 21 September 2011 (UTC)
Why would he need qualifications, or need to be a telecomm engineer, to look at sources and comment on this? As I pointed out above, many sources, including the official ITU doc, capitalize it where they define the acronym, and not otherwise. There's no good reason to treat it as a proper name given such usage. Dicklyon (talk) 09:15, 21 September 2011 (UTC)
(edit conflict, and then the phone range before I posted it) Nageh, perhaps Dicklyon's rationale supports what Joja is saying: "About half of good sources use it in lower case in sentence context. WP style is to do similarly." And Dicklyon, who invented what you're holding now, might have some credentials in the field. Tony (talk) 09:21, 21 September 2011 (UTC)
It actually does not require expertise to determine whether a term has a generic meaning or a specific one. Compare the Internet (the global network of networks, which is based on TCP/IP) with an internet (a network of networks). Or a serial bus with the Universal Serial Bus. It is primarily a matter of grammar. If your argument is that ATM as a trademark would be written in lower-case letters that would be a different argument; but then, it is not a trademark but a specific protocol. I think this makes it quite clear; if not, I don't know what I can do to make it more clear. Nageh (talk) 11:14, 21 September 2011 (UTC)
I agree on Internet and Universal Serial Bus, but not on Asychronous Transfer Mode; not even "the asynchronous transfer mode". My disagreement is based on what I find in sources, not on any particular expertise that I might have. Dicklyon (talk) 11:43, 21 September 2011 (UTC)
We all know the lack of adherence to grammar rules by technical documents – as Tony put it, they tend to upper-case every noun in sight. That this standard document does not follow this practice does not mean it is suddenly right. As I said, it is a matter of grammar: if we've got a proper noun it needs to be upper-cased. In this case, ATM refers to a specific protocol standardized by the ITU, and should be upper-cased. The generic meaning of "asynchronous transfer mode" would mean nothing else but "a mode using packet or cell-switched transmission" (in contrast to traditional (from the perspective of telephone operators) synchronous = connection-based transmission). But the generic meaning is not common at all: people say "packet switching", "cell switching", "packet-based transmission", etc. and not "asynchronous transfer". Nageh (talk) 14:31, 21 September 2011 (UTC)
The above discussion is preserved as an archive of the proposal. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Do not capitalize terms just because they are referred to by acronym

This article up-cases most every term that has an acronym. This is common practice in technical literature but Wikipedia's MoS does not support it. At the least we should match the case here to the usage in the articles we're linking to, though some of those, e.g. virtual channel identifier and virtual path identifier, are probably up-cased incorrectly themselves. Jojalozzo 20:45, 21 September 2011 (UTC)

Yup, and as I mentioned in the move discussion, if this article is about the specific protocol with 53-byte cells, not about the generic technique, then it needs to be written that way too. But also as above some are tough calls, so we should not spend time on brownian motion fighting over case, but perhaps fill out the article with citations, history of adoption, etc. W Nowicki (talk) 18:31, 24 September 2011 (UTC)

Current Uses of ATM

Can anybody add a section on the uses, particularly current uses, of ATM?

It's my understanding that although it's not become the ubiquitous network standard is was touted as in the 90s (Fast/GB Ethernet did), it's still being used in telecoms infrastructures, and, I have been given to understand, some parts of broadband Internet access.

Put somewhere near the start, this would, I think, be a useful and (possibly) interesting addition to indicate the relevance (or not) of this article. Graham Fountain 14:23, 1 December 2010 (UTC)

You need to come up with a citation for such statements. My understanding is that ATM networks are being decommissioned and no new ATM equipment is being installed or built. --21:43, 4 May 2011 (UTC)
Yes, citations needed. It is used in my DSL modem that I am using to make this edit, and suspect it is still the most common form of Internet access to residences. But the irony is that it has shifted to the edges of the network, out of the backbone, where it was originally envisioned. See below of course. W Nowicki (talk)
I believe is some strange hybrid such as (IP over) Ethernet over ATM. Rich Farmbrough, 01:14, 26 September 2011 (UTC).

Changes made by 194.237.142.10 - Corrections made to spelling and grammar

The changes made by 194.237.142.10 at 07:58, 26 September 2011, raise a number of questions. I was, initially, tempted to merely revert, but perhaps that would be a bit precipitous. Some of the changes don't matter to me, so I will not comment on them, but the following ones need some consideration:

The change of the one spelling of "queueing" to "queuing" does beg the question of which is correct in this context, regarding the spelling of queueing theory. However, if "queueing" is right there, then some, many, or all of the "queuing"s in this article need to be changed.

I think that the use of "continued" [source line 122] is wrong; though, otherwise, that edit is not contentious.

I think that "potentially redundant" [source line 147] is, potentially, misleading, though I don't much like "discardable" either. However, the intention is more clear than implying that all cells with the CLP set are "potentially redundant" as opposed to "cells which may be discarded [down stream] in congested conditions" (from Cell Loss Priority) [oh no! another capitalized term].

I like "the provisioner must build" in preference to "provisioned", as it more strongly implies an agent in the creation of PVCs and PVPs.

It appears that 194.237.142.10 does not like "build" and "tear down", presumably as jargon. The question is, should the article be written in the common parlance of the technology, unless it is obviously confusing, which it is not.

The use of "which" [source line 153] as a restrictive/defining relative pronoun is anathema to me, and, in my opinion, it really should be "that" or be preceded by a comma as a descriptive/non-defining relative pronoun [see Fowler's Modern English Usage, 1st ed, THAT, REL, p635]. Whatever the correctness of the original, change for the sake of it seems pointless.

Of the ones I said I wouldn't comment on, it was my understanding that it is policy not to go around changing American spelling to British for the sake of it. [Don't start me off on "ise" vrs "ize" or the use of the serial comma though.]

Anyway, any comments?

Graham Fountain 16:07, 26 September 2011 (UTC)

Be bold. I don't see any problem with your proposed changes. — Dgtsyb (talk) 21:38, 26 September 2011 (UTC)

Hello fellow Wikipedians,

I have just modified one external link on Asynchronous Transfer Mode. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

checkY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 11:33, 20 October 2016 (UTC)

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)

The 53 byte cell has a 48 byte payload, and 5 bytes of routing data. As well as I know, the 48 is a compromise between 32 and 64, as suggested by the US and EU, but I don't remember which side wanted which value. In addition, the seven layer ISO model is a compromise between 6 and 8, again US vs. EU, and again I don't remember who wanted which one. Gah4 (talk) 17:00, 7 February 2017 (UTC)

Too technical

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)

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)

See Peter. See Jane. See Jane run. See Peter run. Is this what you're after? If the article has to cover an introduction for numpties then it'll really no longer be much good as an article. Did you get to this page from the "Random article" link or something? —Preceding unsigned comment added by 128.40.46.110 (talk) 09:04, 1 September 2010 (UTC)

Even with elctronics qualifications (old school) I find the introduction needs clarification. See the wood for he trees, guys. 128.40.46.110, etc, ... I m going to stop now before I get rude.Jabberwoch (talk) 13:05, 1 December 2011 (UTC)

If the article wasn't technical it would be of no use to me. Welcome to my world.BurtonReingold (talk) —Preceding undated comment added 22:05, 24 March 2011 (UTC).

Well yes and yes (and please stay civil). It can be technical and still readable. The usual way to do this is to put context and general overview in the lead section, with details in the body. Also a section at the start giving even more context, e.g. time frame and motivation, phone company vs. computer networking mindsets, etc. W Nowicki (talk)

Technical articles are for technically savvy people. If you cannot understand the language, then you're obviously in the wrong place: reading something that you shouldn't or being too much of a novice and aiming too high. If you don't understand some terms, then LOOK THOSE DAMN TERMS UP and learn before proceeding to read the main article, or don't read it at all, since you're apparently not qualified for it. The article isn't meant to provide information for newbies, it simply provides all information about the subject as is using the most fit terms. It should NOT and will NOT have non-savvy readers in mind, remember it firmly. Or do you go to articles on math articles about, say, topology or differential equations, or theoretical physics articles, read it not understanding a word, and complain too? These articles are no different from those highly specialized complex math/physics articles -- either learn all the prerequisite terminology and theory and then proceed to the article, or stay away. End of story. 213.141.136.24 (talk) 05:19, 25 September 2015 (UTC)

There is some use for articles that non-technical people can at least begin reading, but technical people need references, too. For networking technologies that make it into the home, articles should be able to begin with an explanation for home users. For many articles, there is no non-technical place to start. Gah4 (talk) 17:03, 7 February 2017 (UTC)

No 53 T-shirts

would be nice to have a photo of someone wearing one of those T-shirts with the number 53 in a red circle with red slash (international prohibition sign). AnonMoos (talk) 12:19, 31 December 2009 (UTC)

I suppose useful if you are at an ATM conference, but walking down the street, you will just confuse people. Gah4 (talk) 17
04, 7 February 2017 (UTC)

Hello fellow Wikipedians,

I have just modified one external link on Asynchronous Transfer Mode. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

checkY An editor has reviewed this edit and fixed any errors that were found.

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 05:48, 26 July 2017 (UTC)

ATM vs. IP

Some parts of the article sound like it is a competition between ATM and IP, but it seems to me that it ATM makes sense as a networking protocol, it pretty much has to include (encapsulate) IP. That is related to LAN Emulation, and there is some discussion about that. Gah4 (talk) 17:13, 7 February 2017 (UTC)

In the context of future avionic systems, it was more a battle between ATM and packet switched Ethernet than with IP as such (and happened in the late nineteen nineties and early twenty-hundreds [decade]). There was a diversion for F35 into the avionic variant of Fibre Channel (FCAE) - though that diversion had, I think, more to do with the US MIL-Av industry's NIH syndrome, etc.
The battle between ATM and Ethernet for future avionic systems has also been complicated by AFDX and Time Triggered Ethernet. However, they both really need bespoke network interfaces for even reasonably efficeint operation, which entirely misses the point that standard Ethernet interfaces are cheap and, more importantly, have become virtually ubiquitously integrated into computing equipment – just as it was said ATM's would but didn't. Also even 622 Mbps now looks seriously pedestrian in the context of systems that are expected to transport uncompressed HD imagery at video frame rates. Fortunately IEEE 802.1Q and SDN protocols like OpenFlow (v1.3+) add enough to allow Ethernet to meet the real-time data transport requirements (guaranteed reliable delivery within a deadline, i.e. nothing like what TCP gives), which ATM was almost perfectly designed for. However, Ethernet's data frames are still too big and jumbo frames are, for me, just anathema.
So, in that context, I think ATM is dead, buried, and the grass needs cutting already. That is a shame, because ATM really was the better protocol - arguably the best damned PSN protocol there ever was. But its relationship with Ethernet is clearly another example of the verb 'to betamax'.


Graham.Fountain | Talk 08:34, 26 July 2017 (UTC)

ATM vs Ethernet on the backbone

"Some consider that this makes a case for replacing ATM with Ethernet in the network backbone."

We took the wrong fork in the road when we gave up on ATM. And statements like this (and another I've seen for MPLS emulating ATM in IP) are just stupid.

ATM is truly elegant. Bits show up on one port and through an associative memory like mechanism are directed to the proper output port without any decision making whatever. The path is laid down end to end through the nodes at connection setup time and then unchanged for the life of the connection. This transit of a node can be done in just one clock cycle ... and conceivably with direct gate logic (using FPGA techniques)zero clock cycles. ATM can make thousands of hops in less than a second. On the other hand, IP requires an enormous amount of time at each hop and thus demands a "backbone"-like architecture to minimize hops ... job security for carriers. If we used ATM the entire backbone could be replaced with an amorphous mesh ... and the internet would be multitudes more responsive.

The vast majority of internet traffic is natively connection oriented. The data goes from one sourcing endpoint to one and only one receiving endpoint ... and those endpoints don't change in the session. ATM is naturally connection oriented. IP, on the other hand is natively broadcast oriented. Without kludgey training wheels, IP has to rediscover the connection with each packet/node transit. That's why MPLS was cobbled together ... to deliver one of those training wheels.

Why in the world did they make the choices they made?

I was there when it was happening and I know ... and it was not technological ... it was greed. A simple refinement of dynamic SVC techniques to replace the PVC provisioning employed by the carriers would have been all it would take.

The IP process has become an enormous kludge as it tries to emulate ATM and deliver security and QoS and speed that ATM delivers perfectly naturally.

It is such a shame.WithGLEE (talk) 16:36, 1 August 2017 (UTC)

But then again – why did all the carriers change over to the Ethernet side? Packet switching simply is more cost effective. What your infrastructure can transport is what you can sell. Elegant (sadly) doesn' win the prize. --Zac67 (talk) 17:04, 1 August 2017 (UTC)
The reason Ethernet betamaxed ATM was primarily because of the cost of interfaces, as they are both PSNs. Why ATM interfaces were inherently more expensive than Ethernet ones is to do with the low level ATM functionality that almost necessarily had to be done in hardware, e.g. traffic shaping after SAR. That's somewhat offset by the need of more memory in the Ethernet switches, but memory is cheap and there will always be far fewer switches than network interfaces. Ethernet interfaces, using much simpler hardware, transpose that hardware cost in to a software cost which hits the system performance not the purchaser's pocket. But as the purchaser only ever found out about the performance hit, if they ever did find out, after they'd bought the system, and by then it was too late to ask for their money back, it was a no brainer for the manufacturer/vendor. And then the economies of scale kicked in. Once that happened, the cost of switches fell dramatically, and Ethernet will never ever have to look back.
That does not change the fact that ATM was (IMNSHO) a much better PSN protocol than Ethernet. But neither does that change the fact that complaining about it will do no good.
As for MPLS, VLANs are better, even though you have to support the Ethernet frames over any other interconnecing physical layer - Ethernet over X - to preserve the IEEE 802.1Q tags. It would be better if the VLAN Id were longer than 12-bits, but Q-in-Q gets round that.
Graham.Fountain | Talk 08:28, 2 August 2017 (UTC)

Requested move 4 June 2018

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review. No further edits should be made to this section.

The result of the move request was: page moved. -- Ed (Edgar181) 11:51, 11 June 2018 (UTC)


Asynchronous transfer mode (ATM) → Asynchronous transfer mode – No need for parenthetical. Why use this strange name?106.39.191.224 (talk) 03:54, 4 June 2018 (UTC)

I might be for a change, but one should say the change(s) suggested. Also, what is the meaning of the strange red link. Why a link to page moving? Gah4 (talk) 04:47, 4 June 2018 (UTC)
It seems that the suggested new name is why use this strange name?, which I believe is not very descriptive of the page. Also, there should be a why= parameter, explaining the reason for the suggested move, and there isn't one. For those reasons, I vote against the change. Gah4 (talk) 04:52, 4 June 2018 (UTC)
  • Support as above and the acronym could easily confuse the reader, as normally an ATM is an Automated Teller Machine, so the acronym would confuse a reader if they only read the title (if they then read the lead they could see the context around the acronym).
The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page or in a move review. No further edits should be made to this section.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Asynchronous_Transfer_Mode/Archive_2&oldid=1083507357"