|  |     You've raised a lot of interesting questions.  I have yet to see a
    Digital networks position paper on switched Ethernet vs. 100Mb Ethernet
    vs. FDDI vs. ATM.  We seem to have done a lot of work in all of those
    products, but nothing concrete that describes where one is better used 
    than another.  Bill Hawe (ERLANG::HAWE) is the Technical Director for
    NPB, so you may want to contact him to see if such a position has taken
    place.
    
    Regarding 100Mb Ethernet - for NIC-related questions, contact Mike
    Oconnor (NETCAD::OCONNOR) who is the Adapters group manager.  For
    DEChub-related questions, I suggest the DECHUB Notes conference(s) or
    contacting one of the business managers.
    
    >>	If these vendors can produce $100 cards AND produce a switch which
    >>	is priced the SAME as our GIGAswitch, how are we going to compete
    >>	with $700 PCI UTP FDDI cards?
    
    If they're quoting $100 cards to MCI, then they're just low-balling.  I
    can't imagine 10/100 Ethernet PCI adapters selling that low.  However,
    I'm in engineering, not sales, so it might be true.  We feel that our
    PCI UTP prices are fairly good and hope that the street price will be
    much lower to make it competitive with other high-performance NICs. 
    
    We (mostly me) also feel that FDDI and Fast Ethernet can peacefully
    coexist in the PC space.  On the desktop, I concur that 10/100 cards
    will be more cost-effective for customers.  On the server end, the
    decision is more difficult since FDDI offers more fault tolerance,
    is widely interoperable (today), connects easily to the backbone (of
    which FDDI is quite common), and offers excellent throughput for
    larger packets sizes since the maximum packet size is 3 times that of
    Ethernet and Fast Ethernet.  In bridged Ethernet-FDDI environments
    the difference may not be extreme, but in FDDI-FDDI environments the
    difference will likely be noticeable.
    
    For additional thoughts on the subject, contact George Nielsen
    (DELNI::G_NIELSEN) who is the PM for our FDDI PCI and EISA cards.
    
       - Larry
 | 
|  |     
    	Re .-1
    
    	"I can't imagine 10/100" .... 
    
    	Does this mean that the 100 mbit Ethernet cards can run either
    10 or 100?
    
    	We are getting more questions from our ISV's about 100 Mbit cards
    and so far I am putting them off by saying ATM is around the corner and
    FDDI is here today, but if they can deliver true 100Mbit performance
    into hubs that can run either 10 or 100 per port, and can deliver this
    in the next few months, we may need that position papaer sooner than
    later.
    	
    					Bill
 | 
|  |     >>	Does this mean that the 100 mbit Ethernet cards can run either     
    >>10 or 100?
    
    Yes.  The Fast Ethernet standard that we're focusing on in APG is the
    IEEE 802.3 standard which is basically the same CSMA/CD protocol of
    existing 10Mbps Ethernet.  Cards as well as hubs can be designed to
    support both standards through the same connector.  Of course, this
    introduces issues like
    
    	- how do you hot configure 10 to 100 then back again?
    	- how do you notify protocols after binding that your throughput
          capacity just changed?
    
    >>	We are getting more questions from our ISV's about 100 Mbit cards
    >>and so far I am putting them off by saying ATM is around the corner and
    >>FDDI is here today, but if they can deliver true 100Mbit performance
    >>into hubs that can run either 10 or 100 per port, and can deliver this
    >>in the next few months, we may need that position papaer sooner than
    >>later.
    
    This is an important message about the fact that FDDI is a standard,
    robust architecture that is supported by almost every hub and option
    vendor.  However, ultimately the price-per-port of FDDI will likely
    doom any possibility of displacing Ethernet on the desktop.  As a
    backbone and server/workstation technology, however, I think FDDI today
    provides a lot of management capabilities, fault tolerance, peformance,
    and robustness over Fast Ethernet.  As more powerful processors convert
    DOS Intel PC's into workstations running real operating systems, we're
    seeing more interest in getting higher performance NICs.
    BTW: Be careful about the "true 100Mbit performance" qualifier.  As
    specific FDDI implementations don't get 100Mbps, neither will 100Mbps
    Fast Ethernet.  However, depending on the use, network configuration,
    software implications, etc, one or the other technology may be a better
    choice.
    
    On the point of migrations, here are some of my thoughts on how we can
    position this:
    
    	1. For existing 10Mbps Ethernet customers, provide an upgrade path
           via 10/100 Mbps cards so they don't immediately have to upgrade
           their hubs.  They can run 10 today, 100 tomorrow as their
           requirements change.
        2. For existing 4/16Mbps Token-Ring customers, FDDI may be a closer
           analogy as an upgrade path.  TR vendors like Madge are already
           touting FDDI as simply "Fast Token-Ring".  Though I don't agree
           with the moniker, we can try the idea out on TR customers to see
           if they're willing to migrate to FDDI.  The message being that
           Token-Ring is behind the technology curve, they can add FDDI
           without a complete upgrade, and they have a migration path to
           ATM since FDDI-ATM interoperability exists today.
        3. For customers that already have FDDI backbones, offer the idea
           that they can improve their performance by moving their servers
           and high-powered workstations directly to the FDDI ring.  The
           majority of clients can be bridged or switched onto the Ethernet
           or Fast Ethernet.
        4. For customers that have a 10Mbps Ethernet backbone, the jury is
           still out on which technology (100Mbs Ethernet vs. FDDI) makes
           for a better backbone, but I have my own opinion on the subject.
    
       - Larry
 |