Re: iSCSI - negotiating against defaults/renegotiation the same key

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

Julian,

Can you clarify what you mean by "self contained negotiations" ? Further
comments inline.

Thanks,
Santosh

Julian Satran wrote:
> 
> Dear colleagues,
> 
> I think that my previous proposal about negotiating against defaults is
> flawed.
> I was based on the simple-minded assumption that after the initiator has
> said all he had to say (as evidenced by the T=1) the target may assume that
> the values the target puts forward are against default. I even prepared a
> text in
> 5.3 that read:
> 
>    When the initiator issues a login request with the T bit set to 1 the
>    target MUST assume that this request includes also an "imaginary
>    content".  The "imaginary content" consists of key=value pairs including
>    all the operational keys that have a default value and where not sent
>    yet by the initiator during the operational parameter negotiation. The
>    values in the "imaginary content" are the key default values.  This
>    enables an initiator to avoid sending all the defaults while the target
>    may negotiate as if they where sent.
> 
>  But that was wrong. Here is a simple example:
> 
>  A simple initiator may issue a first login entering the operational
>  negotiation and having T=1 and nothing beyond the 2 names:
> 
>  I->T Iname... Tname
> 
>  This means only that he does not care about things like MaxBurst and is
>  content with defaults.
> 
>  The target (in my proposal prompted by Santosh's request) can't do
>  anything but lower the value while under our simple rule of self contained
>  negotiations he could ask for a burst increase and the negotiation could
>  have proceeded.

If the initiator did'nt have any limitation on FirstBurstSize &
MaxBurstSize, it should be sending 0 (no limit) and not 64K or 128K.
Sending a finite value implies the initiator has a specific limit on the
amount it can handle. 

While on this subject, I suggest that the default value of MaxBurstSize
be 0, since the initiator does not usually care about or have a limit on
this field. The field is more a limitation of the target's ability and
using 0 allows the target to send back the maximum it can support as the
result of the negotiation.



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