Subject: Re: [Fwd: iSCSI - revised 2.2.4]

From: "Julian Satran" <[email-masked]>
Date: Sun, 14 Oct 2001 02:17:38 +0300

Santosh,

The reason I am hesitant on accepting this change proposal as is that it
might makes the negotiation very much state dependent and different for
keys that have a default and keys that don't have one.  In addition it may
change login behavior for different versions of the protocol that may have
different defaults.   I admit that it has appeal for the login (where the
defaults are relevant) by shortening some negotiations.

However the issues it raises are multiple. Assume that you have the
following sequence:

I->T key1=x
T->I key1=z,key2=a
I->T key2=b
....

Observe that the initiator designer was very conservative and probably
intended to negotiate the keys one at a time
while the target is aggressive and wants to set everything as soon as
possible.

With the defaults rule the results are harder to define.

With the rules we have now the results are hardly dependent on sequence.

Add to this that with the new rules about PDULength exchanges are hardly
"self contained" - i.e. key=value pairs can span sequences (that was
another reasons I did not like this but framing at high speeds has
precedence!).

However we might perhaps want to consider the following loose rule for
defaults in the context of operational parameter negotiation at login only
(leaving the negotiation rules as they are):

If the initiator issues a login request with the F bit set to 1 is assumed
to have an imaginary content including all the operational keys that have a
default value and where not sent yet by the initiator during login and
their values set to the default value.

Comments?

Julo

PS - and a procedural thing - nagging me repeatedly on a subject is
annoying and quoting the number of agreements before attempting different
scenarios is even more so

                    Santosh Rao                                                               
                    <santoshr@cup.       To:     IPS Reflector <[email-masked]>              
                    hp.com>              cc:                                                  
                    Sent by:             Subject:     [Fwd: iSCSI - revised 2.2.4]            
                    owner-ips@ece.                                                            
                    cmu.edu                                                                   

                    11-10-01 01:36                                                            
                    Please respond                                                            
                    to Santosh Rao                                                            

Julian,

What is the resolution on this issue ?

- Santosh

