[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::fddi

Title:	FDDI - The Next Generation

Moderator:	NETCAD::STEFANI

Created:	Thu Apr 27 1989
Last Modified:	Thu Jun 05 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2259
Total number of notes:	8590

65.0. "XTP for FDDI" by HAMCL3::MOELLER () Wed May 16 1990 11:58

    Hello,
    
    has anybody heard something about a protocol called: XTP
    which stands for Express Transfer Protocol. It is currently
    under development by Protocol Engines,Inc., a consortium made
    up of computer companies. 
    My question is:
    
      1. Is Digital one of the consortium members ?
    
      2. Is Digital going to implement XTP in FDDI ?
    
    
    Thanks....Juergen

T.R Title User Personal
Name Date Lines

65.1 not widely useful, more marketing hype DELNI::GOLDSTEIN Offer void in Sectors N and R Thu May 17 1990 18:29 22

T.R	Title	User	Personal Name	Date	Lines
65.1	not widely useful, more marketing hype	DELNI::GOLDSTEIN	Offer void in Sectors N and R	`Thu May 17 1990 18:29`	22
	Protocol Engines, Inc. is a privately-held corporatioan spun off of Silicon Graphics for the purpose of marketing XTP, whose development primarily takes place at SGI. PEI intends to sell an XTP "Protocol Engine" chipset, as well as a TCP "Protocol Accelerator" chipset. At the moment their principal source of revenue appears to be selling seats on their consortium at $25k a pop; there were 19 members reported as of last week. Digital is not a member of the consortium. Nor is it likely that we'll join, IMHO, though I'm simply speaking my own opinion and tea-leaf reading. XTP isn't really suitable for what we do (data processing), rather, it's more aimed at things like multi-screen image display. It provides a semi-reliable multicast service. But we already get multicast out of FDDI, and being "almost reliable" isn't good enough -- we need a REAL transport layer when we want reliability! Also, there's NO flow control other than rate-based, so if (say) the receiver has to go to disk and its buffers are full then the bit bucket fills up... So XTP is a fairly narrowly-oriented protocol. If there is some special purpose that needs it, fine, but it's not going to replace what DNA and TCP/IP already have in layers 3 and 4. fred

    Protocol Engines, Inc. is a privately-held corporatioan spun off of
    Silicon Graphics for the purpose of marketing XTP, whose development
    primarily takes place at SGI.  PEI intends to sell an XTP "Protocol
    Engine" chipset, as well as a TCP "Protocol Accelerator" chipset.
    At the moment their principal source of revenue appears to be selling
    seats on their consortium at $25k a pop; there were 19 members reported
    as of last week.
    
    Digital is not a member of the consortium.  Nor is it likely that we'll
    join, IMHO, though I'm simply speaking my own opinion and tea-leaf
    reading.  XTP isn't really suitable for what we do (data processing),
    rather, it's more aimed at things like multi-screen image display. It
    provides a semi-reliable multicast service.  But we already get
    multicast out of FDDI, and being "almost reliable" isn't good enough --
    we need a REAL transport layer when we want reliability!  Also, there's
    NO flow control other than rate-based, so if (say) the receiver has to
    go to disk and its buffers are full then the bit bucket fills up...
    
    So XTP is a fairly narrowly-oriented protocol.  If there is some
    special purpose that needs it, fine, but it's not going to replace what
    DNA and TCP/IP already have in layers 3 and 4.
         fred