Subject: RE: iSCSI: Use of Reject as a key value

From: "Julian Satran" <[email-masked]>
Date: Sat, 27 Jul 2002 16:37:08 +0300

Kevin,

The current text says explicitly that reject is a valid response (i.e., 
not a protocol error).
The addition makes only explicit the obvious.
On the other hand a reject may be bad for some parameters (e.g., some 
locally enforced authentication).
In that case you are free to close the session with a login error.
But that IS NOT the general case. The wording about Reject not being a 
protocol error is NOT a change.

Julo

[email-masked]
07/26/2002 05:54 PM

        To:     Julian Satran/Haifa/IBM@IBMIL, [email-masked]
        cc:     [email-masked], [email-masked], [email-masked]
        Subject:        RE: iSCSI: Use of Reject as a key value

The iSCSI spec did not specify the handling of reject prior to the current 
v15 working version.

I am NOT proposing changing the case sensitivity.

I am merely pointing out a potential problem in the proposed handling of 
reject during login negotiation.

Our current implementation handles it as described by Professor Russell as 
"Case 2", the rejection of a parameter during login (except for markers) 
terminates the login.

My example was meant to demonstrate the problem associated with continuing 
the login with rejected parameters. The initiator and target have the 
potential to continue with miss-matched parameters.

Professor Russell had three proposals in what he posted. He was not 
requesting a particular wording but meant to open it up to the list for 
discussion and a solution.

Kevin

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Friday, July 26, 2002 1:33 AM
To: [email-masked]
Cc: [email-masked]; Julian Satran; [email-masked];
[email-masked]
Subject: RE: iSCSI: Use of Reject as a key value

Do you propose the formulate the standard so that it can tolerate all
initiator syntax errors? Or just we state that it should be case
insensitive.
The first would be a bad idea. The protocol has enough complexity in order
to deal with transport errors. It would be a bad idea to add
implementation errors to the list.
If you want case insensitivity - this was discussed and rejected a long
time ago - again because it felt unnecessary.

I would also like to point out that this is not a change. This behavior 
was
always assumed (and implied in the statements about negotiations
atomicity).
The statement was added at the request of Bob Russell as a clarification.

Julo

                      kevin_lemay@agile   
                      nt.com                   To:       Julian 
Satran/Haifa/IBM@IBMIL, [email-masked]  
                                               cc:       [email-masked], 
[email-masked] 
                      07/25/2002 09:59         Subject:  RE: iSCSI: Use of 
Reject as a key value 
                      PM   

Julian,

I think that this change is a bad idea.

The spec says that:

"If the acceptor sends "Reject" as an answer the negotiated key is left at
its current value (or default if no value was set). If the current value 
is
not acceptable to the proposer on the connection or session it is sent the
proposer MAY choose to terminate the connec- tion or session."

But what happens in the following case:

i->ImmediateData=Yes
t->ImmediateData=no (Note: wrong case used)

The initiator must use the default, which is ImmediateData=Yes, and there
is no way for the initiator to inform the target of the error because
sending:
i->ImmediateData=Reject would be a re-negotiation.

This will not work!

Kevin

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, July 24, 2002 7:52 PM
To: Robert D. Russell
Cc: [email-masked]; [email-masked]
Subject: Re: iSCSI: Use of Reject as a key value

Bob,

On the last pdf you will find a statement about what to do.

Julo

             "Robert D. Russell" <[email-masked]>
Sent by: [email-masked]

07/25/2002 12:58 AM

        To:        [email-masked]
        cc:
        Subject:        iSCSI: Use of Reject as a key value

Julian:

Attached are 2 ascii text files.

The first, reject_extracts.txt, contains all the pieces of
draft 14 (the latest available txt version of the drafts)
that say anything about the use of Reject as a key value.
(At least all those I could find using simple search --
unfortunately, Reject is also the name of a PDU and hence
it is not a simple mechanical process to distinguish the two
uses!  If I missed some, please let me know.)

The second, reject_comments.txt, are my comments on these
excerpts from the standard.

It seems to me that the key thing missing in the standard is
a general statement about "what to do next" if a key=Reject response
is received.  Except for the OFMarkInt and IFMarkInt keys,
I could find no other statement about how to proceed after
receiving the key=Reject response.  In looking through the
e-mails posted to the list for June and July, I also could find
nothing, although many people seem to be taking the third
of the 3 interpretations I listed in reject_comments.txt.

I am requesting a clear statement somewhere in the standard that
says "what to do next" upon receiving a key=Reject response.

Thank you for your consideration.

Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774

#### reject_extracts.txt has been removed from this note on July 25 2002 
by
Julian Satran
#### reject_comments.txt has been removed from this note on July 25 2002 
by
Julian Satran

---

From: "Amir Shalit" <[email-masked]>
Date: Sat, 27 Jul 2002 10:15:59 -0700

Piggybacking session window information in data phase is hurting fast path
performance.
Can it be avoided? Target can always use NOP-IN to update session window if
it feels
an urge to do so.

Amir

---

From: "Julian Satran \(Actcom\)" <[email-masked]>
Date: Mon, 29 Jul 2002 11:20:39 +0300

That is purely an implementation issue.
I have seen some where it does not.
Look carefully at what piggyback information you must use and when.

Julo
  ----- Original Message ----- 
  From: Amir Shalit 
  To: Julian Satran 
  Cc: [email-masked] 
  Sent: Saturday, July 27, 2002 8:15 PM
  Subject: Piggybacking session window in data phase

  Piggybacking session window information in data phase is hurting fast path performance.
  Can it be avoided? Target can always use NOP-IN to update session window if it feels
  an urge to do so.

  Amir

---

From: "Julian Satran \(Actcom\)" <[email-masked]>
Date: Mon, 29 Jul 2002 11:27:42 +0300

Julo
  ----- Original Message ----- 
  From: Amir Shalit 
  To: Julian Satran 
  Cc: [email-masked] 
  Sent: Saturday, July 27, 2002 8:15 PM
  Subject: Piggybacking session window in data phase

  Amir