Subject: iSCSI: draft04 questions

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 01 Mar 2001 11:02:14 PST

Julian,

Thanks for incorporating a lot of the earlier reflector feedback 
into the latest draft.

Some questions:

1. Section 1.2.5 states :
	"Unsolicited data MUST be sent on every connection in the 
	same order in which commands were sent. If the amount of data 
	exceeds the amount allowed for unsolicited write data, the 
	specific connection MUST be stalled - i.e., no more unsolicited 
	data will be sent on this connection until the specific command 
	has finished sending all its data and has received a response."

Sorry if there was a discussion on this already.  Why not the iSCSI 
response of "Unsolicited data rejected" usable for this case?  Initiator
appears to be behaving erratically, and I don't see how it is expected
to adhere to the stipulation that it shall not send anymore unsolicited
data till this command is completed.

2. I didn't find a way for an iSCSI target to say that it does not support 
any unsolicited data at all.  SPC-2 specifies that a zero FirstBurstSize
means unlimited.

3. Section 2.14 states: 
	"If an initiator intends to start recovery for a failing connection it
   	MUST use the either the Logout command to "clean-up" the target end
   	of a failing connection and enable recovery to start, or use the
   	restart option of the Login command to the same effect."
This seems to be contradicting section 2.10.1, where a prior logout of the
CID is stated as a requirement for using the restart bit of the Login PDU
(which I agree with).

4. Somehow, "Asynchronous Message" seems at odds with the rest of the
usage in the draft in regards to PDUs (since a message is introduced as
PDU in section 1.2).  Should we may be just call it an AEN PDU?  Section
2.14.3 calls this so.  (I realize that it may not always result in a 
SCSI-level AER.)

5. In the same section 2.18, I dont' quite see the operational difference
for an initiator, if any, between iSCSI event codes 2 & 3.  Could you please
comment?  

Also, isn't the time in seconds the maximum time than the minimum
time as currently stated? 

6. In section 2.20.1, reject reason code 5 is stated as a "command 
restart reject".  Seems like the usage of "restart" in the draft elsewhere
is for the connection/session login, and "retry" is for commands -
except this one.  Comment if I am reading too much into the usage.

7. Section 6.2 on digest errors states:
	"If the error is a Data-Digest-Error in a Data-PDU, the target 
	MUST either request retransmission with a R2T or answer with 
	a Reject iSCSI PDU and abort the task."
Were you meaning the target's internal termination of the task? That
could cause problems on a subsequent Data PDU reception from the 
initiator since there may be no state for the task in the target.  
Suggest dropping "and abort the task".

8. Same section states the following:  
	"When an initiator receives an iSCSI data PDU with a Data-Digest
   	error, it must discard the PDU and it MUST either request the missing
   	data PDUs through SACK or terminate the command with an error."
If you meant reporting a service failure to SCSI within the initiator, 
seems like that could cause trouble to initiator iSCSI layer since it 
is likely to receive the data/status PDUs for the command shortly thereafter.
Suggest dropping "or terminate the command with an error", or replace
with "or abort the task".

9. End of section 6.7.1 states:
	"An iSCSI target MAY reject a data-SACK and terminate the command with
   	an iSCSI error response of SACK rejected."

The "SACK rejected" iSCSI response code needs to be added in section 2.4.2.

Thanks.
--
Mallikarjun 

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
[email-masked]

---

From: [email-masked]
Date: Fri, 2 Mar 2001 11:30:05 +0200

Mallikarjun,

Answers in text ...

Thanks,
Julo

"Mallikarjun C." <[email-masked]> on 01/03/2001 21:02:14

Please respond to [email-masked]

To:   [email-masked]
cc:
Subject:  iSCSI: draft04 questions

Julian,

Some questions:

++++ This is a leftover from an older scheme (very old) thanks +++

+++ UseR2T=yes (default) and ImmediateData=no +++

3. Section 2.14 states:
     "If an initiator intends to start recovery for a failing connection it
     MUST use the either the Logout command to "clean-up" the target end
     of a failing connection and enable recovery to start, or use the
     restart option of the Login command to the same effect."
