Re: iSCSI 05.txt is out

[julian_satran@il.ibm.com]

Sandeep,

Thanks for the carefull reading. Responses in text.

Julo



Sandeep Joshi <sandeepj@research.bell-labs.com> on 02/03/2001 21:15:53

Please respond to Sandeep Joshi <sandeepj@research.bell-labs.com>

To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI  05.txt is out





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.
+++ in response we had to take care of the BiDirectional commands so there
are two
sets. In read data - that is only for pure Reads (not for write-then-read
++++
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 ?
+++ SACK is ascking for data (DataSN) the target knows

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.
+++ you are correct
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.
+++ one cause could be maintenance
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.
+++ Login can be sent only when establishing (or restarting) a connection
but
---  i.e. TCP-Open followed by login -
Obviously there can be races but the initiator and target can get out of
them
quickly  +++
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.
+++ I & T have no synchronized clocks - and I did not see a compeling
reason to add one
Sec 2.10 :  Version number
----------------------------
The min & max versions are just plain numbers.  Any plans to
support major+minor version numbers ?

+++ they where in then we decided that we have enough artifacts already -:)