Subject: RE: [Tsvwg] Another view of the SCTP error check problem

From: Robert Snively <[email-masked]>
Date: Mon, 2 Jul 2001 08:35:16 -0700

David,

With a well-designed modern (i.e. FCP-2) implementation, FC
and FCIP may cheerfully discard frames whenever they need to.
The only commands effected are those for which frames are
discarded.  Those commands are recovered in a timely manner with
a minimum of fuss and bother using the FCP-2 retransmission
capability.  This has been proven with jammer testing, so this
is not a theoretical statement.

In general, SCSI retry (except for tape drives) is trivial 
even if FCP-2 retry is not implemented.  The command is simply
executed again.  This has worked for parallel SCSI, parallel
packetized SCSI, FC FCP SCSI, and all other forms of SCSI.

I do not believe there is any justification for the statement
"SCSI level recovery is horrendously expensive by comparison 
to a TCP or SCTP retransmit".  The recoveries for SCSI errors are more
compact and less disruptive than TCP or SCTP retransmissions
and the latencies are comparable or lower.

Bob Snively                        e-mail:    [email-masked]
Brocade Communications Systems     phone:  408 487 8135
1745 Technology Drive
San Jose, CA 95110

>  -----Original Message-----
>  From: [email-masked] [mailto:[email-masked]]
>  Sent: Friday, June 29, 2001 4:41 PM
>  > While it is clear that the iSCSI recovery stack would be
>  > exercised less often with an SCTP plus CRC transport than 
>  with a TCP
>  > plus 16-bit Check Sum transport, the number of errors will
>  > be the same.  None of these transport mechanisms support ECC and
>  > all use similar retransmission mechanisms.
>  > I am  assuming that the transport layer recovery
>  > algorithms are about as expensive as the application
>  > layer recovery, so the impact on performance is approximately
>  > the same in both cases.
>  
>  That's a bad assumption when the application is SCSI.  SCSI level
>  recovery is horrendously expensive by comparison to a TCP
>  or SCTP retransmit.  FCIP will discard the corrupt frame and
>  leaves SCSI to pick up the pieces (assuming that the
>  application is SCSI over FCP over FCIP) - this will almost
>  always be much slower than a TCP or SCTP retransmit.

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: [email-masked]
Date: Mon, 2 Jul 2001 14:15:34 -0400

> discarded.  

Provided that FCP-2 retry is implemented.  There's a lot
of gear out there that doesn't do it.

> executed again.

Trivial, maybe, but definitely not quick.  The dropped command
has to be timed out first (don't assume Class 2 service) and
that takes much longer than a SACK or dup-ack and retransmit
in the transport. The transport retransmit mechanisms complete
in something like an RTT or two.  Setting a SCSI command
completion timeout anywhere close to that level will generate a
*lot* of false alarms, hence such timeouts tend to be considerably
larger.

> to a TCP or SCTP retransmit".

It's a fact of life in most general purpose operating systems, for the
above reasons and because SCSI error code paths are not optimized
(heck, getting them to work is hard enough).

--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------