Santosh Rao wrote:
>
> Julian,
>
> I apologize upfront for being so persistent on this.
>
> However, it would really help if you could give some clear example of a
> scenario as to why the initiator cannot be considered the originator of
> a negotiation, when it offers a key value implicitly, through the use of
> a default.
>
> Several people on this list (Paul Konning, Sanjeev, Deva, myself, and
> perhaps others, that I cannot recall at the moment) have asked that the
> spec must not differentiate login behaviour when the initiator offers a
> key explicitly vs. when it offers a key implicitly thru the use of the
> default.
>
> Please help us understand the need for iscsi to distingush the login
> behaviour in the above case. [through some tangible scenarios and
> examples].
>
> Thanks,
> Santosh
>
> > "Sanjeev Bhagat (TRIPACE/Zoetermeer)" wrote:
> >
> > Julian,
> >
> > I would also request an explicit definition of offering party and
> > responding party. The current text still leaves ambiguity when target
> > sends a key in response to implicit default key of the Intiator. In
> > this case who is the offering party and who is the responding party
> >
> > Sanjeev
> >
> >      -----Original Message-----
> >      From: Julian Satran [mailto:[email-masked]]
> >      Sent: Friday, October 05, 2001 2:06 PM
> >      To: [email-masked]
> >      Subject: iSCSI - revised 2.2.4
> >
> >      Here is a revised (complete) part 2.2.4 based on recent
> >      agreed changes:
> >
> >      1.1.1        Text Mode Negotiation
> >
> >      During login and thereafter some session or connection
> >      parameters are negotiated through an exchange of textual
> >      information.
> >
> >      All negotiations are stateless - i.e. the result MUST be
> >      based only on newly exchanged values.
> >
> >      The general format of text negotiation is:
> >
> >      Originator-> <key>=<valuex>
> >      Responder-> <key>=<valuey>|reject|NotUnderstood
> >
> >      The value can be a number, a single literal constant a
> >      Boolean value (yes or no) or a list of comma separated
> >      literal constant values.
> >
> >      In literal list negotiation, the originator sends for each
> >      key a list of options (literal constants which may include
> >      "none") in its order of preference.
> >
> >      The responding party answers with the first value from the
> >      list it supports and is allowed to use for the specific
> >      originator.
> >
> >      The constant "none" MUST always be used to indicate a
> >      missing function. However, none is a valid selection only if
> >      it is explicitly offered.
> >
> >      If a target is not supporting, or not allowed to use with a
> >      specific originator, any of the offered options, it may use
> >      the constant "reject".  The constants "none" and "reject"
> >      are reserved and must be used only as described here.  Any
> >      key not understood is answered with "NotUnderstood".
> >
> >      For numerical and single literal negotiations, the
> >      responding party MUST respond with the required key and the
> >      value it selects, based on the selection rule specific to
> >      the key, becomes the negotiation result.  Selection of a
> >      value not admissible under the selection rules is considered
> >      a protocol error and handled accordingly.
> >
> >      For Boolean negotiations (keys taking the values yes or no),
> >      the responding party MUST respond with the required key and
> >      the result of the negotiation when the received value does
> >      not determine that result by itself.  The last value
> >      transmitted becomes the negotiation result.  The rules for
> >      selecting the value to respond with are expressed as Boolean
> >      functions of the value received and the value that the
> >      responding party would select in the absence of knowledge of
> >      the received value.
> >
> >      Specifically, the two cases in which responses are OPTIONAL
> >      are:
> >
> >      - The Boolean function is "AND" and the value "no" is
> >      received. The outcome of the negotiation is "no".
> >      - The Boolean function is "OR" and the value "yes" is
> >      received. The outcome of the negotiation is "yes".
> >
> >      Responses are REQUIRED in all other cases, and the value
> >      chosen and sent by the responder becomes the outcome of the
> >      negotiation.
> >
> >      The value "?" with any key has the meaning of enquiry and
> >      should be answered with the current value or
> >      "NotUnderstood".
> >
> >      The target may offer key=value pairs of its own. Target
> >      requests are not limited to matching key=value pairs as
> >      offered by the initiator.  However, only the initiator can
> >      initiate the negotiation start (through the first Text
> >      request) and completion (by setting to 1 and keeping to 1
> >      the F bit in a Text request).
> >
> >      Comments ?
> >
> >      Julo
>
> --
> ##################################
> Santosh Rao
> Software Design Engineer,
> HP-UX iSCSI Driver Team,
> Hewlett Packard, Cupertino.
> email : [email-masked]
> Phone : 408-447-3751
> ##################################

--
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : [email-masked]
Phone : 408-447-3751
##################################

---

From: Santosh Rao <[email-masked]>
Date: Mon, 15 Oct 2001 10:13:37 -0700

Julian Satran wrote:
> keys that have a default and keys that don't have one. 

I don't see why. An initiator that receives a login response needs to
know whether to respond to a received key anyway. It does this by some
mechanism like maintaining a list of keys that it sent in its login
command. All that is required is that the initiator include those
operational keys that it sent as defaults in this list. (it needs to do
this anyway, since usage of defaults implies the initiator is offering
those key values.)

Also, when the target responds to a default offering, it is actually
sending back the result of the negotiation. What benefit exists in
having the initiator again echo this value back to the target in a
redundant round-trip ?

> In addition it may
> different defaults. 

Again, I don't see why. The default values accepted by both sides are
the defaults of the "version active" returned in the login response.

>  I admit that it has appeal for the login (where the

I don't understand how the above scenario is correct. If key2 was an
operational parameter, it already has a default defined for it, and the
initiator cannot negotiate it one at a time, since it has already made
the offer (of the default) by not sending the key explicitly.

In any case, the initiator can always re-negotiate a key by re-sending
the key again. I don't understand how the above example justifies the
need for your current model.

> their values set to the default value.

Julian, the login rules are already complex enough. Why do we need to
special case them further and increase the complexity ? I think login
behaviour is quite simple to understand/follow when the initiator is
considered as the originator of a key if it uses default values for that
key. 

Thanks,
Santosh

> scenarios is even more so

It is unfortunate that you consider my polite requests to attempt to
resolve an open issue as nagging. I don't know how much more polite I
could possibly get. [and I am trying to discuss specific scenarios to
understand the issues you have with this].

---

From: "Mallikarjun C." <[email-masked]>
Date: Mon, 15 Oct 2001 12:34:07 -0700

Julian and Santosh,

It appears to me that there are a couple of questions 
to address, to arrive at a resolution to this change 
request -

	1)Should all operational keys be sent in one
          text command PDU?  (Can they, given that 
          the max PDU size may be a constraint?  Or,
          did the constraint go away with the recent
          set of changes that allow one key=value to
          span multiple PDUs?)
        2)Can keys be renegotiated to different values 
          (after they were negotiated once) in the same 
          negotiation sequence?

