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

From: "Mallikarjun C." <[email-masked]>
Date: Fri, 29 Dec 2006 13:11:25 -0800 (PST)

Julian,  

As I read through relevant sections of 3720, I see the following in section 5.3:

The Login Phase is only implemented via Login Request and Responses.
The whole Login Phase is considered as a single task and has a single
Initiator Task Tag (similar to the linked SCSI commands).

Section 10.10.3 makes a similar point about text requests/responses.  

I do not thus believe that the current text allows the flexibility to pipeline multiple outstanding Login/Text Requests/Responses.  That of course means that I guess I am reaching the opposite conclusion than the one I started with - the clarification the anonymous reviewer had wanted me to put in wrt Login Response is not necessary.  

If OTOH you believe we need to explicitly allow pipelining overriding this 3720 text, please let me know.

Thanks.

Mallikarjun

----- Original Message ----
From: Julian Satran <[email-masked]>
To: Mallikarjun C. <[email-masked]>
Cc: IPS <[email-masked]>
Sent: Friday, December 29, 2006 3:15:41 AM
Subject: Re: [Ips] IG clarifications: Login Response & Reject reason codes

Mallikarjun,

If we allow for multiple outstanding
Login Requests we will have to allow for multiple outstanding Login Responses.

Regards,

Julo

"Mallikarjun C."
<[email-masked]> 
28/12/06 21:45

To

Julian Satran/Haifa/IBM@IBMIL

cc

IPS <[email-masked]>

Subject

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

Julian,

Thanks for the inputs, I somehow overlooked
to respond to this email earlier.

I agree with you on the "Task in progress" Reject reason code.
 There is no 

Unless I hear new objections, I would like
to note "Negotiation Reset" Reject reason code as obsolete.  Based
on the silence so far, like you, I do not believe it is in use.

On the "no more than one outstanding
Login Response" semantics, your comments seem to be around Login Request
PDU (and I believe we have such text for Login Request PDU) - do you see
any cases wherein there can be multiple outstanding Login Responses on
the wire?  The request I got was to clarify if there is a plausible
use case.  

Thanks!

Mallikarjun

----- Original Message ----

From: Julian Satran <[email-masked]>

To: Mallikarjun C. <[email-masked]>

Cc: IPS <[email-masked]>

Sent: Monday, December 11, 2006 1:34:41 PM

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

"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).

> 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 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 :-)

> 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

__________________________________________________

Do You Yahoo!?

Tired of spam? Yahoo! Mail has the best spam protection around 

http://mail.yahoo.com 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

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

---

From: Julian Satran <[email-masked]>
Date: Sun, 31 Dec 2006 09:08:51 +0200

Mallikarjun,

Thanks for getting through all this. Yes I think that cthe clarification 
is not needed. But if the reviewer felt that not to clear or explicit 
enough some text will help (and hopefully not harm).

Regards,
Julo

"Mallikarjun C." <[email-masked]> 
29/12/06 23:11

To
IPS <[email-masked]>
cc

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

Julian, 

As I read through relevant sections of 3720, I see the following in 
section 5.3:

I do not thus believe that the current text allows the flexibility to 
pipeline multiple outstanding Login/Text Requests/Responses.  That of 
course means that I guess I am reaching the opposite conclusion than the 
one I started with - the clarification the anonymous reviewer had wanted 
me to put in wrt Login Response is not necessary. 

If OTOH you believe we need to explicitly allow pipelining overriding this 
3720 text, please let me know.

Thanks.

Mallikarjun

----- Original Message ----
From: Julian Satran <[email-masked]>
To: Mallikarjun C. <[email-masked]>
Cc: IPS <[email-masked]>
Sent: Friday, December 29, 2006 3:15:41 AM
Subject: Re: [Ips] IG clarifications: Login Response & Reject reason codes

Mallikarjun, 

If we allow for multiple outstanding Login Requests we will have to allow 
for multiple outstanding Login Responses. 

Regards, 
Julo 

"Mallikarjun C." <[email-masked]> 
28/12/06 21:45 

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

Julian, 
 
Thanks for the inputs, I somehow overlooked to respond to this email 
earlier. 

I agree with you on the "Task in progress" Reject reason code.  There is 
no 
 
Unless I hear new objections, I would like to note "Negotiation Reset" 
Reject reason code as obsolete.  Based on the silence so far, like you, I 
do not believe it is in use. 
 
On the "no more than one outstanding Login Response" semantics, your 
comments seem to be around Login Request PDU (and I believe we have such 
text for Login Request PDU) - do you see any cases wherein there can be 
multiple outstanding Login Responses on the wire?  The request I got was 
to clarify if there is a plausible use case. 
 
Thanks! 
 
Mallikarjun 
----- Original Message ----
From: Julian Satran <[email-masked]>
To: Mallikarjun C. <[email-masked]>
Cc: IPS <[email-masked]>
Sent: Monday, December 11, 2006 1:34:41 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.
> 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). 

> PDU semantics as well) says: "An initiator MUST have at most one 
seems).
> a TMF response reason code for that case (Julian?).  So I'm not sure

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 :-) 

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com _______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips