Conference 7.286::fddi

    We are "thinking" (not to mention "doing", but we shouldn't talk about
    unannounced products here, should we?) about making ATM and FDDI play
    together.
    
    In the outside world, ATM has started acquiring the "big mo" and taking
    it from FDDI.  There are, in short, three main reasons why this is
    happening:
    
    	1) ATM may be more cost-effective in the long term.  Because it
    	   doesn't use shared media but switched media, and can mix
    	   medium types and speeds, it may be more flexible and extensible
    	   than FDDI while not much costlier, if any.  (It's not a likely
    	   low-end candidate, though.)
    
    	2) It promises multimedia.  That is, it supports more services
    	   than FDDI.  While connection-oriented, ATM supports both
    	   asynchronous (packet) and reasonably-well-emulated isochronous
    	   connections, at a very wide range of speeds.
    
    	3) LAN/WAN integration.  Because ATM began as a WAN (telco)
    	   technology, it has no visible LAN/WAN boundary.  A
    	   transcontinental connection is as easy as one down the hall,
    	   once the network's built.  From the network designer
    	   viewpoint, it's even more complicated than the phone system
    	   (not trivial; that's what I do for a living), but from the
    	   end user viewpoint, the phone system's pretty appealing.
    
    The CCITT has already finished a (preliminary) set of standards, and is
    adding more.  In fact, I just sent in my ANSI letter ballot on the
    dPANS for the ATM Layer spec.  And the ATM Forum has finished Issue 1
    of its implementation agreement.  None of these are, like the FDDI
    spec, a complete roadmap to a workable network.  There are many tricks,
    traps, traumas and tribulations that you go through to get a working
    ATM system.  It's bleeding edge technology today, with a few systems
    built and many in the trial stage.  But its problems are not insoluble.
    
    It's important not to panic.  A natural DECreaction is to blast ATM as
    evil, wicked, mean and nasty, because it's harming our investment in
    FDDI.  That's bad.  The key is to position the two as working together.
    FDDI works today, is bulletproof and deliverable.  ATM is an
    evolutionary course, not a point product.
    
    I do have a little paper on the topic of ATM-as-a-LAN, in plaintext,
    which can be copied from
    	CARAFE::USER1:[GOLDSTEIN.DOC]ATMLAN.TXT
    
    If I get around to it, I'll finish up a rather longer paper on how ATM
    networks are leading to a major paradigm shift in networking, which
    will require us to refocus our LANcentric thinking and for that matter
    organization.  Summary:  LANs and WANs merge into switched nets; ATM is
    simply the first popular protocol for building them.
        fred

    Thanks Fred for an excellent "summary" resonse, this is just the kind of 
    answer I was looking for. I shall copy your paper for more information.
  
    Is there a notesfile or other forum specific to these emerging technologies 
    and/or the associated changes we all face as "designers/implementers" of 
    networks ?
  
    Yet more study/learning to be done..... will it never end ?   ;^)
  
    Regards
  
    Rog

Fred, I would also like to say thanks for the 'summary'. Believe you me 
it took awhile to find anything on ATM hidden amongst FDDI!! How about 
you starting an ATM TOPIC and keeping us up to date on whats going on. My 
customers are basically universities and you know how these 'whizzos' are 
with leading-edge-technology.

Eddie

As another person who is trying to learn all I can about ATM, I can suggest
the following two articles:

	"High-performance networks challenge Ethernet", Computer Design
	magazine, July 1992

	"ATM becomes part of the LANscape", Electronic Engineering Times,
	July 20, 1992

    Last week, I was a member of a panel discussion on ATM vs FDDI at
    Local Computer Networking Conference, Minneapolis, MN. My pro-FDDI
    views, which may be helpful to some of you who are trying to sell
    FDDI, are available on-line:
    
    FILES::net$arch:[papers]ATM_VS_FDDI_SLIDES.PS
    
    -Raj Jain

    I read over the slides identified in -.1. I found them interesting and
    definitely PRO-FDDI. Would it be possible to obtain the notes that went
    with these slides? I'd be interested in seeing the oppositions slides 
    as well.
    
    Is there a way to obtain copies of the PRO-ATM slides and notes?
    
    Mike
    

    Yes, Raj's slides are definitely pro-FDDI.  But they tend to go a bit
    overboard in bashing ATM for what it isn't.  It only works on its own
    terms, which are definitely not FDDI's.  Here are my comments on the
    topic:
    
