Subject: [Ips] Discovery reinstatement

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 24 Aug 2005 13:04:22 -0700

I spent sometime studying previous email threads on this topic and gave 
the topic some thought.  My current thinking and rationale is written 
below, I hope we'll arrive at a consensus on this topic this time......

In short, I'm leaning towards not saying anything on discovery 
reinstatement in the Implementer's guide, but still open to being 
persuaded otherwise.  Sorry it's a long note.

[Options:

A. TPGTs are always Node-scoped.  If Node name isn't specified in the 
discovery Login Request PDU, TPGT is meaningless and can't be inferred 
(or inferred to be invalid).

B. TPGTs are always Node-scoped.  If Node name isn't specified in the 
discovery Login Request PDU, a special "No-Name" iSCSI Node is implied. 
  This No-Name iSCSI Node has its own TPGT numbering space - one tag for 
each physically possible portal group - and thus the TPGT can be inferred. ]

Question 1:
Is it desirable that an initiator precisely know in advance when a new
discovery session might reinstate an existing discovery session (with
the same Network Entity)?

Yes (based on the plugfest feedback), so let's analyze what this leads 
us to.  If I got this wrong, feel free to reset me (especially to Bob 
Russell).

If the answer is no, then the whole discussion is moot (jump down to the
conclusions).

Question 2:
If so, how would the initiator deterministically know what reinstates
what?

Option A:
Assuming a fixed InitiatorName and ISID pair, a new no-named discovery
session will reinstate an old no-named discovery session if the
following is met:
(1) servicing iSCSI Portal (for the new session) is hosted by the
     same Network Entity as that of the existing session.

Option B:
Assuming a fixed InitiatorName and ISID pair, a new no-named discovery
session will reinstate an old no-named discovery session if the
following are met:
(1) servicing iSCSI Portal (for the new session) is hosted by the
     same Network Entity as that of the existing session, and,

(2) TPGT of the servicing iSCSI Portal (for the new session) matches
     that of the existing session.

Question 3:
Can the conditions for each option be met?

Condition (1) can be met if we assume that the initiator has a
(non-iSCSI) way of discovering that two IP addresses are hosted
by one remote system (i.e. iSCSI Network Entity).

Condition (2) for realizing Option B however cannot be met because TPGT
is an exclusive iSCSI notion, and iSCSI neither defines TPGTs in the
absence of a node name nor a way to communicate them to the initiator
apriori.  Besides, there's a bootstrapping problem in that a discovery
session is needed to find out TPGT associations.

So I believe condition (2) cannot be met, and thus do not see a way to
support Option.B *given* the desire that the initiator deterministically
predict session reinstatement in advance (answer to Question.1).

To summarize:

I see four possibilities (in decreasing order of my preference):

I.  We reject the assertion that initiator should be able to
     deterministically predict session reinstatement.  So say
     nothing about this topic in the Implementer's guide.

II. We accept the assertion.  So mandate Option A in Implementer's
     guide.

III.We "semi-accept" the assertion by saying that the initiator cannot
     predict reinstatement in advance but will know why a reinstatement
     happened post-fact (because the new session returned the same TPGT
     as did an existing no-named session).  So mandate Option B in
     Implementer's guide.

IV. We reject the assertion.  Specify both Option A and Option B in the
     Implementer's guide.  And leave it to implementer's discretion.

I am personally fine with either I or II but not motivated to go to III
because it does not satisfy the "predict in advance" desire even
while it requires enhancements/changes to RFC 3720 (and by extension, to
some existing implementations):
a) allow a No-Name target node (i.e. a node that maps 1-to-1
    with Network Entity)
b) explicitly allow a TPGT numbering space for a No-Name target
c) mandate returning TPGT on no-named discovery sessions.
d) deal with second-order questions such as: shouldn't the
    No-Name target information be returned in SendTargets response?
    how about target port names for No-Name target node? ....

The net is that I see very little ROI in III.

I again see little ROI in IV.
-- 
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
StorageWorks Division
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com

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

---

From: William Studenmund <[email-masked]>
Date: Wed, 24 Aug 2005 14:54:00 -0700

On Aug 24, 2005, at 1:04 PM, Mallikarjun C. wrote:

> I spent sometime studying previous email threads on this topic and 
> gave the topic some thought.  My current thinking and rationale is 
> written below, I hope we'll arrive at a consensus on this topic this 
> time......
>
> discovery Login Request PDU, a special "No-Name" iSCSI Node is 
> implied.  This No-Name iSCSI Node has its own TPGT numbering space - 
> one tag for each physically possible portal group - and thus the TPGT 
> can be inferred. ]
>
>
> Question 1:

Can we get more information on the basis for this desire? I think 
knowing why folks wanted this will help us decide what to do.