This seems to be contradicting section 2.10.1, where a prior logout of the
CID is stated as a requirement for using the restart bit of the Login PDU
(which I agree with).
+++ It is a colapse of a logout-login for those cases in which a new
connection is oppened _ and the target allows only one connection! It
allows the target to do the logout function then follow with the login +++

+++ Fixed 2.14.3 - vox populi in Orlando not to create confusion -:) +++

5. In the same section 2.18, I dont' quite see the operational difference
for an initiator, if any, between iSCSI event codes 2 & 3.  Could you
please
comment?
+++ 2 is for the purists - message,logout,login, 3 indicates that the
target will disconnectd the named connection +++
Also, isn't the time in seconds the maximum time than the minimum
time as currently stated?
+++ time is minimum - allows the target to do the cleanup before being hit
with a
login +++
6. In section 2.20.1, reject reason code 5 is stated as a "command
restart reject".  Seems like the usage of "restart" in the draft elsewhere
is for the connection/session login, and "retry" is for commands -
except this one.  Comment if I am reading too much into the usage.
+++ i'll make it retry +++
7. Section 6.2 on digest errors states:
     "If the error is a Data-Digest-Error in a Data-PDU, the target
     MUST either request retransmission with a R2T or answer with
     a Reject iSCSI PDU and abort the task."
Were you meaning the target's internal termination of the task? That
could cause problems on a subsequent Data PDU reception from the
initiator since there may be no state for the task in the target.
Suggest dropping "and abort the task".

+++For this reason 2.4.2 delays the bad status and I have already added a
similar statement in 6.2+++

is likely to receive the data/status PDUs for the command shortly
thereafter.
+++ fixed +++

+++ will fix +++
Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka

---

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 02 Mar 2001 12:49:49 PST

Julian,

Thanks.  I am not clear on some. Comments.

>+++ UseR2T=yes (default) and ImmediateData=no +++

I am confused.  I thought this combination disallows just the "immediate"
data, and not the unsolicited data as a whole.  The draft hints at this
in section 1.2.5.
	"A target MAY separately enable immediate data without 
	enabling the more general (separate data PDUs) form of
   	unsolicited data."

If I misunderstood, could you please comment how immediate data alone is
disabled, while allowing unsolicited data of FirstBurstSize?

>+++ Fixed 2.14.3 - vox populi in Orlando not to create confusion -:) +++

As I said in my message to David, since we said a message is a PDU in 1.2, 
an "Asynchronous Message PDU" would be a redundant term, unless we call it
as "Asynchronous something PDU".  Do you see what I was getting at?  I 
would leave it upto you.

>+++ time is minimum - allows the target to do the cleanup before being hit

Do I take it then that the draft currently doesn't specify the maximum time
the targets should keep the session & connection records around hoping
for a restart?  I would strongly recommend adding that as an additional
field in the payload, since that is a resource allocation and scalability issue.

Thanks.
--
Mallikarjun 

Mallikarjun Chadalapaka

---

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

=== coments in text Julo

"Mallikarjun C." <[email-masked]> on 02/03/2001 22:49:49

To:   [email-masked]
cc:
Subject:  Re: iSCSI: draft04 questions

Julian,

I am confused.  I thought this combination disallows just the "immediate"
data, and not the unsolicited data as a whole.  The draft hints at this
in section 1.2.5.
     "A target MAY separately enable immediate data without
     enabling the more general (separate data PDUs) form of
     unsolicited data."
=== for this case you have UseR2T=yes and ImmediateData=yes
If I misunderstood, could you please comment how immediate data alone is
disabled, while allowing unsolicited data of FirstBurstSize?
=== UseR2T=no ImmediateData=no

Do I take it then that the draft currently doesn't specify the maximum time
the targets should keep the session & connection records around hoping
for a restart?  I would strongly recommend adding that as an additional
field in the payload, since that is a resource allocation and scalability
issue.

Thanks.

=== I assume that a traget can figure out by itself after a while that
there is no rendezvous - but I am open to requests
--
Mallikarjun

Mallikarjun Chadalapaka