These are my comments on the slides "ATM and FDDI" by Raj Jain, reflecting 
my understanding of FDDI and ATM issues.
    fred

(No changes to "Problems with FDDI" and "Impediments to FDDI" pages.)

	Impediments to ATM

>1.  Standards delayed.
**should be:

1.  Standardization based at CCITT
	Heavy international involvement
	->Longer standardization delays.

**note:  CCITT is a slow process; ATM is actually happening there
**_too_ quickly, because it's standardizing things before they're tested.

2.  Too many options too soon
	Many independent forums
	-> People energy divided

>3.  Cost:  Higher

**"Probably higher than FDDI" is more accurate, since there is a school of 
**thought that ATM can be made cheaper or the same as FDDI or 
**switched-FDDI.  This makes sense if you approach the problem correctly.

>4.  Low adapter performance:  
>	Performance easier to achieve with larger cells

** True in today's adapters (Fore) but not necessarily with new
** silicon, like AToM-3.

5.  Inefficient hosts/software
** Today.

6.  Insufficient applications. Only long-haul backbone will succeed.
** 1990 thinking no longer current.  High-performance LAN is a likely
** success.

	Good points of ATM/BISDN

>1.  Cell size is fixed
>	->Easier to handle/store/forward

>2.  Easier to count and bill.

>3.  Slotted system
>	->Better scalability in terms of distance-bandwidth product.

>4.  Complexity moved to edges.  No hop-by-hop retransmission.

>5.  Distributed-media shared-switch topology.

**That page is okay.  But I'd add two more that the market cares about:

6.  Same protocol works in LAN and WAN environment
	-> potential for simpler interworking

7.  Support for high-speed isochronous channel emulation.

>	Myth of Scalability

** I don't really understand this argument.  Maybe I had to be there.
** ATM's scalability is based on the switched nature of the topology.
** If you provision bandwidth, an arbitrary mesh will get you there.
** Model:  Telephone network.  It's scalable because demand can be
** forecast.

>	Problems with ATM

>1.  Key issues such as flow/congestion not resolved.
** True, though it's more accurate to say:
1.  Key issues such as efficient flow and congestion control are
not resolved. 
	Problem pushed to users.
	Rate-based operation unnatural for data

>2.  Inefficient broadcast/multicast

>3.  Inefficient for large transfers

** Unclear.  Small-packet transfers have more waste.  Better to say:
3.  Inefficient use of bandwidth.
	often 40% and greater overhead 

>4.  Connection-oriented
** because this isn't purely "bad" but religious, add:
	More difficult to integrate with connectionless 
	 networks, LANs.
	Connection management not yet resolved

>5.  Large initial cost.

>6.  48 bytes suitable for voice at low speed.
>	Non-optimal at higher speeds.
>	Highly unsuitable for video.

**That's too generous!  It's mediocre for voice.  It's too short
** for efficient data.  Video issues are unresolved; it could be
** made to fit if cell-based coding were used.

>7.  Scalability is a myth.
** Huh again?

>Another Technical Mistake (like ISDN)
** ISDN is NOT really a technical mistake, though it is of course 
** imperfect..  It has been a terrible Marketing
** mistake in the US, because the RBOCs positioned it against LANs
** (the old "versus" instead of "complementary" problem) instead of
** against modems and analog lines.  ATM's problem is that it's an
** interesting set of ideas assembled by a committee, so the 
** resultant protocol details are a mess, requiring lots of work-arounds
** and careful navigation amongst the options.

>	ATM and FDDI

** No changes to the page per se, but it seems a bit strange to praise
** FDDI on its video merits and say that ATM has to succeed on data
** alone.
    

Re: .1

>>> While connection-oriented, ATM supports both
>>> asynchronous (packet) and reasonably-well-emulated isochronous
>>> connections, at a very wide range of speeds.

Ok, I bite.

What does "isochronous" mean?  I've seen this term in multiple engineering
articles re: ATM but I have yet to find out what it means.


thanks,

kevin

constant rate. (ie like a phone conversation at 8KB each and every second).

CCITT RED BOOK Vol X Fascicle X.1 Terms & Definitions

ISOCHRONOUS:

	"The essential characteristic of a time scale or a signal such that the
	intervals between consecutive significant instants either have the same
        duration or durations that are integral mulipules of the shortest 
        duration

	NOTE: In parctice, variations in the time intervals are constrained 
	within specified limits"

