haas@wasatch.utah.edu (Walt Haas) (06/10/89)
We're in the market for Ethernet over twisted pair products. The guys from AT&T want to sell us Starlan-10 (surprise!) but I have a few questions about compatibility with Ethernet in general and 10BASET in particular: 1) Are there any compatibility issues that arise if I use existing Ethernet interfaces through AT&T's AUI adapters into Starlan hubs? 2) How big are the differences between Starlan and the forthcoming 10BASET, ie. if I buy a Starlan now, how well will it interoperate with the Brand X 10BASET products I buy next year? Thanks in advance for any information. Walt Haas haas@cs.utah.edu utah-cs!haas
viki@crash.cts.com (Victoria Harkey) (06/12/89)
In article <2009@wasatch.utah.edu> haas@wasatch.utah.edu (Walt Haas) writes: >We're in the market for Ethernet over twisted pair products. The >guys from AT&T want to sell us Starlan-10 (surprise!) but I have a few >questions about compatibility with Ethernet in general and 10BASET in >particular: > I am not familiar with the Starlan-10 product, but am impressed with Ungerman-Bass' solution to Ethernet over UTP; the product is called Access/One and I am fairly certain that it does conform to 10BASET. If you are seeking an Ethernet solution over unshielded twisted pair wire, I recommend that you take a look at Access/One. Disclaimer: I have nothing to gain from endorsing Ungerman-Bass products, I'm just impressed with some of their equipment. Viki Harkey Network Analyst, ISA, Inc. crash!viki@nosc.mil
ron@ron.rutgers.edu (Ron Natalie) (06/13/89)
If you're talking STARLAN 10, it is supposed to be compliant with the 10BASET draft standard out for vote. STARLAN (one, I guess) is not, but can be bridged to regular Ethernet. Hopefully everyone will embrace the 10BASET standard. Cabletron has already pledged converting their product to bring it in line with the standard. The other big player, Synoptics, hasn't been heard from yet with regard to their Lattisnet product. They've got a bigger problem as their product is not as close to the 10BASET draft as others are (their hubs are not repeaters). -Ron
mkd@mtunh.ATT.COM (Mark Darby) (06/14/89)
In <2009@wasatch.utah.edu>, Walt Haas (haas@wasatch.utah.edu) writes: >We're in the market for Ethernet over twisted pair products. The >guys from AT&T want to sell us Starlan-10 (surprise!) but I have a few >questions about compatibility with Ethernet in general and 10BASET in >particular: > >1) Are there any compatibility issues that arise if I use existing > Ethernet interfaces through AT&T's AUI adapters into Starlan hubs? > >2) How big are the differences between Starlan and the forthcoming 10BASET, > ie. if I buy a Starlan now, how well will it interoperate with the > Brand X 10BASET products I buy next year? > >Thanks in advance for any information. > >Walt Haas haas@cs.utah.edu utah-cs!haas Answer to 1 ----------- Let me first clarify that the AT&T AUI Adapter is in reality a TPMAU (TP = Twisted Pair) in IEEE Parlance, or a Twisted Pair transceiver in Ethernet Parlance. There shouldn't be any problem using the AT&T AUI Adapter with any interface card which has an IEEE 802.3/Ethernet Type 2 compliant AUI interface. The design guide for the AUI Adapter's AUI connector is Chapter 7 of the IEEE 802.3 green book. On the twisted pair side, the only real problem is making sure you have proper connectivity. Always make sure an OUT jack is connected to an IN jack at the other end, or vice versa. Answer to 2 ----------- The AT&T StarLAN 10 products today meet key technical parameters of the 10BASE-T draft: 1) Transmit level: the draft specifies 2.5 volts nominal peak 2) Equalization technique: at the transmitter, not the receiver 3) distance support: 100 meters on typical installed TP wire Greater distance in 25 pair is not feasible. 4) HUB element: a multiport repeater as specified in Chapter 9 of the IEEE 802.3 Supplement. This includes auto-partitioning, an option in Chapter 9, but mandatory in 10BASE-T. The AT&T StarLAN 10 architecture is based on HP's original proposal to 10BASE-T at the beginning of the standard-writing process circa 8/87. That basic proposal included symmetric transceivers, one at each end of a wire link, and that the 10BASE-T HUB is a Multi-Port Repeater, not to be confused with a concentrator. In fact, AT&T has direct (at the twisted pair interface) interoperability with HP's StarLAN 10 product, as well as Ungerman Bass's twisted pair Ethernet product. That's what standards are all about. One remaining key technical element exists which neither AT&T, HP, nor UB has implemented yet, at least not that I know of. That is the link integrity function. 10BASE-T proposes a function to determine the availability of the twisted pair link between endpoints (e.g. node to repeater). The function consists of periodic pulses transmitted on a link by link basis in the absence of true data. These pulses, transmitted/received correctly, will have no effect on other network elements. This function was added to the 10BASE-T draft near the end of the writing process and was radically changed just before the latest draft, assuring no one was ""compliant"". Any vendor with an existing pre-standard embedded base should make available a migration path to products based upon the final standard, with maintained interoperability between it's own pre-standard and post-standard products. AT&T's plan includes the ability of switching on and off the link integrity function per link on it's post-standard products to allow full interoperability with it's pre-standard hardware, along with pre-standard HP and UB products. Post-standard products from other vendors would need to implement a similar scheme to interoperate with pre-standard products, or face a forklift upgrade! As was stated earlier, the issue of link integrity is the only real outage, other than possibly a trivial nit or two, between the draft (as it stands now) and current product. The link integrity function has been changed by the task force just recently before letter ballot, and will probably change once again because of various holes in the overall function. The draft has completed letter balloting by the 802.3 Working Group. The 10BASE-T Task Force will meet later this month to resolve all NO votes from the balloting. Mark Darby 201-957-2706
John_Robert_Breeden@cup.portal.com (06/14/89)
>We're in the market for Ethernet over twisted pair products. The >guys from AT&T want to sell us Starlan-10 (surprise!) but I have a few >questions about compatibility with Ethernet in general and 10BASET in >particular: > >1) Are there any compatibility issues that arise if I use existing > Ethernet interfaces through AT&T's AUI adapters into Starlan hubs? > No, you should have no problem (you need an AUI port on your ethernet interface). >2) How big are the differences between Starlan and the forthcoming 10BASET, > ie. if I buy a Starlan now, how well will it interoperate with the > Brand X 10BASET products I buy next year? > As long as the OTHER vendors are 10baseT compatable (see note below), they will interoperate. As a matter of fact, two other vendors besides AT&T conform to the March '88 10baseT draft, Hewlett Packard and Ungermann Bass and you can mix and match the three vendors' HUBS, AUI's and NICs (AT&T by far is the least expensive of the three). NOTE: AT&T, HP and UB where the only three 10baseT draft compliant vendors as of the 1988 summer draft. At the December meeting, a new feature was proposed but not included in the draft (it is expected to be included in the draft when the IEEE meets this summer) and that's the"link status" packet, it tells the network that the device is there and up. It is expected that the draft will become a standard in the first quarter of 1990 - what this means is that the major parts of the protocol is for all intents and purposes set in concrete ie; there won't be any major changes in the draft that would make either AT&T, HP or UP non-compatable with the standard. What about the "status packet"? No vendor today supports it (it's not even in the draft yet). But if it becomes part of the draft, AT&T, HP, and UB will produce product that support it. Does this mean that anything I have prior to the new product goes out the window - the fork lift upgrade to make it work? No - that's the issue between compliant and compatable. A vendor could support the "link status" packet and have a switch on a hub's port to turn the packet OFF - then anything downstream could be a 10baseT product that doesn't support "link status" - ie: not 100% compliant with the standard, but 100% compatable (one must remember that "link status" is'nt required to make the ethernet function - it's really a management issue). The bottom line is that you can mix and match products from different vendors today and tomorrow, you're not stuck with a single vendor's proprietary solution - like Cabletron or Synoptics (that should ruffle some feathers). >Thanks in advance for any information. >Walt Hass "I'm prejudice because it's true" John Breeden - uunet!john_robert_breeden@portal.com
John_Robert_Breeden@cup.portal.com (06/15/89)
>If you're talking STARLAN 10, it is supposed to be compliant >with the 10BASET draft standard out for vote. STARLAN (one, >I guess) is not, but can be bridged to regular Ethernet. Hopefully >everyone will embrace the 10BASET standard. Cabletron has already >pledged converting their product to bring it in line with the >standard. The other big player, Synoptics, hasn't been heard from >yet with regard to their Lattisnet product. They've got a bigger >problem as their product is not as close to the 10BASET draft as >others are (their hubs are not repeaters). > >-Ron And Synoptics NEW product isn't 10baseT either.
rnicovic@polyslo.CalPoly.EDU (Ralph Nicovich) (06/15/89)
In response to the Starlan-10 and 10baseT. It is my understanding that HP's Starlan-10 and UB's Access/one was a joint development. I have the twisted pair adapters for both and they look identical (inside and out) except for the LOGO. I haven't seen AT&T's starlan but it is my understanding it is the same as HP's. It is my understanding (from a presentation from UB) that the proper way to test twisted pairs for these networks is to plug a TPAU (twisted pair access unit) on each end of the pairs, and then to use a "standard" (perhaps regular is more appropriate) Ethernet tester and run a test as though it was an Ethernet. I personally took this a little further and decided since a tester thought it was an Ethernet, why not use it as an Ethernet ? Well it worked. I put a multiport transceiver in each of two buildings which are connected through TPAU's to each other through 900 ft of telephone wire. This is a judgment call kind of network, not to any known standards, but it is fitting the needs of the user. Ralph Nicovich Network Engineering Cal Poly State University
morgan@Jessica.stanford.edu (RL "Bob" Morgan) (06/15/89)
John Robert Breeden writes: > As a matter of fact, two other vendors besides AT&T conform to the > March '88 10baseT draft, Hewlett Packard and Ungermann Bass and you > can mix and match the three vendors' HUBS, AUI's and NICs Here's a quote from the front page of the 10BASE-T draft dated April 7, 1989: > This is an unappproved draft which is subject to change and cannot be > presumed to reflect the position of Project 802 or the IEEE, Inc. > DO NOT SPECIFY OR CLAIM CONFORMANCE TO THIS DOCUMENT. To paraphrase Gene Shue, the standard ain't a standard 'til the fat lady sings. If you think you're buying conforming equipment before the standard is approved, you're only fooling yourself. - RL "Bob" Morgan Networking Systems Stanford
mkd@mtunh.ATT.COM (Mark Darby) (06/15/89)
In article <19449@cup.portal.com>, John_Robert_Breeden@cup.portal.com writes: > > NOTE: AT&T, HP and UB where the only three 10baseT draft compliant vendors > as of the 1988 summer draft. At the December meeting, a new feature was > proposed but not included in the draft (it is expected to be included in the > draft when the IEEE meets this summer) and that's the"link status" packet, > it tells the network that the device is there and up. It is expected that > the draft will become a standard in the first quarter of 1990 - what this > means is that the major parts of the protocol is for all intents and > purposes set in concrete ie; there won't be any major changes in the draft > that would make either AT&T, HP or UP non-compatable with the standard. > > What about the "status packet"? No vendor today supports it (it's not even > in the draft yet). But if it becomes part of the draft, AT&T, HP, and UB The link test function in the 10BASE-T letter ballot draft (Dated April 7, 1989, Document P802.3I/D6) consists of a transmission of a single positive pulse, 100 nanoseconds in duration, every 24 to 150 milliseconds in the absence of transmit traffic. The 10BASE-T MAU receiver does not detect the link test pulse as a packet reception. The link test function provides the means for the 10BASE-T MAU to determine whether the twisted pair link is available. This comes as a result of 10BASE-T's handling of loopback (loopback is done internally on the MAU, as opposed to externally, as is done on a typical 10BASE5 MAU). The twisted pair receiver does not pass the link test pulse through the MAU to the AUI, as this would result in a lot of unnecessary garbage floating around a network. The link test function is performed on a link by link basis. EVERY 10BASE-T port, whether on a 10BASE-T MAU or HUB, requires the link test function. So if you have 10BASE-T MAU A and 10BASE-T MAU B connected together via twisted pair, and neither is transmitting true data, each MAU is sending link test pulses to the other. If the twisted pair wire got cut, for example, both A and B would detect the absence of link pulses and disable their data transmit and data receive functions. The pulse transmit and pulse receive capabilities of the MAUs would not be affected. When the cable is repaired and the MAUs detect the link pulses once again (in a manner specified in 10BASE-T), the MAU's data transmit and receive capabilities are restored. > Does this mean that anything I have > prior to the new product goes out the window - the fork lift upgrade to make > it work? No - that's the issue between compliant and compatable. A vendor > could support the "link status" packet and have a switch on a hub's port > to turn the packet OFF - then anything downstream could be a 10baseT > product that doesn't support "link status" - ie: not 100% compliant with > the standard, but 100% compatable (one must remember that "link > status" is'nt required to make the ethernet function - it's really a > management issue). This is entirely true, assuming the new post-standard hardware is flexible enough to interoperate with the pre-standard stuff by the use of switches/ options to disable the incompatibility. Otherwise you run into some interesting network problems. > >Thanks in advance for any information. > > >Walt Hass > > "I'm prejudice because it's true" > John Breeden - uunet!john_robert_breeden@portal.com ------------------------------------------------------------------- Mark K. Darby AT&T: (201)957-2706 AT&T Bell Labs uucp:..!att!mtunh!mkd DISCLAIMER: The opinions expressed here are not necessarily those of my employer.
mkd@mtunh.ATT.COM (Mark Darby) (06/15/89)
In article <677@mtunh.ATT.COM>, mkd@mtunh.ATT.COM (Mark Darby) writes: > The link test function in the 10BASE-T letter ballot draft (Dated April 7, > 1989, Document P802.3I/D6) consists of a transmission of a single > positive pulse, 100 nanoseconds in duration, every > 24 to 150 milliseconds in the absence of transmit traffic. The 10BASE-T ^^ ^^^ || | \\-------- These numbers should be 8 and 24 milliseconds, respectively. The previous numbers refer to certain link test timer limits. ------------------------------------------------------------------- Mark K. Darby AT&T: (201)957-2706 AT&T Bell Labs uucp:..!att!mtunh!mkd DISCLAIMER: The opinions expressed here are not necessarily those of my employer.
mkd@mtunh.ATT.COM (Mark Darby) (06/15/89)
In article <12030@polyslo.CalPoly.EDU>, rnicovic@polyslo.CalPoly.EDU (Ralph Nicovich) writes: > > In response to the Starlan-10 and 10baseT. > > It is my understanding that HP's Starlan-10 and UB's Access/one > was a joint development. I have the twisted pair adapters for both > and they look identical (inside and out) except for the LOGO. > I haven't seen AT&T's starlan but it is my understanding it is > the same as HP's. As one of the developers of AT&T's STARLAN 10 products I can assure you that the development effort was done our own way. The development of STARLAN 10 was based solely upon the information received from the 10BASE-T standard writing process, independent of any other pre-10BASE-T standard product from other companies. > Ralph Nicovich > Network Engineering > Cal Poly State University ------------------------------------------------------------------ Mark K. Darby AT&T: (201)957-2706 AT&T Bell Labs uucp:..!att!mtunh!mkd
pat@hprnd.HP.COM (Pat Thaler) (06/17/89)
Bob Morgan writes: > > Here's a quote from the front page of the 10BASE-T draft dated April > 7, 1989: > > > This is an unappproved draft which is subject to change and cannot be > > presumed to reflect the position of Project 802 or the IEEE, Inc. > > DO NOT SPECIFY OR CLAIM CONFORMANCE TO THIS DOCUMENT. > > To paraphrase Gene Shue, the standard ain't a standard 'til the fat > lady sings. If you think you're buying conforming equipment before > the standard is approved, you're only fooling yourself. > > - RL "Bob" Morgan > Networking Systems > Stanford > ---------- This is something that all purchasers should know. Vendors and the press tend to use the words "conformant" and "compliant" very loosely. Any draft standard is a moving target and not a good measure of compliance. In buying product now, the important question to ask the vendor is "How will you support migration to 10BASE-T when the standard is completed?" As Mark Darby points out, 10BASE-T is a definition of a new MAU/transciever (802.3/Ethernet terminology). As such, the interface between the MAU/transceiver and the DTE/station is the AUI. This interface is already defined in 802.3 section 7. Since the interface is already defined, there should be no interoperation problems between well designed pre-standard 10BASE-T-like products and existing DTEs or repeater. The 10BASE-T draft defines the interface between the MAUs and the behavior of the MAUs. That interface is where the questions of interoperability between pre-standard products and 10BASE-T products arise. Mark Darby's comments on link test and the current status of 10BASE-T draft are accurate. 10BASE-T MAUs support a point-to-point links which are usually connected together through multi-port repeaters (see section 9 in the 802.3 Supplement, not the original section 9). If one only needs to support two stations, two MAUs could be connected with no repeater. Make sure the receive pair of one MAU goes to the transmit connection of the other. Because 10BASE-T uses repeaters as the hub of the star, you can use a coax or fiber-optic backbone to join the stars togeather. 10BASE-T segments can be added to existing networks. This is also true for pre-standard products which use repeaters as hubs. Products designed to support 100 m of cable reliably will often support longer distances if you try one instance. After all when we do the designs we have to allow for variations in MAU components and cables. The problems are: If you install it that way 100 times it may work 9 out of 10. It may work fine some days and not others. Temperature variations and noise variations may degrade performance. Degraded performance includes high bit error rate or not working at all. There are lower attenuation twisted pair cables available if you want to support more than 100 m. Or you can put in a repeater. Or use fiber which supports 1 Km or more. Pat Thaler 916-785-4538 My comments are my own and do not necessarily represent the opinions of the 10BASE-T task force. (So are my spellings. I was in a hurry and probably left some typos behind.)
pag@tcsc3b2.UUCP (Philip A. Gross) (06/21/89)
In article <19449@cup.portal.com>, John_Robert_Breeden@cup.portal.com writes: > >We're in the market for Ethernet over twisted pair products. The > >guys from AT&T want to sell us Starlan-10 (surprise!) but I have a few > >questions about compatibility with Ethernet in general and 10BASET in > >particular: > > You will find that the AT&T StarLAN 10 hardware is in fact Ethernet Network. The StarLAN software which you may purchase from AT&T uses the OSI Transport Layer instead of TCP/IP. Of course, you could implement your network using TCP/IP, if you chose to do so. But beware, TCP/IP from AT&T is mucho $$$ and is the Wollongong TCP/IP (gug), and for the AT&T 3B2, it is available ONLY from AT&T (darn!). Proof of point: I implemented an Ethernet Network using the AT&T StarLAN hardware with an NCR 32/650 Tower as a server. The Tower used Excelan's Ethernet board and TCP/IP as the transport layer. At the end of the transceiver cable was an AUI from which UTP cable was led to the StarLAN 10 HUB. From the HUB we connected a number of PC's with AT&T StarLAN 10 NAU cards over UTP. Now the network software was an interesting task, to say the least. With AT&T's StarLAN 10, they nicely bundle all of the software and document (?) the installation of it so that it is a fairly straight-forward task to get the network operational. Well, since we were using an NCR Tower, we were not able to use any of the AT&T StarLAN software, particularly since I was unable to find the OSI transport layer for it. We also needed the capability to mount virtual drives on the PC's to certain directories on the NCR Tower, ie, a RFS/NFS look and feel. Well, in order to do this, we obtained PC/TCP from FTP Software for the PC. This completed the TCP/IP transport layer interface end-to-end. Next, in order to provide the functionality of RFS, we installed Syntax's SMB Server on the NCR Tower and 10Net Communications 10Net+ Software on the PC's. Through SMB protocols, this software permitted us to link virtual disk drives on the PC's to certain directories on the Tower. Through the use of all of this software, not only is the PC user able to use the disk storage and file sharing capabilities of the NCR Tower but they were also able to hot key in telnet to provide them access to a login on the NCR Tower. PC/TCP also comes with a version of tar which permits the user to back the hard disk on the PC to the streaming tape drive on the NCR Tower. All-in-all, it was a very interesting task taking approx. 2-3 months to research, purchase, and install. Any questions, drop me a note. =============================================================================== Philip A. Gross The Computer Solution Co., Inc. Voice: 804-794-3491 ------------------------------------------------------------------------------- INTERNET: pag@tcsc3b2.tcsc.com USENET: tcsc3b2!pag UUCP: tcsc3b2!pag (804)794-1514 ATTMAIL: attmail!tcsc3b2!pag ------------------------------------------------------------------------------- The opinions expressed here are strictly mine and nobody elses. << I haven't heard what I have to say about that yet. >> :-)
henry@utzoo.uucp (Henry Spencer) (06/21/89)
In article <2230006@hprnd.HP.COM> pat@hprnd.HP.COM (Pat Thaler) writes: >...In buying product now, the important question to ask >the vendor is "How will you support migration to 10BASE-T when the >standard is completed?" You know, I'd really like to see at least one vendor reply to that question with "we won't, since we think twisted-pair Ethernet is a dumb idea and totally unnecessary". I don't expect that anyone's marketing department will let them get away with that, though... IEEE is showing a depressing pattern of being unable to say no to any proposal for a new standard. I realize the politics involved make this hard to fix, but it could use fixing. -- NASA is to spaceflight as the | Henry Spencer at U of Toronto Zoology US government is to freedom. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
morgan@Jessica.stanford.edu (RL "Bob" Morgan) (06/22/89)
Henry Spencer writes: > You know, I'd really like to see at least one vendor reply to that > question with "we won't, since we think twisted-pair Ethernet is a > dumb idea and totally unnecessary". I don't expect that anyone's > marketing department will let them get away with that, though... Well, Henry, I invite you to come and submit a cost-effective Ethernet design for our central campus, including connections to a few hundred faculty offices. If you want thin coax, remember to factor in the cost of asbestos removal from every ceiling and crawlspace. Don't forget you'll also have to pass your thinnet design past the architectural review board that won't allow molding to be run in the hallways or in many of the rooms. Can you see why twisted-pair Ethernet makes sense to (some of) us? - RL "Bob" Morgan Networking Systems Stanford
dave@westmark.UUCP (Dave Levenson) (06/22/89)
In article <1989Jun21.155639.21593@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: ... > You know, I'd really like to see at least one vendor reply to that question > with "we won't, since we think twisted-pair Ethernet is a dumb idea and > totally unnecessary". I don't expect that anyone's marketing department > will let them get away with that, though... While I wouldn't especially mind one vendor's taking that stand, I would certainly steel clear of any who did! Fortunately, if one vendor decided not to support twisted-pair ethernet, others would continue to support it. We sell, install, and service networked personal computers. We usually install them in existing older buildings. Today, most of these buildings are full of disused telephone wiring, left over when the 1A2 key telephone system was replaced by a modern system. The major cost of installing a system is neither the wire nor the network components, it's the labor involved in running the wire. If there is existing twisted-pair in the ceilings, walls, and equipment closets, it reduces the overall cost of installing a network by a factor of more than 50%! And it works! It may not be technically elegant, but it under-sells coax every time. That is not a dumb idea. That is not totally unnecessary. -- Dave Levenson Voice: (201) 647 0900 Westmark, Inc. Internet: dave@westmark.uu.net Warren, NJ, USA UUCP: {uunet | rutgers | att}!westmark!dave [The Man in the Mooney] AT&T Mail: !westmark!dave
roy@phri.UUCP (Roy Smith) (06/22/89)
In <1989Jun21.155639.21593@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: > You know, I'd really like to see at least one vendor reply to that question > with "we won't, since we think twisted-pair Ethernet is a dumb idea and > totally unnecessary". Why do you say that? Aside from the fact that I don't believe it can possibly work (just like I don't believe it's possible to build 9600 baud dial-up modems :-)), I think it's a grand idea. Makes good use of existing wiring and related technology. Not to mention trivial advantages like there are conduits set in the concrete in our building going to every room designed for phone lines. I can almost always snake another run of 4-pair twisted phone line through one of them if I have to, but running an Ethernet tranciever cable means knocking holes in cinderblock walls, and even RG-fifty-whateveritis can somtimes mean getting the drills and chisels out. What's your beef with twisted-pair Ethernet? -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network"
henry@utzoo.uucp (Henry Spencer) (06/22/89)
In article <3077@portia.Stanford.EDU> morgan@Jessica.UUCP (RL "Bob" Morgan) writes: >Well, Henry, I invite you to come and submit a cost-effective Ethernet >design for our central campus... [subject to troublesome constraints] Well, in return, I invite you to come and submit a cost-effective twisted- pair Ethernet design for connecting my apartment to my workplace. It's only a couple of kilometers away, surely an unimportant constraint... :-) Standards should not be expected to solve everyone's problems. Apart from some general dislike for the idea, standardizing twisted-pair Ethernet simply seems to me to be premature -- all the schemes are new enough that nobody has a good idea of which works best, as witness the wrangling over which one to adopt. If the current mania for standardizing everything immediately continues, our successors will curse our memories. "Our responsibility is to do what we can, learn what we can, improve the solutions, and pass them on. It is our respon- sibility to leave the people of the future a free hand. In the impetuous youth of humanity, we can make grave errors that can stunt our growth for a long time. This we will do if we say we have the answers now, so young and ignorant as we are. If we suppress all discussion, all criticism, pro- claiming "This is the answer, my friends; man is saved!" we will doom humanity for a long time to the chains of authority, confined to the limits of our present imagination..." - Richard Feynman -- NASA is to spaceflight as the | Henry Spencer at U of Toronto Zoology US government is to freedom. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
pat@hprnd.HP.COM (Pat Thaler) (06/23/89)
henry@utzoo.uucp (Henry Spencer) writes: > > You know, I'd really like to see at least one vendor reply to that question > with "we won't, since we think twisted-pair Ethernet is a dumb idea and > totally unnecessary". I don't expect that anyone's marketing department > will let them get away with that, though... > > IEEE is showing a depressing pattern of being unable to say no to any > proposal for a new standard. I realize the politics involved make this > hard to fix, but it could use fixing. > ---------- The IEEE 802.3 Working Group uses 5 Criteria to determine if a new standard should be developed. They are: Broad Market Potential Will the proposal serve a broad set(s) of applications? Will the proposal be used by many users and supported by multiple vendors? Compatability with IEEE Standard 802.3 Conformance with IEEE 802.3 MAC and PLS Conformance with IEEE 802.2 Distinct Identity Substantially different from other 802.3 specifications/solutions Does fill the needs of an application area not served by other 802.3 specifications? Technical Feasibility Demonstrated feasibility Confidence in reliability Economic Feasibility Reasonable cost for performance expected Total installation costs considered There have been proposals which were rejected as not meeting these criteria. In some of those cases, proponents modified their proposals and the revised proposals were accepted. At times, several similar proposals were brought to IEEE 802.3. Under the pressure of the Distinct Identity criteria, the proponents worked together to develop a single joint proposal. The additions to the original standard which IEEE 802.3 has developed or is developing have been of two types: Support of additional media, e.g. twisted-pair and fiber-optics; and additional capabilities, e.g. network management and conformance test. Some people feel as Mr. Spencer does. Others feel that IEEE 802.3 makes it too hard to start a new addition and that the process of showing that the criteria are satisfied takes too long. In my opinion, the process results in better additions to the standard due to the examining the objectives and synthesizing the ideas of the participants. In March of 1988, IEEE 802.3 decided that the 10BASE-T proposal met the 5 criteria. 10BASE-T and 10BASE-F (fiber optic) should allow 802.3 networks to be installed in buildings wired in accordance with EIA 41.8, a standard currently under development for building wiring. Pat Thaler My opinions are my own and do not necessarily represent those of the 10BASE-T Task Force.
jbvb@ftp.COM (James Van Bokkelen) (06/23/89)
In article <244@tcsc3b2.UUCP>, pag@tcsc3b2.UUCP (Philip A. Gross) writes: > ..... > obtained PC/TCP from FTP Software for the PC. This completed the TCP/IP > transport layer interface end-to-end. Next, in order to provide the > functionality of RFS, we installed Syntax's SMB Server on the NCR Tower > and 10Net Communications 10Net+ Software on the PC's. Through SMB > protocols, this software permitted us to link virtual disk drives on the > PC's to certain directories on the Tower. In the near future, OEM versions of PC/TCP will be available from both AT&T and 10Net/DCA. I believe that both versions will contain all the applications we ship to customers who buy from us direct. We also sell a version of LANWatch for the AT&T NAU card (one version runs on any of Ethernet, Starlan or Starlan-10). -- James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
ncpjmw@amdcad.AMD.COM (Mike Wincn) (06/24/89)
You know, there must be SOMETHING about living in a Zoo that alters one's sense of logic and reason. In one article, henry@zoo.toronto.edu (Henry "Flat Earth Delegate" Spencer) writes: >In article <2230006@hprnd.HP.COM> pat@hprnd.HP.COM (Pat Thaler) writes: >>...In buying product now, the important question to ask >>the vendor is "How will you support migration to 10BASE-T when the >>standard is completed?" >You know, I'd really like to see at least one vendor reply to that question >with "we won't, since we think twisted-pair Ethernet is a dumb idea and >totally unnecessary". ... so, Spencer is not interested in alternative, cost effective LAN solutions, and then in a following article he writes: >Well, in return, I invite you to come and submit a cost-effective twisted- >pair Ethernet design for connecting my apartment to my workplace. It's >only a couple of kilometers away, surely an unimportant constraint... :-) Instead of an investigation of feasability, or request for factual information, or logical argument to refute, he offers a taunt. Perhaps someone should instead check Mr. Spencer for leaking lobotomy scars. >Standards should not be expected to solve everyone's problems. Apart from >some general dislike for the idea, standardizing twisted-pair Ethernet >simply seems to me to be premature -- all the schemes are new enough that >nobody has a good idea of which works best, as witness the wrangling over >which one to adopt. If the current mania for standardizing everything >immediately continues, our successors will curse our memories. Intents of standardizing include, among others, ensuring operability of the system in its electrical environment and interoperability among various vendors. Operability is reviewed by the people who draft the standard, and I have yet to hear of any system that completed the standards development process and wound up not functional. Satisfaction of the constraints of interoperability ensures that one can't bring down the net merely by attaching some random vendor's product. Apparently, these concepts are foreign to Mr. Spencer. I have never heard anyone suggest that standards attempt to "...solve everyones's problems" and some standard is certainly preferrable to the chaos that would follow a situation where anyone with the manufacturing capability could offer any variation of LAN implementation he chose. Mr. Spencer's arguments are, at best, specious and uninformed. Mike Wincn ncpjmw@amdcad.AMD.COM (408) 749-3156 Disclaimer: The opinions expressed are my own, not necessarily those of my employer, nor those of 802.3 Committee or 10BASE-T Task Force.
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (06/24/89)
In article <26097@amdcad.AMD.COM>, ncpjmw@amdcad.AMD.COM (Mike Wincn) writes: > ...flames about Henry Spencer's irritation with the new twisted pair standard > > Mike Wincn > ncpjmw@amdcad.AMD.COM > (408) 749-3156 It does seem that at least some versions of twisted pair ethernet are quite handy. They are clearly easier to install, maintain, and so forth. Maybe it is time to have a Standard for them. It would certainly be nicer if there were fewer versions then already exist. Maybe there was a little intemperance in the original irritation. However, after the votes for less than compelling changes taken in the X3T9.5 FDDI SMT meeting on Wednesday, I am a little puzzled by someone from AMD defending the standards process. Can the FORMAC capture the 6 byte info field in the newly required "directed beacon"? If not, how might one build a network manager with the "SUPERNET Family for FDDI"? (I understand the FORMAC can at least send them, unlike the silicon of a big computer computer vendor.) Remembering milestones like "Extended BASIC" or "COBOL80" should be enough to make anyone unenthusiastic about standardization efforts before the market place has spoken. All too often, the process is turned into a way to increase employeement for consultants and a way for companies who are late to penalize those which had their act more together. Vernon Schryver Silicon Graphics vjs@sgi.com
sdjmc@amdcad.AMD.COM (John McCool) (06/25/89)
In article <36666@sgi.SGI.COM> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes: > >However, after the votes for less than compelling changes taken in the >X3T9.5 FDDI SMT meeting on Wednesday, I am a little puzzled by someone from >AMD defending the standards process. Can the FORMAC capture the 6 byte >info field in the newly required "directed beacon"? If not, how might one >build a network manager with the "SUPERNET Family for FDDI"? (I understand >the FORMAC can at least send them, unlike the silicon of a big computer >computer vendor.) I would like to clarify the operation of FDDI rings during recovery to avoid confusion. The short answer to Vernon's question is Yes. Here's the long answer: AMD's SUPERNET chipset for FDDI is capable of sending directed beacons during ring recovery. In addition, the chip set WILL receive beacons in buffer memory if the destination address matches the node's address (or is a broadcast). The FDDI MAC State Machines, however, may prevent reception of ANY FRAME during the ring recovery process. During ring recovery, the token passing protocol for transmission no longer holds. Several stations on the ring may be transmitting (beacons, claims, etc.) Under these conditions, an FDDI station will stop transmission on reception of a beacon frame. Subsequent directed beacons arriving before TMAX time will be received and repeated. Note that normal 'failed claim' beacons are not received by stations as their destination address = null. This is done to prevent buffer overflows during non-fatal physical layer reconfigurations. John McCool Advanced Micro Devices 802.3 Network Products (408)749-2302
ncpjmw@amdcad.AMD.COM (Mike Wincn) (06/26/89)
In article <36666@sgi.SGI.COM> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
<However, after the votes for less than compelling changes taken in the
<X3T9.5 FDDI SMT meeting on Wednesday, I am a little puzzled by someone from
<AMD defending the standards process. Can the FORMAC capture the 6 byte
<info field in the newly required "directed beacon"? If not, how might one
<build a network manager with the "SUPERNET Family for FDDI"? (I understand
<the FORMAC can at least send them, unlike the silicon of a big computer
<computer vendor.)
I'm not as acquainted with the FDDI program as I am with 10BASE-T. If I can
get an answer for you, I'll reply later...
<Remembering milestones like "Extended BASIC" or "COBOL80" should be enough
<to make anyone unenthusiastic about standardization efforts before the
<market place has spoken. All too often, the process is turned into
<a way to increase employeement for consultants and a way for
<companies who are late to penalize those which had their act more
<together.
<
<Vernon Schryver
<Silicon Graphics
<vjs@sgi.com
I can see that as a possible result, but I've not had any personal experience
along those lines. For 10BASE-T our primary concerns include feasibility and
interoperability, and while AMD joined this standard development later than
others, our goals have not included penalizing anyone. Our preference at this
stage is to offer silicon expertise in joint development with those who have
superior systems knowledge.
Mike Wincn
ncpjmw@amdcad.AMD.COM
(408) 749-3156
Disclaimer:
The opinions expressed are my own, not necessarily those of my employer,
nor those of 802.3 Committee or 10BASE-T Task Force.henry@utzoo.uucp (Henry Spencer) (06/26/89)
In article <26097@amdcad.AMD.COM> ncpjmw@amdcad.AMD.COM (Mike Wincn) writes: >You know, there must be SOMETHING about living in a Zoo that alters one's >sense of logic and reason... Fortunately I don't live in one (although I work in a Zoology department, which is almost as bad...) ;-) >... so, Spencer is not interested in alternative, cost effective LAN solutions I prefer solutions which don't involve serious technical compromises; last I heard, any twisted-pair 10Mbps network did. (I admit to not being familiar with the twisted-pair-Ethernet-proposal-of-the-week.) >>Well, in return, I invite you to come and submit a cost-effective twisted- >>pair Ethernet design for connecting my apartment to my workplace. It's >>only a couple of kilometers away, surely an unimportant constraint... :-) > >Instead of an investigation of feasability, or request for factual information, >or logical argument to refute, he offers a taunt. It was a satire on your argument, which essentially read "the usual standards don't solve *my* problem, therefore a new standard is needed". >I have yet to hear of any system that completed the standards development >process and wound up not functional... I can think of some that have never been implemented in their full form. I can think of others that are widely implemented, except that everybody ignores the stupid parts and does things right instead. I don't know what you consider "not functional", but these come close. And people whose opinions I consider reliable are seriously worried about some of the current mania, especially in Europe, for standardizing things that have never been tried and whose practicality is very unclear. There is also no shortage of standards that are functional, but verifiably inferior in essentially every way to the previous de-facto standards. >I have never heard anyone suggest that standards attempt to "...solve >everyones's problems" and some standard is certainly preferrable to >the chaos that would follow a situation where anyone with the manufacturing >capability could offer any variation of LAN implementation he chose. My contention is not that LAN standards are unnecessary, but that at 10 Mbps we have enough -- indeed, too many -- of them already. We would be better served by one or two *good* ones than by standardizing every variation anyone's marketing department can think of. -- NASA is to spaceflight as the | Henry Spencer at U of Toronto Zoology US government is to freedom. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (06/27/89)
In article <26111@amdcad.AMD.COM>, sdjmc@amdcad.AMD.COM (John McCool) writes: > > AMD's SUPERNET chipset for FDDI is capable of sending > directed beacons during ring recovery. In addition, the chip set WILL > receive beacons in buffer memory if the destination address > matches the node's address (or is a broadcast). > > John McCool > Advanced Micro Devices > 802.3 Network Products > (408)749-2302 That is encouraging. Since the new directed beacon is to a "multicast address", will a network manager using AMD's SUPERNET have to go into promiscuous mode to receive the beacon? Or have external address detect hardware? Of course, in the case of the directed beacon, we know we're stuck at beacon, and so have plenty of time to reset the FORMAC into promiscuous mode. Please note that the original topic was standards processes. It looks as if AMD survived Wednesday's change, aside from the hassle of promiscuous mode. However, there are plenty of SMT meetings left where the problem that AMD's current silicon is usable can be fixed. Not that anyone with much memory needs more evidence of the dangers of standards meetings. Vernon Schryver Silicon Graphics vjs@sgi.com
ncpjmw@amdcad.AMD.COM (Mike Wincn) (06/27/89)
In article <1989Jun26.163706.1078@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >I prefer solutions which don't involve serious technical compromises; last >I heard, any twisted-pair 10Mbps network did. (I admit to not being familiar >with the twisted-pair-Ethernet-proposal-of-the-week.) I don't understand what you consider a 'serious technical compromise', unless you are truly concerned with getting to your office from home with exclusive use of twisted pairs. Every communication medium has some kind of limitation, and the market generally decides which best suits the application (or, if you prefer, which causes the least pain). The last thing an end user needs is a plethora of differnet choices with none of them compatible. If no one was interested in compatibility, standards would all be ignored. It has been stated that 10BASE-T is intended to circumvent the less cost- effective (and thus 'painful') choices of Tolken-Ring and COAX Ethernet. It has also been stated that a strong market already exists for Twisted Pair LAN (though perhaps not mentioned in this newsgroup). [...comments about cost effective twisted pair from his home to his office, deleted..] > >It was a satire on your argument, which essentially read "the usual standards >don't solve *my* problem, therefore a new standard is needed". I make no such claim. My point is that there a many vendors who already offer a version of Twst.Pr. Ethernet, and many others who are ready to do so. From many reports there exists a strong market desire for such media access method. As long as there are going to be many players it makes perfect sense to me that they should all be compatible at some minimal level. We could all wait for the market to decide what that minimal level is, but we then may never be able to take advantage of the reduced interconnect cost. We could wait for some one vendor to 'invent' or 'discover' classes of media access, like 10BASE-T, but then we would have to wait to discover precisely _what_ will be offered and place trust in diligence and accuracy of ONE feasibility study (when and _IF_ such study was done). >>I have yet to hear of any system that completed the standards development >>process and wound up not functional... > >I can think of some that have never been implemented in their full form. >I can think of others that are widely implemented, except that everybody >ignores the stupid parts and does things right instead. I don't know what >you consider "not functional", but these come close. And people whose >opinions I consider reliable are seriously worried about some of the current >mania, especially in Europe, for standardizing things that have never been >tried and whose practicality is very unclear. No one is restricted from deviating from a standard. Any vendor can offer any product or combination of products he so chooses in any form that his manufacturing process allows. Given a choice between a 'compliant' product and a 'non-compliant' product, or 'standard' and 'non-standard', which do you think most end users prefer? Does it make sense to you that we SHOULDN'T invoke a process that weeds out those schemes "...whose practicality is very unclear" ? Go back and re-read Pat Thaler's comments on IEEE's standards process. 'Not functional' means 'doesn't work', even in its most basic form. Clearly, if some standard exists for a system which doesn't work, buyers are free to take their dollars (yen, guilders, marks, etc.) elsewhere. No one system is completely perfect or satisfies all needs, else we'd only HAVE one. You're looking for one or two perfect media access methods? I have some advice for you: Get used to disappointment. You want exclusive use of COAX and Tolken Ring? Hang on a little longer - there'll be plenty of spare hardware for you to buy. >There is also no shortage of standards that are functional, but verifiably >inferior in essentially every way to the previous de-facto standards. Okay, I'll bite... verify it. [...] >My contention is not that LAN standards are unnecessary, but that at >10 Mbps we have enough -- indeed, too many -- of them already. We would >be better served by one or two *good* ones than by standardizing every >variation anyone's marketing department can think of. ...and there once were people who thought that the world was flat, and that there was no need to consider any other possibility. Mike Wincn ncpjmw@amdcad.AMD.COM (408) 749-3156 The opinions expressed are my own, not necessarily those of my employer, nor those of 802.3 Committee or 10BASE-T Task Force.
henry@utzoo.uucp (Henry Spencer) (06/27/89)
In article <26135@amdcad.AMD.COM> ncpjmw@amdcad.UUCP (Mike Wincn) writes: >... My point is that there a many vendors who already >offer a version of Twst.Pr. Ethernet, and many others who are ready to do >so. From many reports there exists a strong market desire for such media >access method. As long as there are going to be many players it makes >perfect sense to me that they should all be compatible at some minimal level. Provided that we understand the tradeoffs involved and the technical alternatives. It is not at all clear to me that there is enough real, live experience with the hardware to justify that. >... Does it make sense to you that we >SHOULDN'T invoke a process that weeds out those schemes "...whose >practicality is very unclear" ? I think such a process would be great, if it existed. The current standards process does not consistently do this. IEEE, to give them credit, often does okay. That's not universally true of other standards bodies, unfortunately. Actually, there is such a process: real world experience with hardware. Standardization should be based on that, rather than trying to anticipate it. >>There is also no shortage of standards that are functional, but verifiably >>inferior in essentially every way to the previous de-facto standards. > >Okay, I'll bite... verify it. The lower layers of ISO networking, versus TCP/IP. (The ISO folks do seem to be doing some useful things at higher levels. One could wish they would concentrate on that and leave the lower ones alone.) >>... we have enough -- indeed, too many -- of them already. We would >>be better served by one or two *good* ones than by standardizing every >>variation anyone's marketing department can think of. > >...and there once were people who thought that the world was flat, and that >there was no need to consider any other possibility. And surprise surprise, once the dust settled -- as the result of real-world experience, not theological pontification -- one and only one possibility turned out to be useful and correct. Do *you* feel any need to consider the possibility that the world might be flat? :-) -- NASA is to spaceflight as the | Henry Spencer at U of Toronto Zoology US government is to freedom. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
ncpjmw@amdcad.AMD.COM (Mike Wincn) (06/29/89)
In article <1989Jun27.165911.1613@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <26135@amdcad.AMD.COM> ncpjmw@amdcad.UUCP (Mike Wincn) writes: [...] >>access method. As long as there are going to be many players it makes >>perfect sense to me that they should all be compatible at some minimal level. > >Provided that we understand the tradeoffs involved and the technical >alternatives. It is not at all clear to me that there is enough real, >live experience with the hardware to justify that. Granted. How can I make this more clear? AT&T, DEC, HP, SynOptics, and many others provided a small mountain of technical data on TwstPr Ethernet over the course of draft standard development. The data consisted of combinations of theoretical analysis, computer simulation, and _measured performance_ on _real hardware_ in _existing installations_. In many cases measured performance was indistinguishable from simulation and/or theory. In cases where there was an observable difference, further work concluded that some of those differences were not significant enough to warrant concern. Where concern was warranted, the draft was modified to reflect that concern. I don't know how else I can convince you, other than by wheeling a lab setup and 'scope cart into your office. My understanding is that TwstPr Ethernet systems have been in use in various sites for at least a year, and the market has shown little, if any, sign of reluctance to continue. And I'm talking production quantities, not some tweaky, onesey/twosey thing that some technician threw together in a lab one otherwise boring afternoon... (And before you ask, go call AT&T, DEC, HP, SynOptics, etc., etc.) >>... Does it make sense to you that we >>SHOULDN'T invoke a process that weeds out those schemes "...whose >>practicality is very unclear" ? > >I think such a process would be great, if it existed. The current >standards process does not consistently do this. IEEE, to give them >credit, often does okay. That's not universally true of other standards >bodies, unfortunately. Go back and re-read my earlier comments. No system is perfect, let the others catch up to reality. In the meantime, no one isforced to buy anything. My disagreement is with uninformed conclusions. [...] >>>There is also no shortage of standards that are functional, but verifiably >>>inferior in essentially every way to the previous de-facto standards. >> >>Okay, I'll bite... verify it. > >The lower layers of ISO networking, versus TCP/IP. ...so I'm told. Re-read my earlier comments. Maybe a message will start to sink in. >>>... we have enough -- indeed, too many -- of them already. We would >>>be better served by one or two *good* ones than by standardizing every >>>variation anyone's marketing department can think of. >> >>...and there once were people who thought that the world was flat, and that >>there was no need to consider any other possibility. > >And surprise surprise, once the dust settled -- as the result of real-world >experience, not theological pontification -- one and only one possibility >turned out to be useful and correct. Do *you* feel any need to consider >the possibility that the world might be flat? :-) If you really understood my points, you already know the answer. Mike Wincn ncpjmw@amdcad.AMD.COM (408) 749-3156