Subject: RE: The iSCSI Plugfest - update for Wednesday

From: "Julian Satran" <[email-masked]>
Date: Thu, 19 Jul 2001 19:30:40 +0300

No - only sending good status on Data-In PDU.  And again this did not
change from draft 00.  Julo

"Barry Reinhold" <[email-masked]> on 19-07-2001 15:23:47

Please respond to "Barry Reinhold" <[email-masked]>

To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
cc:
Subject:  RE: The iSCSI Plugfest - update for Wednesday

Julian,
     Am I to understand from this that iSCSI intends to support both (1)
sending
of status information in iSCSI data PDUs and also sending of data in iSCSI
response PDUS?

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Julian Satran
>Sent: Thursday, July 19, 2001 6:27 AM
>To: [email-masked]
>Subject: Re: The iSCSI Plugfest - update for Wednesday
>
>
>
>Status and Data where (and) are part of the standard.
>They are important to reduce the protocol overhead and performance of the
>software implementation
>is substantially reduced without it.
>
>It is clearly stated in several places (1.2, the Data-In PDU) etc. and has
>never changed (from version 0).
>
>As for the plugfest - congratulations - great work.
>
>Julo
>
>
>
>
>Please respond to "Barry Reinhold" <[email-masked]>
>
>To:   "ISCSI" <[email-masked]>
>cc:
>Subject:  The iSCSI Plugfest - update for Wednesday
>
>
>
>
>The plugfest process has settled down to the detailed process of isolating
>implementation bugs. A significant percentage of the implementors are now
>able to connect and perform I/O operations - though this is often achieved
>by first compiling with -D "company Name" switches to handle the different
>issues that have already been discovered.
>
>New Issues: A detailed posting of the issues to date will (or has) be done
>by Bob Russell. In brief  only one additional standards issues came to
>light
>that impacted interoperability in the days testing:
>
>1. The current wording of the standard appears to allow for the
>transmission
>of IO data in response frames. This is actually being done in a few
>implementations. Although this was perhaps a vision at the start of the
>iSCSI effort there is little support for this. Most implementors were not
>prepared to handle this.
>
>Progress:
>
>Test progressed to round 17 and it appears that it is highly likely that
>developers will get a chance to test against all other parties by the end
>of
>the week.
>
>Two vendors were able to establish a multi connection session, getting
>through the login process and the start of IO.
>
>Two other vendors established an iSCSI session with header digests,
>completing the security phase of the login process.
>
>Some generic problem areas that come up:
>
>0 Length data frames
>Target initiated text negotiation
>Response information in data PDUs.
>SCSI compatibility issues
>
>There was a UNH iSCSI consortium meeting at the end of the day
>
>1. Overview of UNH iSCSI consortium
>2. Discussion on dates/time for next plug fest
>3. Election of steering team
>
>People flowing out at 7:00 -- sign that things are pretty good.
>
>
>
>Barry Reinhold
>Principal Architect
>Trebia Networks
>[email-masked]
>603-868-5144/603-659-0885/978-929-0830 x138
>
>
>
>

---

From: "Robert D. Russell" <[email-masked]>
Date: Thu, 19 Jul 2001 13:59:22 -0400

Julian:

The warning in section 8.6 of draft 06-99 still does not solve the
problem and is in fact wrong.  It now reads:

  "However negotiating an amount of unsolicited data for writes and
   sending less than the negotiated amount when the total data amount to
   be sent by a command is larger than the negotiated amount may
   negatively impact performance as the targets will not be able to ask
   for the remainder of the data."

The problem is, even if the initiator DOES send the full negotiated
amount, the target does NOT know this in advance and therefore cannot
send out the R2T for the rest until getting the unsolicited data PDU
with the F bit set to 1.  In other words, even the very best
implementation of an initiator does NOT solve the problem -- the target
still does NOT know what is coming because the initiator can NOT tell him.
Performance is ALWAYS impacted, regardless of what the initiator does.

The simplest solution would be to REQUIRE the initiator to send
the negotiated amount (after all, if he doesn't want to send that much
every time then why did he negotiate that much?).  Then the target
will know, in advance, what is coming and send out the R2T for the
rest of the data WITHOUT WAITING!  This is where the performance gain
is to be found.

(In all of the above discussion I am assuming the Expected Transfer
Length is greater than the First Burst Size.  The acutal requirement
for sending unsolicited data is that the initiator be required to
send min(Expected Transfer Length, First Burst Size) as unsolicited
data if unsolicited data has been negotiated.)

Thanks,

Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774