Aren't you glad you asked! If I remember right, this is how a T1 span keeps sync
thoughout the network with all the repeaters. The T1 span must keep "Bit Density"
which must be 3 ones in 24 bits, no more than 15 consecutive zero's. This is 
done to extract a clock from the data to keep the repeaters all in sync. It's been
awhile, I hope this is correct.

    Or to try another explanation:  "Isochronous" means "self-clocking
    synchronous".
    
    A "sync" interface such as V.35 has separate clock and data leads.  An
    "async" interface has a start bit and a predetermined clock rate.  An
    isochronous interface has neither.  Instead, the rate must be
    predetermined within fairly tight tolerances, and the receive clock
    adjusts within these tolerances to the actual received rate.  Thus the
    "1's density" requirement, since on T1, a 1 is a pulse and a 0 is no
    pulse.
    
    In the ATM world, isochronous service is emulated.  ATM Adaptation
    Layer Type 1 is one such protocol.  The network delivers the cells at a
    constant-over-time rate.  But ATM adds jitter and can lose cells, so
    the received flow is definitely not smooth!  So in AAL1, each cell has
    one octet of header which includes a 3-bit sequence number.  This
    enables dropouts to be detected and "filled in" (with 376 bits).  The
    receiving end uses buildout buffers to ensure no "cell starvation"; the
    output delay is thus at least as long as the maximum delay variance.
    
    Just for grins and chuckles, there's also "plesiochronous", but it's
    not an ATM term.  (It means "nearly synchronous", and refers to the
    T1/T1/T3 and related hierarchies, in which the payload consists of
    multiplexed isochronous payloads, each of which may be clocked
    separately.  I've also labeled "plesiochronous" cell transfer as a
    variant on ATM in which cells are loosely slotted into an allocation
    frame.)
       fred

    ...Caution, possibly inflammatory opinions follow...
    
    "reasonably well emulated isochronous" is an oxymoron.
    
    "isochronous" is a well-defined concept.  For networking it's not
    particularly interesting, since the major user is traditional telephone
    digitized voice, without any compression or silence suppression.
    
    Once you do any processing on what started out as a constant-rate
    stream (voice or video; for example compression) it becomes variable
    rate, and you need buffering for the reverse processing at the
    destination.  Given that processing, you no longer have any need for
    the "no jitter" service that isochronous transmission gives you. 
    Instead, you then need a transmission service that has bounded jitter;
    the bound can often be quite high.  (For example, with compressed
    video, the jitter bounds are at least equal to the frame time, i.e., 
    30 ms)  This is why FDDI-2 makes no sense.  (I guess it also explains
    why "well emulated isochronous" service is useable, though the only
    reason for using the word "isochronous" in there that I can see is to
    get past the preconceived notions of those who still believe that
    isochronous service has a place in networking.)
    
    	paul

    RE: -.1
    Well no.  "Reasonably-well idoschronous" makes lots of sense.  ATM will
    carry pure, unadulterated, uncompressed telephony (PCM, ADPCM), video
    (PictureTel, H.261, etc.), data (SNA, DDCMP, IPX, Airline code, etc.),
    inter-nodal-processor link (StrataCom, NET, Newbridge, Typmplex, etc.),
    and whatever else today _expects_ to see a "T1" or similar channel. 
    Indeed one of the initial applications for ATM WANs will be links
    between nodal processors.  And the ATM standards folks are working on a
    "bearer service description" for a "T1 bearer service", which is a
    constant bit rate stream that emulates isochronous 1.544 Mbps.  
    
    That's the whole point of ATM:  It can emulate non-packet as well as
    packet.  It's transparent to embedded systems and end users.  It can
    also do its "native" thing, which is a variable-bit-rate flow.
    
    The reason that ATM is not a perfect equivalent to isochronous is that
    true isochronous channels tend to have one and two bit errors, while
    ATM will have these as well as 376-to-384 bit clustered errors caused
    by cell dropouts.  Also ATM has more delay due to the need for buildout
    (jitter buffer).  But it's good enough for many applications.
    
    It is well beyond the subject of this topic to explain why telephony
    does not want to be treated as packet-mode variable-rate data.  Suffice
    to say that it's a given.
       fred

    
    Can anyone recommend a source of info on ATM basics?
    
    Thanks!
    
    -Ed
    

    There is a course offered in the Colorado Springs training center on
    ATM and Frame Relay. It's called something like "Broadband
    Technologies: Understanding ATM and Frame Relay". I went to it and it
    is a pretty good course. If you send mail to GENRAL::ETA_TRAINING (I
    think), you probably could get a course out line.