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

From: "Elliott, Robert" <[email-masked]>
Date: Tue, 7 Aug 2001 12:47:44 -0500

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: Dave Sheehy <[email-masked]>
Date: Tue, 07 Aug 2001 12:38:55 PDT

> Command PDU was discussed as a possible simplification.

What are you trying to simplify? Is it the case where both immediate and
unsolicited PDUs are allowed in the same command? In that case I would 
recommend making the two mutually exclusive as the preferred simplification. 
Separate unsolicited data PDUs are far more onerous than immediate data (for 
the target). If you really want to simplify things then eliminate unsolicited
data PDUs and keep immediate data!

Dave Sheehy

---

From: Stephen Bailey <[email-masked]>
Date: Wed, 08 Aug 2001 03:59:47 -0400

> What are you trying to simplify?

Trying to simplify the receiver's data path by eliminating one of the
two possible ways in which unsolicited data could arrive.

Eliminating the unsolicited PDUs is the WRONG choice because if you
only have immediate data (data within the command PDU), you can must
either a) make the allowable size of the command PDU relatively
unbounded (to accomodate arbitrarily sized immediate data), which will
break either framing mode b) severely limit the amount of unsolicited
that can be sent, which makes unsolicited data useless.

So, unsolicited data should be carried in a similar, if not identical
way as regular data, tiled into multiple PDUs.

Steph

---

From: Stephen Bailey <[email-masked]>
Date: Wed, 08 Aug 2001 04:27:55 -0400

Robert,

> field from the Data-in PDU.

It wouldn't hurt my feelings if this happened.

However, there is a difference between these two simplifications.  The
good status optimization prevents the transmission of a PDU which is
~100% overhead.  Unsolicited data, by its nature, is to carry data, so
adding additional headers just leads you to the current header/data
overhead level.

That said, the ratio of data to status is going to be high no matter
what, so the overhead contribution of not optimizing good status is
probably neglible.  Furthermore, for hardware implementations, the
good status optimization is just an irritant.  Presumably that is why
FCP never bothered with it.

The traditional-sockets software-only implementations will have the
same argument against eliminating this optimization that they do
against removing Immediate data.  These optimizations permit them to
do half as many reads (2 instead of 4) in the optimized cases.
Personally, I would prefer not to give weight to unoptimized TCP
software solutions over hardware and optimized TCP software solutions.
Although most existing implementations are unoptimized TCP versions,
they should be considered prototypes (after all, version=0 until RFC
or death :^)

At an absolute minimum, I think we could remove the status field, and
assume that s=1 implies status=good.  There are no other SCSI statuses
that are worth optimizing.

Steph

---

From: Dave Sheehy <[email-masked]>
Date: Tue, 14 Aug 2001 21:06:57 PDT

Sorry for the delayed response, I was away from the office for most of last
week.

> two possible ways in which unsolicited data could arrive.

Eliminating immediate data doesn't accomplish that to any significant degree
hence my question.

> that can be sent, which makes unsolicited data useless.

I did not mean to imply that it was the RIGHT or the WRONG choice. John
Hufferd's post echoes my own thoughts on the matter quite well. Handling
unsolicited data PDUs at the target is a lot of work because they have
no target context and they arrive separately from the command. The handling
of immediate data is trivial in comparison.

> way as regular data, tiled into multiple PDUs.

Then forget simplification because you aren't going to get it to any
significant degree.

Dave