[email protected] (Seymour J Metz) writes:
> I would have loved to see an enhanced SNA with internetworking and
> DNS, but when CCITT refused to look at it, that wasn't an option.
>
> If the major TCP-based protocols at least switched to SCTP, that would
> be an improvement.

re:
http://www.garlic.com/~lynn/2019.html#3 Network Names

late 80s, I was on XTP technical advisory board ... that IBM
communication group found hard to block.

XTP has high-speed option for TCP/IP. Supported internetworking and
reliable delivery in minimum of 3-packet exchange (compared to TCP that
requires minimum 7-packet exchange for reliable transmission and the
earlier stanford VMTP that required minimum 5-packet exchange for
reliable transmission).

We had been doing rate-bassed pacing inside the HSDT effort (T1 & faster
speed links, both satellite and terrestrial) for several years ... and I
wrote the draft for rate-based in XTP. There was lots of XTP multi-cast
reliable work by various DOD organizations (went into navy's SAFENET).  Also
cleaned up some other stuff in TCP flow that was serialized ... so it
could be pipelined. Much of this was influenced from SGI and Greg
Chesson from SGI's pipelined graphics engines.

SCTP, XTP and TCP as transport protocols for high performance computing
on multi-cluster grid environments
https://dl.acm.org/citation.cfm?id=2127989
https://link.springer.com/chapter/10.1007/978-3-642-12659-8_17
Xpress Transport Protocol
https://en.wikipedia.org/wiki/Xpress_Transport_Protocol
SAFENET II-THE NAVY'S FDDI-BASED COMPUTER NETWORK STANDARD
(although it mentions the dreaded "OSI" word)
https://apps.dtic.mil/dtic/tr/fulltext/u2/a230482.pdf
XTP
http://www.cs.virginia.edu/~acw/netx/xtp_long.html

The Xpress Transport Protocol (XTP) has been designed to support a
variety of applications ranging from real-time embedded systems to
multimedia distribution to applications distributed over a wide area
network. In a single protocol it provides all the classic functionality
of TCP, UDP, and TP4, plus new services such as transport multicast,
multicast group management, transport layer priorities, traffic
descriptions for quality-of service negotiation, rate and burst control,
and selectable error and flow control mechanisms.

... snip ...

in some sense, SCTP is a later subset of some of the XTP features
https://en.wikipedia.org/wiki/SCTP
SCTP Oct2000.
https://tools.ietf.org/html/rfc2960

HSDT posts
http://www.garlic.com/~lynn/subnetwork.html#hsdt
XTP posts
http://www.garlic.com/~lynn/xtphsp
rate-based pacing draft for XTP (1989)
http://www.garlic.com/~lynn/xtprate.html

we were also doing some slight of hand with selective resend. There was
work with Berkeley Reed-Solomon company (that did a lot of the work for
CDROM standard, they were then bought by Kodak) on high-speed 15/16-rate
Reed-Solomon ... and selective resend (if couldn't be corrected by
RS-FEC) would transmit the 1/2-rate Viturbi (rather than original data,
could reasonably recover even if both packets had unrecoverable errors
with RS-FEC) ... and if things really got noisy, dynamically switch to
1/2-rate Virturbi (within 15/16-rate Reed-solomon).
https://en.wikipedia.org/wiki/Viterbi_decoder
https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction

Reed-Solomon codes are a group of error-correcting codes that were
introduced by Irving S. Reed and Gustave Solomon in 1960.[1] They have
many applications, the most prominent of which include consumer
technologies such as CDs, DVDs, Blu-ray Discs, QR Codes, data
transmission technologies such as DSL and WiMAX, broadcast systems such
as satellite communications, DVB and ATSC, and storage systems such as
RAID 6.

... snip ... 

-- 
virtualization experience starting Jan1968, online at home since Mar1970

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to