RE: iSCSI: re-negotiating the same key

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

Similar to the key re-negotiation issue, let me comment on allowing the
behavior that an initiator may change it's T bit setting from 1 back to 0
within a login phase.

I don't see the need to specify that the initiator may decide to recind it's
offering of the T bit based on a target response.  The logic I've heard
cited refers to "something that might be required by vendor unique keys".
You can't design a protocol for all possible theoretical behavior of vendor
unique keys.  We must design for the behavior that is logical for the keys
which are currently specified, and vendor unique keys must adhere to that
behavior.  

What is the need *viewing the current set of keys* for an initiator to
change it's T bit setting from 1 back to 0 within a login phase?

Marjorie 

> -----Original Message-----
> From: Mallikarjun C. [mailto:cbm@rose.hp.com]
> Sent: Monday, October 15, 2001 5:40 PM
> To: ips
> Subject: Re:iSCSI: re-negotiating the same key 
> 
> 
> 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
> Networked Storage Architecture
> Network Storage Solutions Organization
> MS 5668	Hewlett-Packard, Roseville.
> cbm@rose.hp.com
> 
> 
> Santosh Rao wrote:
> > 
> > Mallikarjun,
> > 
> > Thanks for attempting to drive this forward from its 
> current deadlocked
> > position ! My comments inline.
> > 
> > Thanks,
> > Santosh
> > 
> > "Mallikarjun C." wrote:
> > >
> > > 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?)
> > 
> > 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.
> > 
> > >         2)Can keys be renegotiated to different values
> > >           (after they were negotiated once) in the same
> > >           negotiation sequence?
> > 
> > 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.)
> > 
> > >
> > > 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.
> > 
> > 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
> > > 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.
> > 
> > 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.
> > 
> > -------------------------------------------------------------------
> > 
> > > Santosh Rao wrote:
> > > >
> > > > Julian Satran wrote:
> > > > >
> > > > > 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.
> > > >
> > > > 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
> > > > > change login behavior for different versions of the 
> protocol that may have
> > > > > 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
> > > > > 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.
> > > >
> > > > 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.
> > > >
> > > > >
> > > > > 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.
> > > >
> > > > 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
> > > >
> > > > >
> > > > > 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
> > > >
> > > > 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].
> > > >
>