Subject: [Ips] IG clarifications: Login Response & Reject reason codes

From: "Mallikarjun C." <[email-masked]>
Date: Mon, 11 Dec 2006 10:15:23 -0800 (PST)

All:

I received some offline feedback on the implementers' guide draft from  a few reviewers who preferred to be anonymous.  Please review & comment.

1) RFC 3720 does not explicitly call out that there cannot be more than one outstanding Login-Response PDU on one iSCSI connection at any given time (although the C-bit text indirectly implies it).

Section 10.10 on Text Request PDU (which should cover Login Request PDU semantics as well) says: "An initiator MUST have at most one outstanding Text Request on a connection at any given time."  Essentially, an analog for Login/Text Response is missing (or so it seems).

2) RFC 3720 does not specify the use case for Reject reason code "Task in progress" (0x07).

I vaguely recall we put in this reason code for task reassignment attempts while a task is in progress, but then we subsequently added a TMF response reason code for that case (Julian?).  So I'm not sure if reason code 0x07 is used by implementations any longer.  

The other non-obvious case is that of a "negotiation reset" Reject reason code.  What is this used for by implementations, if at all?  If I don't hear any objections, I will deprecate these two reason codes.

Mallikarjun

____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: Julian Satran <[email-masked]>
Date: Mon, 11 Dec 2006 23:34:41 +0200

"Mallikarjun C." <[email-masked]> wrote on 11/12/2006 20:15:23:

> All:
> 
> I received some offline feedback on the implementers' guide draft 
> from  a few reviewers who preferred to be anonymous.  Please review & 
comment.
> 
> 1) RFC 3720 does not explicitly call out that there cannot be more 
> than one outstanding Login-Response PDU on one iSCSI connection at 
> any given time (although the C-bit text indirectly implies it).
> 
>

This is intentional. At the time we where playing with the idea of 
pipelining the login.
However it is common practice to have a single outstanding Login Request.
I think that the only thing that becomes problematic is the phase change 
request (there you can have only one outstanding).
There is already text that says that all changes to key values become 
final only at the end (when consistency can be reasonably checked).

> Section 10.10 on Text Request PDU (which should cover Login Request 
> PDU semantics as well) says: "An initiator MUST have at most one 
> outstanding Text Request on a connection at any given time." 
> Essentially, an analog for Login/Text Response is missing (or so it 
seems).
> I vaguely recall we put in this reason code for task reassignment 
> attempts while a task is in progress, but then we subsequently added
> a TMF response reason code for that case (Julian?).  So I'm not sure
> if reason code 0x07 is used by implementations any longer. 
> 

The reject can used when the initiator attempts to start a new task but a 
task with the same ITT is still active for those cases when the target 
can't be sure this is a protocol error (e.g., a race between a logout and 
a reissued SCSI command).

> The other non-obvious case is that of a "negotiation reset" Reject 
> reason code.  What is this used for by implementations, if at all? 
> If I don't hear any objections, I will deprecate these two reason codes.
> 

The negotiating can't be continued by one of the parties but the partial 
results (e.g., previous stage) are OK and no renegotiation is deemed 
necessary. I have no clue if somebody uses it but I felt at the time that 
the purists will object if I'd suggest restarting the login :-)

---

From: "Eddy Quicksall" <[email-masked]>
Date: Tue, 12 Dec 2006 17:30:58 -0500

Julian,

Then the negotiation reset applies to only the current negotiation exchange? If so then maybe this needs to be cleared up.

The only place I process that in my target is when I'm in a full feature phase text negotiation. If I receive it I reset the fact that I may be in a continuation state. I figured it was for that purpose. I don't know why an initiator would "change his mind in the middle of the stream".

   An initiator MAY reset an operational parameter negotiation by
   issuing a Text request with the Target Transfer Tag set to the value
   0xffffffff after receiving a response with the Target Transfer Tag
   set to a value other than 0xffffffff.  A target may reset an
   operational parameter negotiation by answering a Text request with a
   Reject PDU.

Eddy
  ----- Original Message ----- 
  From: Julian Satran 
  To: Mallikarjun C. 
  Cc: IPS 
  Sent: Monday, December 11, 2006 4:34 PM
  Subject: Re: [Ips] IG clarifications: Login Response & Reject reason codes

  "Mallikarjun C." <[email-masked]> wrote on 11/12/2006 20:15:23:

  > from  a few reviewers who preferred to be anonymous.  Please review & comment.
  > 

  This is intentional. At the time we where playing with the idea of pipelining the login. 
  However it is common practice to have a single outstanding Login Request. 
  I think that the only thing that becomes problematic is the phase change request (there you can have only one outstanding). 
  There is already text that says that all changes to key values become final only at the end (when consistency can be reasonably checked). 

  > Essentially, an analog for Login/Text Response is missing (or so it seems).
  > 

  The reject can used when the initiator attempts to start a new task but a task with the same ITT is still active for those cases when the target can't be sure this is a protocol error (e.g., a race between a logout and a reissued SCSI command). 

  > If I don't hear any objections, I will deprecate these two reason codes.

  The negotiating can't be continued by one of the parties but the partial results (e.g., previous stage) are OK and no renegotiation is deemed necessary. I have no clue if somebody uses it but I felt at the time that the purists will object if I'd suggest restarting the login :-) 

  > Mallikarjun

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

---

From: Julian Satran <[email-masked]>
Date: Wed, 13 Dec 2006 17:32:12 +0200

Eddie,

It appears quite obvious that the negotiation reset "nullifies"the 
negotiation in progress - i.e., brings the parties back to the point they 
where before he negotiation started (not when the phase started). It does 
not nullify previously concluded negotiations nor does it nullify the 
login negotiation results.

It obliges inititiator and target to be able to "roll-back" a negotiation.

I am not sure it needs clarifying text but I have nothing against it being 
added.

Julo

"Eddy Quicksall" <[email-masked]> 
13/12/06 00:30

To
"Mallikarjun C." <[email-masked]>, Julian Satran/Haifa/IBM@IBMIL
cc
"IPS" <[email-masked]>
Subject
Re: [Ips] IG clarifications: Login Response & Reject reason codes

Julian,
 
Then the negotiation reset applies to only the current negotiation 
exchange? If so then maybe this needs to be cleared up.
 
The only place I process that in my target is when I'm in a full feature 
phase text negotiation. If I receive it I reset the fact that I may be in 
a continuation state. I figured it was for that purpose. I don't know why 
an initiator would "change his mind in the middle of the stream".

Eddy
----- Original Message ----- 
From: Julian Satran 
To: Mallikarjun C. 
Cc: IPS 
Sent: Monday, December 11, 2006 4:34 PM
Subject: Re: [Ips] IG clarifications: Login Response & Reject reason codes

comment.

seems).