> If the answer is no, then the whole discussion is moot (jump down to 

I'd like to throw in a bit of a qualification here.  I see two 
variations to the "not know in advance" idea. There is the variation 
where the initiator thought the new session would reinstate an existing 
one but didn't (due to TPGT information received as part of login) and 
then there's the variation where the initiator thought a new session 
would not reinstate an old one but it did.

I think that not reinstating when the initiator thought it might is 
less severe than reinstating when the initiator thought it shouldn't.

> predict session reinstatement in advance (answer to Question.1).

I think I agree with your analysis. While the non-iSCSI way of 
discovering network entity affiliation from condition 1 could also 
indicate TPGT sense, I feel it'd be fragile.

>     nothing about this topic in the Implementer's guide.

I think I agree with rejecting this assertion, but I would soften it to 
be that the initiator should expect reinstatement but could be told 
after the fact (as part of the initial login response) that 
reinstatement did not happen. Yes, this is the "semi-accept" except 
that the initiator should always expect reinstatement.

As for saying nothing, that would be fine. It would be nice, however, 
if we could relax the text regarding the TargetPortalGroupTag to 
indicate that a target MAY send a TPGT when no TargetName was specified 
by the initiator if the target keeps TPGTs for discovery sessions.

> II. We accept the assertion.  So mandate Option A in Implementer's

I think this would be hard for some implementations. Doable, but hard.

>     Implementer's guide.  And leave it to implementer's discretion.

Note that I think options III and IV are really the same. My thoughts 
include "no TPGT" as a "valid" TPGT for discovery, so option A is a 
special case of option B. :-)

> c) mandate returning TPGT on no-named discovery sessions.

As per above, I think "no TPGT" implicitly is a TPGT for this, so 
existing implementations are in-spec. So I don't think we need to 
_mandate_ this change. I'd like to allow it, but not mandate it.

>    how about target port names for No-Name target node? ....

I agree that kind of question is a bit silly. You aren't supposed to 
keep discovery sessions open, so you shouldn't really care about 
reinstatement on them. You can, but you get what you get.

I'm not sure what I think at this point. While I like option III, 
option I would be fine too. There is something to be said for not 
opening the can of worms.

Take care,

Bill

---

From: "Eddy Quicksall" <[email-masked]>
Date: Mon, 29 Aug 2005 09:00:39 -0400

FYI, I believe Dr Russell is on a one year sabbatical.

Eddy

----- Original Message ----- 
From: "Mallikarjun C." <[email-masked]>
To: "IPS" <[email-masked]>
Sent: Wednesday, August 24, 2005 4:04 PM
Subject: [Ips] Discovery reinstatement

>I spent sometime studying previous email threads on this topic and gave the 
>topic some thought.  My current thinking and rationale is written below, I 
>hope we'll arrive at a consensus on this topic this time......
>
> discovery Login Request PDU, TPGT is meaningless and can't be inferred (or 
> inferred to be invalid).
>
> Yes (based on the plugfest feedback), so let's analyze what this leads us 
> to.  If I got this wrong, feel free to reset me (especially to Bob 
> Russell).
>

---

From: "Robert D. Russell" <[email-masked]>
Date: Mon, 29 Aug 2005 10:47:48 -0400 (EDT)

> FYI, I believe Dr Russell is on a one year sabbatical.
True, and your last e-mail caught me in transit without
reliable e-mail access -- sorry about that.

>> reinstatement in the Implementer's guide, but still open to being persuaded 
>> otherwise.  Sorry it's a long note.
>> 
>> [Options:
>> 
>> This No-Name iSCSI Node has its own TPGT numbering space - one tag for each 
>> physically possible portal group - and thus the TPGT can be inferred. ]
>> 
>> 
>> Question 1:

There was not any reliable plugfest data on this issue.
What we encountered were situations where there was interference
between Normal Sessions and Discovery Sessions (i.e., where a
Normal Session would reinstate a Discovery Session, and vice versa).
That was what was originally discussed on the reflector just about
a year ago, and at that time the issue of multiple simultaneous
Discovery Sessions between the same initiator and target never came
up.  What led to the current discussion was my suggestion of a few months
ago to add to the implementor's guide the resolution of a
non-name target for Discovery sessions, and that brought the realization
that the TPGT issue had never been discussed before and therefore
had not been resolved.  I suggested that the TPGT value be NULL
or empty, because that seemed to be in the spirit of discovery
(as also suggested by Julian), but that was only a suggestion.

My 2-cents worth on the issue is that it is desirable for the
initiator to be able to deterministically know in advance when
a discovery session will be reinstated, because otherwise there
are unexpected surprises that can lead to interoperability issues.
(I believe there have been postings about infinite loops being
triggered.)  Non-determinism also makes it more complex for the initiator 
to deal with, which invariably can cause otherwise
compatible initiator-target pairs to stop interoperating
(the added complexity also hides bugs).

