Subject: Re: iSCSI: draft 7: remove S bit and Status field from the Data-in PD U?

From: "Julian Satran" <[email-masked]>
Date: Wed, 8 Aug 2001 14:35:43 +0300

Elliott,

That might be so for hardware inplementations. For software it means an
additional read and it may negatively affect performance for short
operations (like data base transactions).

The same is true for immediate writes. The simplification that was agreed
that we bring back to the list
was to eliminate 2 types of unsolicited data and return to only one king
being allowed in a command.

So here it is.  I personally think that the simplification is so minor that
it is not worth going through talking about it.

Comments?

Julo

"Elliott, Robert" <[email-masked]>@ece.cmu.edu on 07-08-2001
20:47:44

Please respond to "Elliott, Robert" <[email-masked]>

Sent by:  [email-masked]

To:   "[email-masked]'" <[email-masked]>
cc:
Subject:  iSCSI: draft 7: remove S bit and Status field from the Data-in PD
      U?

At the IETF IPS WG meeting, removing the immediate data from the
Command PDU was discussed as a possible simplification.

A similar simplification would be to remove the S bit and Status
field from the Data-in PDU.  These let Status be returned in the
Data-in PDU rather than in a separate Response PDU.  The target
can send the last Data-in PDU and the Response PDU back-to-back;
there's not much wire overhead sending 48 more bytes.  The
initiator always has to handle separate Response PDUs, so this
eliminates a special case and collects all status and residual
handling in one place.

--
[email-masked]
Compaq Computer Server Storage

---

From: "John Hufferd" <[email-masked]>
Date: Fri, 10 Aug 2001 07:35:39 -0700

Folks,
I might have this all wrong, but it seems to me that we are jumping on the
simplification horse from all directions, whether or not it is right, just
to say we are trying to simplify.  I am afraid that some of this may be at
the expense of "at Distance" installations.

First, immediate and unsolicited separate Data PDUs are very valuable for
situations where the Target is at distance from the Initiator.  (A good
example is writing to tape.  Most tape are only written and hardly ever
read.  Further, many folks would like to have tapes somewhere else -- at a
distance.)  The ability not to have to have R2T exchanges over distance is
an important feature.  Let us not quickly throw that out.

Second, thoughts of removing the immediate data seem not to be
simplification, since all the information to tie the data to the command is
right there with the command.  That has got to be easier then matching up
separate PDUs of data with the approprate commands.

So I am concerned that one of the important strengths of iSCSI -- that
being the ability to efficiently operate at distances where Fibre Channel
would fear to tread -- is being too quickly put aside.

Therefore, if you do not eliminate immediate Data (since that is the most
efficient, especially for the smaller data sizes), you are faced with
removing unsolicited Data Packets and only permitting R2T -- which has a
round trip handshake that is needed to get the data.  From a latency
standpoint this does not seem good.

I can imagine some vendor making a claim that their Storage Unit is the
Industry's best "at Distance" storage controller, but it has more memory
and might be a bit more expensive then the typical R2T based Storage Units
(since they accept unsolicited Data PDUs), but I think that is good.  We
need vendors to offer those types of solutions.

If you do not want unsolicited or immediate Data PDUs, don't accept them at
Login.  But, they were put into the protocol for a reason, and I hope we
continue to have the features that keep iSCSI a distance compatible
protocol.

.
.
.
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
Internet address: [email-masked]