Path: utzoo!attcan!uunet!samsung!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!att!cbnewsh!tds
From: tds@cbnewsh.ATT.COM (antonio.desimone)
Newsgroups: comp.protocols.tcp-ip
Subject: Error Control and ATM (was: TCP Fletcher Checksum Option)
Message-ID: <6528@cbnewsh.ATT.COM>
Date: 12 Dec 89 02:22:16 GMT
References: <6796@shlump.nac.dec.com>
Organization: AT&T Bell Laboratories
Lines: 63

From article <6796@shlump.nac.dec.com>, by goldstein@delni.enet.dec.com:
> In article <[A.ISI.EDU].9-Dec-89.11:15:42.CERF>, CERF@A.ISI.EDU writes...
>>It is by no means clear that reordering at the cell level will be
>>detected by the ATMs or by links level algorithms sending the
>>packets assembled from cells to the hosts since the link level
>>checksums would be recomputed AFTER reassembly, most likely.

I'm not sure if I understand this point.  A host worried about data
integrety would compute a packet checksum before segmentation into
cells and after reassembly into a packet.  Shouldn't the checksum
detect reordering of cells within the packet?
> 
> Indeed, the current proposals for B-ISDN use ATM cell transfer and
> state, in its service description, that it _will_ preserve order.  Now
> doesn't that make you confident that the implementations will never,
> ever, ever, ever mis-order a cell?  The ATM cells do not contain any
> sort of sequence numbers. 

It's seemed to me that people expect both too little and too much from
ATM.  Here's an example of expecting too much.  One may conceive of a
"malfunctioning" time-slot-interchange switch that reorders bytes in a
T1 frame, even though the "service description" says it won't.  Should
we put sequence numbers on individual bytes?  Similarly sequence
numbers for individual cells are overkill since the architecture of ATM
switches preserves the order of cells.

> BTW I have proposed (and gotten rebuffed by the Powers That Be at 
> T1S1.5, namely the AT&T & Bellcore leadership) an end-to-end datalink
> protocol that has cell sequence numbers and bulk cell ack's, loosely
> based on NETBLT, with a 2^14 modulus.  You can always run it or 

A modulus of 2^14 with 48-byte cells allows roughly 6 Mbits outstanding.
A cross-country circuit at 150 Mbits/second can have 9 Mbits in flight
for a 60 msec propagation delay.  Your proposal reduces throughput at
the speeds being contemplated for the next few years, to say nothing of
higher speeds in the future.  (BTW: I had nothing to do with AT&T's
positions in the standards bodies.)

> something else you prefer end to end across the ATM and ignore their
> recommendations for adaptation, if you're not talking to a
> network-provided service (i.e., the "B-ISDN CLNS", which is an L3
> datagramme service running over the adaptation layer).  My impetus,

Doesn't B-ISDN CLNS include a checksum or CRC at the frame level?

> though, is to handle cell loss without having to retransmit the whole
> frame.  (Can you spell 'congestion collapse'?)  Misordering detection 
> comes along with that.

Think for a minute about what losses will look like in a congested ATM
network.  When buffers overflow losses will occur in clusters, just
because of the long time congested queues take to recover.  Also,
errors on transmission lines typically occur in bursts: isolated random
bit errors that we all like to use for modelling are in fact a poor
representation of reality.  All this says that the loss of isolated
cells is rare, and that cell retransmission promises little gain at a
great cost in complexity.  With an understanding of loss patterns frame
retransmission seems quite reasonable.
-- 
Tony DeSimone
AT&T Bell Laboratories
Holmdel, NJ 07733
att!tds386e!tds