Thus I would be in favor of mandating Option A (your conclusion II below),
as being least problematic and most in the spirit of the original
intentions of the RFC 3720 designers.

If your conclusion I below is accepted, I believe you should at least
say something about it in the implementer's guide, even if only to warn
implementers that there is this whole bag of worms to watch out for.

Thanks,
Bob

---

From: "Mallikarjun C." <[email-masked]>
Date: Mon, 29 Aug 2005 12:33:27 -0700

> a discovery session will be reinstated.....

Thanks for the feedback.  I am personally fine with II (II lags I only 
by a little in my preference scale, that too only if I do not need to 
add any "bag of worms" text in adopting I).

Mallikarjun

Mallikarjun Chadalapaka

Robert D. Russell wrote:
>>> discovery Login Request PDU, TPGT is meaningless and can't be 
>>> inferred (or inferred to be invalid).
>>>
>>> Yes (based on the plugfest feedback), so let's analyze what this 
>>> leads us to.  If I got this wrong, feel free to reset me (especially 
>>> to Bob Russell).
>>>
> triggered.)  Non-determinism also makes it more complex for the 
> initiator to deal with, which invariably can cause otherwise

---

From: William Studenmund <[email-masked]>
Date: Mon, 29 Aug 2005 18:04:48 -0700

On Aug 29, 2005, at 7:47 AM, Robert D. Russell wrote:

>>> A. TPGTs are always Node-scoped.  If Node name isn't specified in 
>>> the discovery Login Request PDU, TPGT is meaningless and can't be 
>>> B. TPGTs are always Node-scoped.  If Node name isn't specified in 
>>> the discovery Login Request PDU, a special "No-Name" iSCSI Node is 
>>> one tag for each physically possible portal group - and thus the 
>>> TPGT can be inferred. ]
>>> Question 1:

I'm confused.

The two proposals, as I understand it, are that we either always 
reinstate, or we sometimes reinstate. Part of my recommendation for the 
latter is that the initiator should ALWAYS EXPECT reinstatement, and 
should be "pleasantly surprised" if it does not happen. Also, part of 
the "sometimes reinstate" option is that the initiator would receive 
information (a TPGT or no TPGT == NUL group) in the first response that 
indicates what happened.

It's like playing Russian Roulette. You (should) always expect a 
bullet, yet be pleasantly surprised if there isn't one in the chamber.

Since the initiator should always be expecting the same thing, 
reinstatement, I do not see how such an option (not reinstating) would 
make life more difficult. The only case I can see is that of an 
initiator tested solely with a target where each portal was in a 
different portal group, thus never experiencing reinstatement. But such 
a target will have difficulties anywhere.

Can someone please explain how sometimes not reinstating when it's 
always expected makes life more difficult?

I agree that if we had initiators expecting no reinstatement and then 
getting confused if/when it happened would lead to these issues. That's 
why I specifically added the "always expect reinstatement" clause. :-)

> implementers that there is this whole bag of worms to watch out for.

Agreed.

For short-lived discovery sessions, even with parallel discovery it is 
possible that multiple sessions to the same box will succeed w/o 
reinstatement (consider the case where an initial login packet is 
dropped and retransmit doesn't kick in until other sessions have 
ended). So the initiator will have to deal with getting the same info 
via different paths anyway. Thus anything that would have happened with 
unexpected reinstatement would happen otherwise.

Take care,

Bill

---

From: "Ken Sandars" <[email-masked]>
Date: Wed, 31 Aug 2005 20:56:56 +0100

Hi Mallikarjun,

I like your approach to this problem. In my mind the answer to question 1 is
a strong yes, however, I do not like the clause about Network Entity.

>From my last posting, I restate: an initiator may not know if two Portals
belong to the same Network Entity. For the purposes of discovery, all it
requires prior to establishing the discovery session is each Portal's TCP
addressing information.

Without a priori knowledge of which portals are in the same Network Entity,
it would be difficult for an initiator to deterministically know if starting
a discovery session to Portal Y is going to reinstate its existing discovery
session on Portal X.

Of the four possibilities you propose, I agree that II is on the path to
predictable behaviour. However, I suggest the decision to reinstate a
Discovery session should be based upon matching the tuple InitiatorName +
ISID + servicing iSCSI Portal. Hence a Network Entity with four Portals may
carry four discovery sessions simultaneously from the one InitiatorName+ISID
pair (one per Portal).

Thanks,
Ken 

Ken Sandars
Adaptec UK

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mallikarjun C.
> Sent: 24 August 2005 21:04
> To: IPS