If I understood Santosh right, he is implicitly assuming
"yes" to (1) above - so anything that the initiator 
does not offer tantamounts to an explicit default.  If
that's the case, I agree with this view.  [ Julian, please
comment how the new key-spanning is differentiated from 
the multi-command sequence in the PDU header. ]

If the answer to (2) above "yes" (which Santosh thinks
is the case, and suggests as the answer to Julian's 
scenario), I would first of all like to understand the
practical usage of it.  As a first reaction, it appears
to me to open the door for endless exchanges.  But there
may be other safeguards in the draft that I haven't 
closely looked at.

Thanks.
-- 
Mallikarjun 

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
[email-masked]

---

From: Santosh Rao <[email-masked]>
Date: Mon, 15 Oct 2001 15:11:50 -0700

Mallikarjun,

Thanks for attempting to drive this forward from its current deadlocked
position ! My comments inline.

Thanks,
Santosh

>           set of changes that allow one key=value to

The constraints of max receive pdu length are known only after login
negotiation of that key. 

Hence, there must be a definition of a minimum value for the
MaxRecvPDULength and implementations MUST support a minimum buffer size
of at least that value. Similar precedents exist in other protocols that
negotiate a MTU. (ex : an FC frame cannot be less than 256 bytes in
size.).

Given that such a minimum definition is required, I would then suggest
that this minimum be capable of containing all of the operational keys
with some extra room.

The alternative would be to require that operational parameter
negotiation be split into multiple rounds with the first round only
negotiating the recv pdu length.

I prefer the former method due to its simplicity.

>           (after they were negotiated once) in the same

There's nothing in the draft that prevents this. (I seem to remember
seeing text that allowed initiators to do this, but I may be mistaken
with this.)

> does not offer tantamounts to an explicit default.

I believe this has been the working assumption so far ! If this is not a
correct assumption, I don't see how the concept of defaults can work.
How does a target know whether the initiator offered the default or not
?

>  If
> practical usage of it.

I see nothing in the draft that prohibits an initiator from
re-negotiating a key once it obtained the result. Something along the
following lines is a possibility :

i -> t : InitialR2T=yes
	 FirstBurstSize=16K

t -> i : InitialR2T=yes
	 FirstBurstSize=512

i -> t : InitialR2T=no		(initiator cannot function with a FirstBurstSize
of 512 bytes, and so, decides to turn off un-solicited data.)

>  As a first reaction, it appears
> to me to open the door for endless exchanges. 

An initiator decides when login operational negotiation is initiated and
terminated. That said, however, if you've a buggy implementation,
nothing can safeguard login from endless exchanges with the initiator
never performing a stage transition to FFP.

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

---

From: "Mallikarjun C." <[email-masked]>
Date: Mon, 15 Oct 2001 17:40:26 -0700

Julian,

Let me make one comment on renegotiating the
same key multiple times within a negotiation
sequence.

It just bothers me to  to architect a mechanism into 
the protocol that legally requires the other party
to respond even on negotiated keys any number of times.
Santosh outlined a possibility below, but that does
not seem to create a hard requirement to me (a 
reordering of negotiation should do).  iSCSI does 
not necessarily have to cater to all possibilities 
- in fact, ruling out some should simplify things. 

Could you/anyone please comment if you see a 
strong requirement for such a feature?  If you 
think it's already not allowed, could we make 
that explicit? 

Regards.
-- 
Mallikarjun 

Mallikarjun Chadalapaka