Subject: RE: iSCSI - started countdown to 11

From: "Buck Landry" <[email-masked]>
Date: Fri, 22 Feb 2002 17:29:39 -0600

Two yes/no questions about the new Task Mgmt Function Request/Response wording.

1) Does ABORT_TASK_SET/CLEAR_TASK_SET apply to an immediate cmd with the same CmdSN?  Or to rephrase, in this example scenario:

T -> I (Nop-in, ExpCmdSN = 3)
I -> T (Scsi Command, CmdSN = 3, Immediate bit set)
I -> T (Task Mgmt Func Reqest, ABORT TASK SET, CmdSN = 3, Immediate bit set)

.. is the scsi command aborted?

The statement in section 9.5.1,

"Task management requests must act on all commands having a CmdSN lower than the task management CmdSN"

.. would resolve this nicely ("no") but in the same section, the wording

"According to [SAM2] for all the tasks covered by the task management response (i.e., with CmdSN not higher than the task management command CmdSN)"

...  implies that the task management response covers all tasks w/ equal or lower CmdSN while the request itself only covers tasks w/ lower CmdSN.

-----

2) For CLEAR TASK SET, does the target waiting behavior, 

"the target on its part, MUST wait for responses on all affected target transfer tags before acting on either of these two task management requests" 

.. include tasks that originated from a different initiator than the one that sent CLEAR TASK SET?  Everything in the draft points to "yes" (I think), and I kindof actually like this.  But I'm (somewhat) suprised that, given a scenario with two sessions attached to the same scsi target:

session "A": I -> T (Scsi Write Cmd, lun = 8, tag = 2)
session "A": T -> I (R2T, tag = 2)
session "B": I -> T (Task Mgmt Function Request CLEAR TASK SET, lun = 8)

.. that the target would require the cooperation of session "A"'s initiator and network connection in order to deliver a Task Mgmt Function Response to session "B".  I suppose, if this cooperation did not occur, then eventually a timeout would fire, the affected task could just be forcefully killed, and a task management response could be sent on session "A".. is that the way it's supposed to work?

Thanks for your consideration,
--buck

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Friday, February 22, 2002 10:05 AM
To: [email-masked]
Subject: iSCSI - started countdown to 11 

Dear colleagues, 

I've put on my site a "working" version of the draft labeled 10-90. 
Only the pdf version (with change bars vs. 10) is available. 
I'll soon get out also a text version - without a TOC but otherwise usable. 

Julo

---

From: Eddy Quicksall <[email-masked]>
Date: Fri, 22 Feb 2002 18:29:55 -0500

Should "Reject" be added to this?

Originator-> <key>=<valuex>
Responder-> <key>=<valuey>|NotUnderstood|Irrelevant

Eddy
 
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Friday, February 22, 2002 11:05 AM
To: [email-masked]
Subject: iSCSI - started countdown to 11 

Dear colleagues, 

Julo

---

From: Eddy Quicksall <[email-masked]>
Date: Fri, 22 Feb 2002 18:38:40 -0500

Since most things start with upper case, should we do that for all cases? I
think the only ones left are:
 
FMarker=<send|receive|send-receive|No>
SessionType= <discovery|normal>

Eddy
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Friday, February 22, 2002 11:05 AM
To: [email-masked]
Subject: iSCSI - started countdown to 11 

Dear colleagues, 

Julo

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 23 Feb 2002 08:02:11 +0200

Somesh,

Comments in text.

Thanks,
Julo

"Somesh Gupta" <[email-masked]>
Sent by: [email-masked]
22-02-02 22:10
Please respond to somesh_gupta

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     "IPS" <[email-masked]>
        Subject:        RE: iSCSI - started countdown to 11

Julian,
 
The language in A.1 should be changed from the most recent change. Two 
things
on the changes -
1. We should have a MAY instead of (the now lower case) should to
indicate the agreement reached - or worst case delete the sentence.

+++ the text reflects the currecnt agreement - the lower case should 
indicates a standard MAY with the performance warning that appears 
elswhere.  I could add the MAY but that would make the text even less 
readable
+++
 
2. The last sentence in the first para - newly added & repititive (last
sentence in previous paragraph) -
(in my opinion) tries to get around the agreement. It should either
be deleted, or changed to "some receiver implementation will provide
(significantly) better performance when the sender inserts markers" or
"some receiver implementations may provide degraded performance
to senders which do not insert markers". I prefer that we just not add it.
You have something like that in the previous paragraph anyway.

+++ OK - I just forgot that I have it in this part. I will delete the 
previous appearance.+++

One comment on what was not changed -
1. The last sentence in the para before A.1 - "in certain environment, a
sender ...." - I would suggest be changed to "in certain implementation, 
...".
As the behavior is more implementation dependent.
 
+++ That is incorrect. Evironment includes implementation and other 
factors like RTT.
Where RTT is very small framming won't buy you much. Where RTT is large 
they will.
+++

