Re: iscsi : query based login negotiation.

[Santosh Rao <santoshr@cup.hp.com>]

The '0' semantics works fine for me. We just need some mechanism wherein
an initiator can accept values from the target for some keys, without
expressing any limitations of its own on those key values.

Currently, 0 implies no limit for the following numerical keys :
- DataPDULength
- MaxBurstSize
- FirstBurstSize

The following key definitions need to be modified to indicate that 0
implies no limit :
- MaxConnections
- LogoutLoginMaxTime
- MaxOutstandingR2T

Thanks,
Santosh

 

"THALER,PAT (A-Roseville,ex1)" wrote:
> 
> Using 0 to specify no limit or largest possible number is a better solution.
> Overloading query to mean "no limit" during negotiation can create confusion
> between when it is being used for that and when it is just being used to
> check the value at the partner.
> 
> Pat
> 
> -----Original Message-----
> From: Sandeep Joshi [mailto:sandeepj@research.bell-labs.com]
> Sent: Friday, October 05, 2001 9:20 AM
> To: IPS Reflector
> Subject: Re: iscsi : query based login negotiation.
> 
> Another alternative is to let the the initiator send
> "DataPDULength=0".  The target can then select & send
> a lower value it prefers.
> 
> See Appendix D
>   A value of 0 indicates no limit (the largest possible number)
> 
> This would work for DataPDULength, MaxBurst and FirstBurst.
> 
> -Sandeep
> 
> Santosh Rao wrote:
> >
> > Julian,
> >
> > I have another question on the subject of login negotiation, which was
> > brought up earlier in a previous mail. I've enclosed the mail below
> > [with irrelevant portions snipped out.]
> >
> > Could you please clarify if the below described behaviour is possible ?
> >
> > Thanks,
> > Santosh
> >
> > Santosh Rao wrote:
> > >
> > > Julian,
> > >
> > > Another value-add of the "responder picks the negotiation result model"
> > > is that the initiator can use the following "query based" negotiation
> > > model to always use the values the target is capable of offering :
> > >
> > > I -> T : DataPDULength=?
> > > T -> I : DataPDULength=64K
> > >
> > > Both sides agree to use a DataPDULength of 64K.
> >
> > > I suggest that we allow the above "query based model", since this is
> > > more efficient to use when an initiator has no key limitations and would
> > > like to use the value a target can offer. In order to allow the "query
> > > based model", you would need to state in the draft that a key value of
> > > "?" over-rides the default, implying the target offered value would be
> > > the result of the negotiation.
> > >
> > > In particular, the "query based model" is quite useful when an initiator
> > > wishes to function with the target's maximal supported values for keys
> > > like DataPDULength, FirstBurstSize, MaxBurstSize, MaxOutStandingR2T,
> > > LogoutLoginMinTime, LogoutLoginMaxTime, etc without expressing any
> > > limitations on its own key value.
> > >
> > > Comments ?
> > >
> > > Thanks,
> > > Santosh
> >
> > --
> > ##################################
> > Santosh Rao
> > Software Design Engineer,
> > HP-UX iSCSI Driver Team,
> > Hewlett Packard, Cupertino.
> > email : santoshr@cup.hp.com
> > Phone : 408-447-3751
> > ##################################

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################