Subject: Re: iSCSI - Change - Login/Text commands with the binary stage co de

From: "Wheat, Stephen R" <[email-masked]>
Date: Thu, 23 Aug 2001 09:58:34 -0700

Julian,

1.3.6 ISID states that the target should check to see if the old session is
still active when a duplicate session is detected.

I have two questions, the second only if you answer in the affirmative on
the first ;^)

1. Is there a properly executed sequence of events (i.e., no coding error on
the target side) where the session is not active, but the target hadn't
taken notice of it?  It appears this as a protocol-specified means to work
around a flaw in a target's implementation.  I interpret the state diagram
transitions as being atomic wrt other commands.  I.e., the last logout would
result in the various transitions of the connection/session prior to the
initiator starting the session up again.  And the target would have
completed the transitions prior to handling a new session request.

2. If you answered (1) in the affirmative, then the word "Active" is not
consistent with the 6.3 Session State Diagram.  Does this mean the target
got lost, due to transport failures of any sort, in its transition from
Q3-to-Q2-to-Q1?  It sounds like the intent is to close the old session if
the session was in Q2 or Q4, presuming if it were in Q1,  it would not have
been found as a duplicate.

Stephen

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 23 Aug 2001 21:14:46 +0300

Stephen,

1.If the initiator goes away for a while and reboots and there was no
activity on the connections
the target may see a session alive (I am not sure that it has to appear on
the state diagram but maybe).

2.Again - I am not sure that the curent state diagram includes death of the
initiator

Julo

"Wheat, Stephen R" <[email-masked]>@ece.cmu.edu on 23-08-2001
19:58:34

Please respond to "Wheat, Stephen R" <[email-masked]>

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage co
      de

Julian,

1. Is there a properly executed sequence of events (i.e., no coding error
on
the target side) where the session is not active, but the target hadn't
taken notice of it?  It appears this as a protocol-specified means to work
around a flaw in a target's implementation.  I interpret the state diagram
transitions as being atomic wrt other commands.  I.e., the last logout
would
result in the various transitions of the connection/session prior to the
initiator starting the session up again.  And the target would have
completed the transitions prior to handling a new session request.

Stephen

---

From: "Wheat, Stephen R" <[email-masked]>
Date: Thu, 23 Aug 2001 12:50:56 -0700

Julian,

I don't understand your answer.  For the scenario given, I would presume
then that the target would reject the new session attempt, as it sees the
previous session still "alive".  What is there to tell the target that this
is any different from when the Initiator is erroneously using the repetitive
session id?

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 11:15 AM
To: [email-masked]
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
co de

Stephen,

Julo

To:   [email-masked]
cc:

Julian,

Stephen

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 23 Aug 2001 23:56:27 +0300

Stephen,

That can happen as the target may set-up completely new TCP connections
(the old sockets are still there and look OK).
Untill the login is  progessing he assumes that this is just another
open-session attempt. Then he checks the old session and the session is
dead (initiator has closed the connections).

The target has to distinguish only between a session that is alive (and
reject the new one) and one that its dead in which case it can clean-up.

Julo

"Wheat, Stephen R" <[email-masked]> on 23-08-2001 22:50:56

To:   Julian Satran/Haifa/IBM@IBMIL, [email-masked]
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
          de

Julian,

I don't understand your answer.  For the scenario given, I would presume
then that the target would reject the new session attempt, as it sees the
previous session still "alive".  What is there to tell the target that this
is any different from when the Initiator is erroneously using the
repetitive
session id?

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 11:15 AM
To: [email-masked]
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
co de

Stephen,

Julo

To:   [email-masked]
cc:

Julian,

Stephen

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 24 Aug 2001 08:04:38 +0300

Stephen,

I wonder if 123 words (your note) are really needed to say that bookmarks
have no role at all.

For an exchange going well  and on a single connection bookmarks are not
doing more that their paper counterpart. It is when things go wrong that
you need them.

Assume that you have the following sequence:

a)I->T text B=0
b)T->I text B=1 Bkmk1
c)I->T text B=1 Bkmk1
d)T->I text B=1 Bkmk2
e)I ->T...

Assume now that D got lost (digest) and the initiator reissues C.  Without
a Bookmark
the target will think that he got a prompt after D when in fact he got a
replay of C

In summary the bit acts like the paper bookmark and the bookmark field is
more like the word-processor bookmarks - it hold information relevant to
the party that built it.

Julo

"Wheat, Stephen R" <[email-masked]> on 24-08-2001 01:21:04

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
      de

OK; that makes more sense.

But now, why do we have it?  This whole discussion could have been avoided
if it wasn't there in the first place.  How many that follow me in reading
this will have the same questions?  Why should the spec provide something
that has no value in the execution of the spec?  It seems to me that this
is
superfluous, and as such doesn't belong in the spec.  I.e., this seems more
clearly a unnecessary item ever-more-so than alias.

Would you mind doing a query of the group as to who has objection to
removing the bookmark field?

