Re:iSCSI: re-negotiating the same key

["Mallikarjun C." <cbm@rose.hp.com>]

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].
> > >