Subject: iSCSI 05.txt is out

From: [email-masked]
Date: Fri, 2 Mar 2001 14:00:49 +0200

Dear colleagues,

I've just submitted to the Internet-Drafts repository and to our list
archive (at CMU) a new
version of the draft.

You can find the new document at:

http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iSCSI-05.txt

I intended to correct some last minute annoying errors and to add one item
for which I did not have
an acceptable answer at 04 time - a neat recovery for lost R2Ts (StatSN
implies keeping things around and that is not worth for R2Ts).  I've added
them now to the DataSN sequencing.

The text readability score was pretty low (even lower then the usual for a
technical text - I don't know about standards) so that I handed the text to
technical writer.  The text is better (I am told - I can't judge) but I
could not use the Acrobat to put out a version with changes since they
where so many editorial changes.

No major technical changes.

- Fixes
- Security negotiation can adopt one method for the two ends not two
separate methods.
- R2T as I mentioned

Julo

Julian Satran - IBM Research Laboratory at Haifa

---

From: Sandeep Joshi <[email-masked]>
Date: Fri, 02 Mar 2001 14:15:53 -0500

Hi Julian,

Draft looks good.   Here are a few issues i noticed.
Some of these issues may have been valid with 04 too.

-Sandeep 

Sec 2.7: Scsi Data for READ
---------------------------
This is a read PDU but the fields for (O|U) do not match the
corresponding positions for Read status indicators in the
Scsi Response PDU.

In the Scsi Response PDU, it is lowercase "o" and "u" which
indicate read overflow/underflow.  They are present in a
different bit positions.

Notice that the residual count position is consistent.
So how about matching up the over/underflow bits to same
positions with same lowercase syntax ?  This may also 
change the "S" bit position.

R2TDataSN
----------
Sec 6.7.1 has some new content on how to handle lost R2Ts using
SACKs.  But I noticed that the SACK request (Sec 2.16) has not
changed to indicate whether the DataSN is a R2T DataSN or just
a Read PDU DataSN (D bit)
So do we demux on the read/write operation type?
And how does this affect PDU loss in bidirectional commands ?

Sec 2.14.1
----------
CID: This field is valid only if the reason code is not "close
connection" -- you mean "close session" right ?  

To further reinforce this, can we also add "CID or reserved(0)" 
to the PDU frame above - just as we do in other cases.

Sec 2.18 Async PDU
--------------------
Could you elaborate on the scenarios proposed under which
a target might request a logout (event code=2)?  I recall this
code was added recently (in 03 or 04) but cant recall the 
exact semantics.

For example, can this code be used if some connection does not
respond to pings ?  From Sec 2.14, I see that this will result
in a Logout Command with reason_code=2 (target-requested logout).
There is also some discussion in Sec 6.7.1.2 on this.

This facility gives rise to race conditions on duplex & buffered
channels - plus the Async PDU intends to preserve the statSN
ordering.  [Async is a misnomer :-)]

Say both initiator & target decide to close a non-responding TCP
connection_1.  The initiator sends a Login (for conn recovery)
on some other connection_2.  At the same "time", the target
sends an Async PDU for c_1 on connection_3.

By the time Async PDU is delivered, the initiator may well have
recovered the connection so its going to logout a connection
which is chugging along hunky-dory.

In the absence of any synchronized timestamps, it is not possible
to know if one is responding to an event which has already
been handled.

Sec 2.10 :  Version number
----------------------------
The min & max versions are just plain numbers.  Any plans to
support major+minor version numbers ?

---

From: "Venkat Rangan" <[email-masked]>
Date: Mon, 5 Mar 2001 14:40:18 -0800

Julian,

Here are a few technical and editorial comments on the latest draft.

Technical:

Page 12:

- CmdSN - the current Command Sequence Number advanced by 1 on each command
shipped

Add: skipping zero, which is reserved for immediate delivery.

Page 12:
Remove the sentence:
"A large difference between StatSN and ExpStatSN may indicate a failed
connection."

This may have made sense when StatSN and ExpStatSN are session-wide. Now
that it is per-connection, this may not be valid. As was pointed out in the
"Holes in StatSN" thread, ExpStatSN may be "stuck" at a low value when a
single PDU encountered a Digest Error, followed by several well-formed PDUs.

Page 24 - Section 2.1
Add: The length of the PDU SHALL include any padding bytes added.

This raises a question as to whether it may be useful to include a two-bit
"Fill Bytes" field in the header (BHS and AHS) which indicates the number of
bytes that were added. Without this, it may be harder for the receiver to
know how many bytes are part of the data. Fibre Channel has the Fill Byte
specifier in its F_CTL part of the header.

Page 25:
This may be covered in another thread.

What does the first Next-Qualifier (at byte 0) describe? Is it the BHS or
the header following the BHS? If a PDU has a single BHS and a single AHS, is
the sequence WN-BHS-AHS or is it WN-BHS-WN-AHS?

Page 25 and 26:
The text next to the bit description and the headers in the text for
sections 2.2.2.1 to 2.2.2.3 appear to be inconsistent.  An example is
"read-data transfer" vs. "Read Data" "Long Data" vs. "Long Data Transfer"

Also, 2.2.2.3 appears to have text about Long Data Header that probably
belongs in section 2.2.2.2 (or I am confused about how WN is supposed to
work.)

Page 43
Section 2.7
The PDU diagrams should not show "Digests if any..." etc. It should be
covered by NQ and corresponding AHS.

Page 44
Section 2.7.2
The requirement of having to specify a valid LUN as part of WRITE Data (and
NOP-Out) may pose unnecessary overhead for Target processing. The fact that
Targets are now REQUIRED to reject errant initiators who may place a LUN
inconsistent with the one sent in the CommandPdu means that targets should
save the LUN against each context entry for the task. This was discussed
earlier, and I think we said that unless the folks who originally wanted it
spoke up, we will remove it. Note that Fibre Channel does not have this
feature, and its original purpose can be accomplished by using Target
Transfer Tag.

If we still want it, targets should be given the option of negotiating this
so that it can operate in a mode where a LUN specified as part of WRITE data
will be ignored (as opposed to rejected).

Section 2.17
The following text:
"Within a connection, outstanding R2Ts MUST be fulfilled by the initiator in
the order in which they were received."

implies that R2Ts for the same WRITE command may be sent by the target on
multiple connections? Since this is not possible, all R2Ts for a command are
always on a single connection, so I am not sure how the above sentence
should be interpreted.

Page 75:
Add: "i.e., from Most Preferred to Least Preferred" to "reverse order of
preference."

------------
Editorial - typos and such

1. Page 11:

Not covered are he means

Change "he" to "the"

2. Page 20:

Change "later" to "latter" in "the later can be used in subsequent
commands."

3. Page 23:

Change "isa"  to "is a"

Page 42:
Section 2.6.1
Change to: Initiator Task Tag of the task that was not found; used in
conjuction with Response value 1. It MUST be set to zero in other cases.

Page 51:
Change "CID does not change and this command is performs first" to

"CID does not change and this command first performs"

Page 55:
There is nothing that indicates the status codes in the table are sent as
part of Status-Detail.

Page 66:
Change "iSSCSI Data-out PDU" to "iSCSI Data (WRITE) PDU"

The Data-out PDU is a new concept not introduced anywhere.

Page 75:
The term "Security Context Complete" is referred to prior to its definition.

Page 81:
Change "later" to "latter"

------------

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com

---

From: Matt Wakeley <[email-masked]>
Date: Sun, 11 Mar 2001 01:20:58 -0800

Matt Wakeley wrote:
> Venkat Rangan wrote:
> So, if the connection is not frames (markers, etc), it must still be
                                    ^d
> terminated in order to recover.  And if it is framed, there will not be a
> "stuck" low value...
> 
> > Page 24 - Section 2.1
> Agreed.  There is very little padding and how it is conveyed.
                                       ^ info

> (since Julian did not reply), the next qualifier always describes the header
> after the following header (I know, it can be confusing - that's why all this
> discussion and David Black's message on examples, more info was posted).
> 
> >
> > Page 25 and 26:
> I completely agree.
> > multiple connections?
> No. See 1.2.5: "the target MUST return R2T, if any, and the status over
> the same TCP connection that was used to deliver the SCSI command."
> 
> What this means is that if the initiator receives R2T for command 1, followed
> by R2T for command 2, it must send the data for command 1 before command 2.  I
> don't know why this is a requirement, it seems like an unnecessary
> restriction.
> 
> > Since this is not possible, all R2Ts for a command are
> -Matt Wakeley
> Agilent Technologies

---

From: Matt Wakeley <[email-masked]>
Date: Sun, 11 Mar 2001 01:11:17 -0800

I completely agree.

-Matt Wakeley
Agilent Technologies