I really hope my relatively new exposure to all of this has value to you
and
the other authors on the readability/clarity of the spec.

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 11:10 AM
To: Wheat, Stephen R
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de

Stephen,

Bookmark is an opaque thing.  The initiator copies it dutifully from the
target.
The target may choose to put some information there or leave it 0 etc.

Regards,
Julo

"Wheat, Stephen R" <[email-masked]> on 23-08-2001 18:03:45

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
          de

Julian,

Thanks for your response.

OK, then if you follow your temptation, then the bookmark field goes away
and the B-bit does it all, yes?  Otherwise, I'm still missing the sequence
of events where the bookmark fields contributes to syncronization or
segregation or both.

Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, August 22, 2001 11:10 PM
To: Wheat, Stephen R
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de

Stephen,

I've fixed the 2 offending occurrences of Initiator Text Tag (It was a typo
- thanks).

The bookmark  was introduced to:

   relieve the target from the need to maintain state for a number of
   pending sequences - you can have only one bookmark (with some state in
   it) I am tempted to make it one bookmark/initiator
   allow to certify to the target that the initiator is still there and
   willing to get more information (when you clear the bookmark you can
   delete whatever state you maintained).

Regards,
Julo

"Wheat, Stephen R" <[email-masked]> on 22-08-2001 20:48:25

To:   Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  RE: iSCSI - Change - Login/Text commands with the binary stage co
      de

Julian, just to you.

In a couple of places, this refers to "Initiator Text Tag".  What is that?
Is it a typo?

Also, I've been pondering the bookmark field.  Why does this field exist
beyond the B bit, if the bookmark's validity is invalidated by having
received a command with a different ITT?  There must be a scenario where
the
following doesn't work.  Please advise.

      I->T Text SendTargets=all (F=1,B=0)
      T->I Text <part 1> (F=0,B=1)
      I->T Text <empty> (F=1,B=1)
      T->I Text <part 2> (F=0,B=1)
      I->T Text <empty> (F=1,B=1)
      ...
      T->I Text <part n> (F=1,B=0)

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, August 22, 2001 1:30 AM
To: [email-masked]
Subject: iSCSI - Change - Login/Text commands with the binary stage code

1.1.5     Bookmark

   An opaque handle copied from a previous text response.  It is supposed
   to allow a target to transfer a large amount of textual data over a
   sequence of text-command/text-response exchanges.  The target associates
   the bookmark it issues with the Initiator Task Tag and a received
   Bookmark is considered valid by the Target only if received with the
   same Initiator Task Tag and if the target did not receive on the same
   connection a text command with a different Initiator Text Tag since it
*************                                           ^^^^ ????
   issued the Bookmark.

---

From: "Wheat, Stephen R" <[email-masked]>
Date: Mon, 27 Aug 2001 07:47:40 -0700

Julian,

So the Target ignores C-replay CmdSN, mistaking C-replay to be a post-D
prompt.  How can that be?

Stephen the Terse (still looking for bookmark rationale)

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 10:05 PM
To: [email-masked]
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de

Stephen,

a)I->T text B=0
b)T->I text B=1 Bkmk1
c)I->T text B=1 Bkmk1
d)T->I text B=1 Bkmk2
e)I ->T...

Julo

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 11:10 AM
To: Wheat, Stephen R
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de

Stephen,

Regards,
Julo

Julian,

Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, August 22, 2001 11:10 PM
To: Wheat, Stephen R
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de

Stephen,

Regards,
Julo

Julian, just to you.

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, August 22, 2001 1:30 AM
To: [email-masked]
Subject: iSCSI - Change - Login/Text commands with the binary stage code

1.1.5     Bookmark

---

From: "Wheat, Stephen R" <[email-masked]>
Date: Mon, 27 Aug 2001 08:07:32 -0700

Argh, in my attempt to be concise, I forgot to ask about why the target
would ignore the X-bit and consider this as a new command/prompt.  Shouldn't
that suffice to see that it is a replay of a text command, instead of a new
one?  I realize that with I-bit set, CmdSN may not be trackable, yes?

Stephen

-----Original Message-----
From: Wheat, Stephen R 
Sent: Monday, August 27, 2001 7:48 AM
To: [email-masked]
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de

Julian,

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 10:05 PM
To: [email-masked]
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de

Stephen,

a)I->T text B=0
b)T->I text B=1 Bkmk1
c)I->T text B=1 Bkmk1
d)T->I text B=1 Bkmk2
e)I ->T...

Julo

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 11:10 AM
To: Wheat, Stephen R
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de

Stephen,

Regards,
Julo

Julian,

Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, August 22, 2001 11:10 PM
To: Wheat, Stephen R
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de

Stephen,

Regards,
Julo

Julian, just to you.

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, August 22, 2001 1:30 AM
To: [email-masked]
Subject: iSCSI - Change - Login/Text commands with the binary stage code

1.1.5     Bookmark

---

From: "Julian Satran" <[email-masked]>
Date: Mon, 27 Aug 2001 18:19:18 +0300

