Subject: Re: iSCSI 05.txt is out

From: [email-masked]
Date: Sat, 3 Mar 2001 19:32:13 +0200

Sandeep,

Thanks for the carefull reading. Responses in text.

Julo

Sandeep Joshi <[email-masked]> on 02/03/2001 21:15:53

Please respond to Sandeep Joshi <[email-masked]>

To:   [email-masked]
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 -:)

---

From: "Somesh Gupta" <[email-masked]>
Date: Mon, 5 Mar 2001 10:40:06 -0800

> R2TDataSN

Julian,

Regarding the R2TDataSN, I have a comments and a
question.

I think that when a PDU header fails a CRC/checksum check etc,
it is a problem to depend on any information in the header (including
length fields), thereby making any further processing on
the connection unreliable.

What scenarios do you envision where the R2TDataSN is useful.
IN Orlando I think there was clear consensus that application
do not try to transfer very large amounts of data using a
single command.

Thanks,
Somesh

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com