RE: iSCSI: Use of the A bit

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

Yes, that is what is going on.

Last year positive Acks were Overtly Voted Out by the iSCSI group (we had a
consensus call).  It was felt that since TCP/IP already did the error
detection and recovery -- the additional checking of CRC-32c would seldom
find an error which was not caught by TCP/IP.  Therefore, they did not want
to add stuff to the protocol which would inspire or require folks to
perform Send and Ack types of flow in order to guarantee safe arrival.
Instead, they wanted designs to assume that almost always the data arrived
correctly, and just had a back door recovery whenever the rare situation
occurred that our Digests found an error.  In that way:
* things did not hang around and wait, for Acks,
* there was a reduction in line protocol over-head,
* and at-distance interactions would not have to slow down.

This was a clear consensus, no positive Acks!!!

Well finally the case was made that Tapes needed special handling.  That
is, they needed this type of support, because many of the implementations
simply could not perform a reasonable recovery without adding lots more
buffers then they ever needed before.  Tape buffers are not, as a rule,
pooled memory, they are devoted to specific LUs (Tape Drives).  So any
increase to these memory requirements was simply multiplied by the number
of R/W units in the Library.  So because of this, we added back in, over
much contention, the "A" bit as it is today.

It did not need the Ack on the last I/O, since the tape buffer would not be
reused by anyone else anyway until the next command arrived, at which point
the success of the last operation is determined, etc.  This was not a
problem and the consensus was that it was tolerable in the case of tapes.

Now we have, what I think are contrived situations, in which people are
stating that there is no communication between the SCSI Buffer pool and the
iSCSI implementation so we have to act like a tape.  This is, in my opinion
not a correct assumption,  Buffer management was appropriately adjusted, in
most cases,  between SCSI and FC when FC brought the concepts of Credits
into the picture.   And there needs to be corresponding flexibility in the
buffering when you appropriately work with iSCSI.  The concepts of
immediate data, and unsolicited data, make that need clear.  Further the
use of the iSCSI Command Window management, is different then credits.
This means that to make the best use of iSCSI especially at-distance, where
we can clearly stand out from the other protocols,  we should push back on
this idea of Send and Ack.  We should leave the current Positive SNACK to
the realm of Tape.  However, if it is used for disk, consider it additional
information, that can occur at very infrequent intervals (MaxBurstSize),
which might help buffer management, but is not needed!!!

This thread has tried to come up with designs in which the use of the 'A'
bit is required, for their implementation to work.  I think that is just
wrong design, and will cause all of the other implementations to look bad
when placed in the same network at-distance.

There is not a way for the customer to know that the product they are
buying will not work well at-distance, since that is, after all, one of
iSCSI's claim to fame.  Therefore, it will make all the Initiators, which
interact with such devices, look bad and give all of iSCSI a bad name.

I think we should respect the previous consensus call, and Not add back
into the protocol, positive Acks that are not needed for Tape.

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


Eddy Quicksall <Eddy_Quicksall@ivivity.com> on 03/16/2002 06:25:56 AM

To:    John Hufferd/San Jose/IBM@IBMUS, Martins Krikis <mkrikis@yahoo.com>
cc:    ips@ece.cmu.edu
Subject:    RE: iSCSI: Use of the A bit



Nobody in this thread has proposed a "send and ack" design.

Eddy

-----Original Message-----
From: John Hufferd [mailto:hufferd@us.ibm.com]
Sent: Saturday, March 16, 2002 3:58 AM
To: Martins Krikis
Cc: ips@ece.cmu.edu
Subject: RE: iSCSI: Use of the A bit



To any specific user, performance is judged by their own performance not
the performance of the link or the storage controller over all.

When you read an at-distance disk, and its performance sucks, because of a
Send and Ack design, you will not have good things to say about iSCSI.  And
it is not easy to tell what the problem is.  And it is not really possible
for a customer to determine before purchase that he is buying a poorly
designed target HBA or chip.  In fact they may have tested it out in a
local environment and found it OK, and then when contacted by a remote
initiator, that remote unit is very disappointed.  This gives everyone a
bad name.  Even if the Links are well used and the overall efficiency of
the storage controller good, if the individual performance is bad, iSCSI
will be seen to be bad.

Send and Ack designs are bad designs, and in almost all cases are not
needed.  And it gives iSCSI a bad name in the environment we have been
claiming as our own, the at-distance environment.

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


Martins Krikis <mkrikis@yahoo.com>@ece.cmu.edu on 03/15/2002 01:45:14 PM

Sent by:    owner-ips@ece.cmu.edu


To:    ips@ece.cmu.edu
cc:
Subject:    RE: iSCSI: Use of the A bit



Just a quick note. Some people have implied that the
use of A-bit necessarily means poor performance.

I would like to disagree. If the target is just
sitting there waiting for acknowledgment to come
back before sending the next Data-In sequence, then
yes, that's poor performance. But I can imagine
targets that keep sending data while waiting for
the outstanding acknowledgments. Yes, it requires
more buffer space, but the acknowledgments are
actually helpful in managing that bigger buffer space.
It's a very similar situation to multiple outstanding
R2T-s. Hopefully everybody agrees that there may be
benefits to those.

Or am I just missing something again?

  Martins Krikis, Intel Corp.

Disclaimer: These opinions are mine and may not
            reflect those of my employer.




__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/