Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!samsung!aplcen!haven!decuac!shlump.nac.dec.com!delni.enet.dec.com
From: goldstein@delni.enet.dec.com (Fred R. Goldstein)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Error Control and ATM (was: TCP Fletcher Checksum Option)
Message-ID: <6830@shlump.nac.dec.com>
Date: 12 Dec 89 20:15:25 GMT
Sender: newsdaemon@shlump.nac.dec.com
Organization: Digital Equipment Corporation, Littleton MA USA
Lines: 124

In article <6528@cbnewsh.ATT.COM>, tds@cbnewsh.ATT.COM (antonio.desimone) writes...
>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?

If you're referring to the use of an end-to-end checksum at Transport
or higher (i.e., a TCP checksum that could detect misordered cells),
then that would do it.  The AT&T-Bellcore AAL purports to detect
errors, but does not detect misordering.  In a pure OSI environment,
where there's no checksum above datalink, it wouldn't be caught.

>> 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.

You're being silly.  We know from practice that S-TDM switches do not
reorder bytes.  And if they did, your basic CRC would detect it.  (SLIP 
users deserve what they get.)  The current TCP checksum would detect 
frogged bytes, but wouldn't detect frogged 16-bit words.  We do not know
that all manufacturers of ATM switches will build switches that are
unable to reorder cells.  There are no commercial B-ISDNs yet, so it's
purely an extrapolation that the service description will be met.  This
thread began when someone pointed out that the existing TCP checksum may
be inadequate to detect misordered cells.  You simply assert that there
won't be.  The reader is left to trust AT&T or to cover his hide. 

 >> 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.)

A window allowing 6 Mbits outstanding is adequate for the typical
FDDI bridge application.  BLINKBLT's (my proposal's) 50-100 Mbps typical 
maximum rate seems adequate for a number of applications, and I don't
claim it's a panacaea.

>> 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?

NO!  It did, before YOUR COMPANY, Tony, made a big stink and holler
about how hard it would be to compute 32-bit checksums.  They insisted
that it be taken out.  Now the only CRCs are the 10-bitters in each
cell.  Compare Draft 5 of 802.6 with the current Draft 9, since this
changed in lockstep!

If you don't think AT&T Did The Right Thing, then call Harvey Rubin
(hr@edsel) and tell him.  Or do you value your job?  Recall that AT&T
delegates at ANSI meetings are company reps, while DEC delegates are
sponsored contributors.  (I forget the exact terms.)  I'm allowed to 
speak my mind at T1S1.

Incidentally, the main impetus for the change seems to be the 
"data pipelining" service, which is there (solely, I think) to allow
Datakit VCS (tm, AT&T) cells to be stuffed into ATM cells without
waiting to fill the 48-octet ATM cells.  I'm sure the Internet
community is concerned about preserving their Datakits beyond 1999!

>> 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.  

Yes, that's likely.  But the bursts occur as multiple virtual channels
are "funneled" into one output queue which fills.  A moderate-speed v ch
(say, under T1 rate) will lose maybe one or two cells during the burst
event, but many v chs. will have one or two cells lost.  It all depends
upon the traffic mix, and on whether everyone's traffic is carried
as close-together cell bursts (packet trains?) or smoothed flows.  The
former cause the effect you mention; the latter reduces funneling loss.

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.

Like I say, we don't know traffic patterns, so we can't prove loss 
patterns.  Frame retransmission makes sense in some circumstances.
Cell retransmission makes sense in some.  Since BLINKBLT uses exactly 
the same number of bits/data-cell (32) as AAL-VBR, and has relatively
similar protocol overhead, there's no higher transmission cost for it.
Just a different TE implementation.  Buffer lots of little cells (a 
round-trip's worth of bits) or buffer a smaller number of frames (a 
round-trip's worth of bits).

Either form of retransmission can be done with cell resequence
detection at some layer.  Those who choose to use the proposed BISDN
protocols may wish to develop transport or other checksums that detect
it, in case the network isn't perfect.
     fred