FWD: Re: thoughts on personal systems and ISDN

Robert L Ullmann <ULLMANN@process.com> Thu, 07 May 1992 15:13 UTC

Received: from nri.nri.reston.va.us by ietf.NRI.Reston.VA.US id aa02694; 7 May 92 11:13 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa22929; 7 May 92 11:18 EDT
Received: from nri.reston.va.us by NRI.Reston.VA.US id aa22807; 7 May 92 11:18 EDT
Received: from sirius.process.com by NRI.Reston.VA.US id aa22802; 7 May 92 11:16 EDT
Date: Thu, 07 May 1992 11:15:00 -0400
From: Robert L Ullmann <ULLMANN@process.com>
To: isdn@list.prime.com
Cc: iplpdn@nri.reston.va.us
Subject: FWD: Re: thoughts on personal systems and ISDN
Message-ID: <9205071116.aa22802@NRI.Reston.VA.US>

From: Henry Sinnreich <0002498337@mcimail.com>
	It seems to me that you would like a data service that is:
		Connectionless, and has
		Public addressing,
		Global addressing,

	and if you add the the requirement to exchange messages
	containing graphics with sub-second response time, we have
	SMDS, the Switched Multi-Megabit Data Service as emerging in
	the US and Europe. I am refering to the T3-E3 data rates (45
	& 34 Mb/s) respectively. 

SMDS (and, e.g. ATM) is certainly a good looking solution in
the 25-100Mbit range. As you point out, it isn't likely to
be universally available at affordable rates soon. (I would
like to live in a world where every local-loop is 100+Mb
fiber, but it isn't going to be tomorrow :-)
 
	Personal opinion: 64 kb/s does not look like you local LAN
	is good for text only, and you can get text with any modem
	communication worldwide. Dialing time of seconds whenever
	you open a rempote application or window (another VC) also
	does not look local. 

There is a _very_ substantial difference between 64 Kb
transparent access and what can be done with an analog
modem (e.g. Tbit at 18.031 Kb). The feel isn't what a
local LAN has, but it is fairly good.

Note that present-day X.25 PSDNs have setup times in the 50
to 500 msec range, with some international connections
sometimes taking 2-3 sec, but averaging less. This can
result in a slightly "sticky" feel, compared to a LAN, but
only at the very beginning of an operation.

ISDN service providers are going to have to bring their
setup times down into this range.

A procedure that sets up a D or local-B channel VC on
initial demand, then tries to open an end-to-end B only
when traffic warrants, will feel very responsive. (As well
as maintaining connectivity in the absence of available B
channel(s) at either end.)

	Please advise if SMDS would meet your needs if it were
	available and affordable, or if you see a problem. I would
	appreciate your thoughts.

	Henry 

A mixture of ISDN (universal connectivity) and SMDS and/or
ATM (providing high-bandwith where the cost can be met)
seems like a good answer; our job is to bury the differences
down somewhere under layer 4 so that the user just sees
more-or-less performance.

"You want to just pour money at it." -- Dennis Komisky
(Meaning: People don't want to have to change things to get
more and better performance; they just want to pour money
at it.)

[Totally irrelevent note: This, IMHO, is _the_ problem with
government today; change is in fact needed, but they still
want to just pour money: it is much safer, politically.]

The fact that SMDS and ISDN use the same addressing is quite
useful. There isn't any interoperation at the moment, but it
would be _real_ slick if an SMDS "call" (i.e. a packet
arriving) at an ISDN address got put inside a VC, and a VC
opened to an E.163/164 address that was in fact an SMDS line
would cause it to be terminated in the net, with the packets
going into the SMDS service.

The IP routing layer could, for example, use the methods of
RFC1183 to discover E.163/164 addresses (ISDN RR type) and
use them without knowing what kind of access the remote 
actually has.

Or slightly less transparently, a returned diagnostic which
says: that access line (ISDN number) must be reached by
SMDS (or vice versa); the router then using some configured
service to reach the other.
 
Best Regards,
Robert Ullmann
Process Software Corporation