RE: iSCSI: Use of the A bit

["John Hufferd" <hufferd@us.ibm.com>]

A lot of this thinking on this thread reflects the "send and Ack response"
type design.  The work last year rejected that thinking and we overtly
designed against that approach with iSCSI.  This is because, at distance,
this can be a major performance issue.  (round trip delay)

Anyway, that is why people did not want to get into the positive Ack, mode,
since 99.9999999% of the time, TCP/IP will deliver everything just fine.
Then if you look at the probability that TCP/IP thinks it did its job, but
did not detect the problem and the CRC-32c detects it, the probability is
even smaller.

To base a design on requirements for Positive Ack, when the probability of
failure is so remote, is in many people's opinions the wrong way to build
product.  And since our products need to inter-operate, and inter-operate
at distance, what one does poorly effects everyone's product.

When you put a Positive Ack into place, you encourage the type of thinking
we have been seeing on this thread, and that hurts others!  That is the
reason that folks did not like the idea of a positive Ack.

We rolled over with this small "A" bit approach because of issues with Tape
Drives since even if Rare, the resultant problem with tape can be severe,
but we put the restrictions on it that you currently see.

To make things work at distance, yes you need some additional buffering,
somewhere.

I heard the arguments that I cant get my ULP to give me enough buffers to
work with, I do not buy that argument, and I think folks are reaching for
straws to try to prove their point.  I do not doubt there will be some
really dumb devices that do not have enough buffers to do a really good
job, but that was the reason that ErrorRecoveryLevel=0 is there.  It will
happen very very rarely, that the CRC-32c will find a problem that TCP/IP
does not find.  So if you do not have the buffers to handle this "once in a
bluemoon" occurrence, then restart the session when this rare occurrence
happens.  But there is no need to impact the other implementations with a
design that will show up poorly at distance.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com