Stephen,

Yes with one bookmark per initiator my scenario is wrong and the a bit is
enough for correct operation.

Regards,
Julo

"Wheat, Stephen R" <[email-masked]>@ece.cmu.edu on 27-08-2001
17:47:40

To:   [email-masked]
cc:

Julian,

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 10:05 PM
To: [email-masked]
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de

Stephen,

a)I->T text B=0
b)T->I text B=1 Bkmk1
c)I->T text B=1 Bkmk1
d)T->I text B=1 Bkmk2
e)I ->T...

Julo

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 11:10 AM
To: Wheat, Stephen R
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de

Stephen,

Regards,
Julo

Julian,

Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, August 22, 2001 11:10 PM
To: Wheat, Stephen R
Subject: RE: iSCSI - Change - Login/Text commands with the binary stage
co de

Stephen,

Regards,
Julo

Julian, just to you.

Thanks,
Stephen

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, August 22, 2001 1:30 AM
To: [email-masked]
Subject: iSCSI - Change - Login/Text commands with the binary stage code

1.1.5     Bookmark

---

From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <[email-masked]>
Date: Thu, 30 Aug 2001 18:11:39 +0100

Julian, Sandeep,

I am very much in favour of the option A (Always send the names
in the login command).

This is inline with what we proposed in the Matthew/Bob/Marj
login proposal and as Sandeep has pointed out it does simplify
the protocol enormously.

Cheers

Matthew Burbridge

-----Original Message-----
From: Sandeep Joshi [mailto:[email-masked]]
Sent: Thursday, August 30, 2001 5:12 PM
To: [email-masked]
Subject: Re: iSCSI - Change - Login/Text commands with the binary stage
code

Julian,

> > As for the names - I though that security people might object having the
> > name in clear if the security phase does not make use of the name.
> > Otherwise we can mandate them on the login but I wonder if that is a
real
> > improvement or we are getting carelles.
> >
> > Julo

The problem with these names (and hence the request from Steve and
others 
earlier) is that it is not possible to know when the target wants them. 

Consider the following excerpts from your latest login proposal..

> A target MAY use the iSCSI Initiator Name as part of its access control
> mechanism; therefore, the iSCSI Initiator Name MUST be sent before the
> target is required to disclose its LUs.

The above is _very_ confusing..how can the initiator know if the
 the target is doing access control ?

> If the iSCSI Target Name and/or iSCSI Initiator Name is going to be used
> in determining the security mode or it is implicit part of
> authentication, then the iSCSI Target Name and/or iSCSI Initiator Name
> MUST be sent in the login command for the first connection of a session
> to identify the storage endpoint of the session

In both the above cases, how does the initiator know when the target
requires these names?  The partial login response occurs *only* once.
So when going from the security->operational phase, there is no
indication that the target would like these names sent.

There are 3 options here :
(A) ALways send the names in the login command.  Simplify target
   and initiator and eliminate a few of those partial login 
   response codes.
(B) Maintain a configuration database (per-target) of when names
   must be sent - adds an administration burden.  
(C) Change the wire protocol to allow the target to indicate when
   the names must be sent - again more complications. 

To round up, I prefer Option (A).  These are just names and not
passwords, so the security risks are minimal.  Are we trying to 
protect against traffic analysis ?

-Sandeep

> >
> > Steve Senum <[email-masked]>@ece.cmu.edu on 29-08-2001 23:59:36
> >
> > Please respond to Steve Senum <[email-masked]>
> >
> > To:   ietf-ips <[email-masked]>
> > cc:
> >       code
> > A couple of ideas from Matthew Burbridge & Co.'s
> > login proposal that has generated some interest here:
> >
> > 1. Removal of partial login response.  Is it still needed?
> >
> > 2. Requiring Initiator and (if not a discovery session)
> >    Target names on login command, so they are always
> >    available if needed by the initial phase.
> >
> > Comments?
> >
> > Regards,
> > Steve Senum
> >
> >
> >
> >

---

From: Michael Schoberg <[email-masked]>
Date: Thu, 30 Aug 2001 11:47:54 -0500

I'm not sure if this has been suggested, but one possible solution to the
login state confusion could be to eliminate this dual master relationship
between the iSCSI initiator logging in and the iSCSI target.  When the iSCSI
initiator attempts login, it could send an empty (no text options) message
and let the iSCSI Target send back the options it supports as either empty
(InitiatorName=) or with the default (MaxConnections=8).  The login would
proceed until the iSCSI target sends a completion message.  This would
remove the ambiguity of the order in which login variables are presented.

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 31 Aug 2001 00:40:11 +0300

Correct - at the cost of a round-trip. Julo

Michael Schoberg <[email-masked]>@ece.cmu.edu on 30-08-2001
19:47:54

Please respond to Michael Schoberg <[email-masked]>

To:   [email-masked]
cc:

between the iSCSI initiator logging in and the iSCSI target.  When the
iSCSI