We reached a compromise on keeping it in the main draft and making
it a MAY. I hope we can keep that spirit.

+++ That is what I did and I may add the MAY - explicitly if that helps. 
+++
 
Somesh
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Julian Satran
Sent: Friday, February 22, 2002 8:05 AM
To: [email-masked]
Subject: iSCSI - started countdown to 11 

Dear colleagues, 

I've put on my site a "working" version of the draft labeled 10-90. 
Only the pdf version (with change bars vs. 10) is available. 
I'll soon get out also a text version - without a TOC but otherwise 
usable. 

Julo

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 23 Feb 2002 08:20:28 +0200

will do - thanks, julo

Eddy Quicksall <[email-masked]>
23-02-02 01:38

        To:     Julian Satran/Haifa/IBM@IBMIL, [email-masked]
        cc: 
        Subject:        RE: iSCSI - started countdown to 11

Since most things start with upper case, should we do that for all cases? 
I think the only ones left are:

 
Eddy
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Friday, February 22, 2002 11:05 AM
To: [email-masked]
Subject: iSCSI - started countdown to 11 

Dear colleagues, 

Julo

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 23 Feb 2002 08:20:26 +0200

Definitely - Thanks, Julo

23-02-02 01:29

Eddy
 
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Friday, February 22, 2002 11:05 AM
To: [email-masked]
Subject: iSCSI - started countdown to 11 

Dear colleagues, 

Julo

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 23 Feb 2002 20:02:52 +0200

Sorry - I've missed it.

Clear task set is an "unpleasant feature". Obviously iSCSI can't do 
anything it does not know about (other initiators) but we assume that SCSI 
knows how to take care of it (SCSI has to do the clear task set).  The 
rest is a matter of implementation.

Julo

"Buck Landry" <[email-masked]>
23-02-02 09:50

ok, that's cool.  I was worried about the single connection case, where an 
initiator might *expect* some determinative behavior :-)
 
I'm pressing my luck here but... did you have an off-the-top-of-your-head 
answer for my second question as well?  (scan for "2)" in this message if 
you don't know what I'm talking about) .. guess I was wondering if you had 
considered all the interesting consequences.
 
thanks,
--buck
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Saturday, February 23, 2002 12:20 AM
To: Buck Landry
Subject: RE: iSCSI - started countdown to 11

Buck, 

Hard to get a short answer to this question. 
Immediate commands have some "non-determinism". 
If you do what you suggested on a single connection session then the 
answer is yes. 
If you do it on a multiple connection session - your mileage may vary... 
If the command arrived before abort it will be aborted. If not... 
Moreover - even a later immediate command arriving before the abort will 
be aborted. 
The text say quite explicitly that iSCSI hands over to SCSI the abort 
function. 
With immediate commands we have no control on when a command reaches SCSI. 

Julo 

"Buck Landry" <[email-masked]> 
Sent by: [email-masked] 
23-02-02 01:29 
        
        To:        Julian Satran/Haifa/IBM@IBMIL, <[email-masked]> 
        cc:         
        Subject:        RE: iSCSI - started countdown to 11 

Two yes/no questions about the new Task Mgmt Function Request/Response 
wording.

1) Does ABORT_TASK_SET/CLEAR_TASK_SET apply to an immediate cmd with the 
same CmdSN?  Or to rephrase, in this example scenario:

T -> I (Nop-in, ExpCmdSN = 3)
I -> T (Scsi Command, CmdSN = 3, Immediate bit set)
I -> T (Task Mgmt Func Reqest, ABORT TASK SET, CmdSN = 3, Immediate bit 
set)

"Task management requests must act on all commands having a CmdSN lower 
than the task management CmdSN"

"According to [SAM2] for all the tasks covered by the task management 
response (i.e., with CmdSN not higher than the task management command 
CmdSN)"

...  implies that the task management response covers all tasks w/ equal 
or lower CmdSN while the request itself only covers tasks w/ lower CmdSN.

-----

"the target on its part, MUST wait for responses on all affected target 
transfer tags before acting on either of these two task management 
requests" 

.. include tasks that originated from a different initiator than the one 
that sent CLEAR TASK SET?  Everything in the draft points to "yes" (I 
think), and I kindof actually like this.  But I'm (somewhat) suprised 
that, given a scenario with two sessions attached to the same scsi target:

.. that the target would require the cooperation of session "A"'s 
initiator and network connection in order to deliver a Task Mgmt Function 
Response to session "B".  I suppose, if this cooperation did not occur, 
then eventually a timeout would fire, the affected task could just be 
forcefully killed, and a task management response could be sent on session 
"A".. is that the way it's supposed to work?

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Friday, February 22, 2002 10:05 AM
To: [email-masked]
Subject: iSCSI - started countdown to 11 

Dear colleagues, 

Julo