RE: Value of "unlimited". Was Re: iSCSI: current UNH Plugfest

[pat_thaler@agilent.com]

Julo,
 
I am in favor of removing the don't care. Putting the maximum value in
accomplishes "don't care" for a numeric negotiation.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, November 30, 2001 5:26 AM
To: ips@ece.cmu.edu
Subject: Re: Value of "unlimited". Was Re: iSCSI: current UNH Plugfest



Bob, 

It was claimed that a value of 0 - used uniformly independent of the
selection rule (min or max) would be easier to handle. 
I personally don't care - but would like to avoid another raging war on
defaults. 

If you find some other supporters I am ready to remove the don't care
altogether. 

Regards, 
Julo 



	"Robert D. Russell" <rdr@io.iol.unh.edu> 


11/30/2001 01:17 PM 


        
        To:        Julian Satran/Haifa/IBM@IBMIL 
        cc:        ips@ece.cmu.edu 
        Subject:        Re: Value of "unlimited". Was Re: iSCSI: current UNH
Plugfest 

       


Julian:

I would like to request that using the value of 0 as a "don't care"
in numeric negotiations be removed completely.  You said it is there
to "simplify exchanges", but I do not see how it simplifies them
because it makes a special case where none is needed.

If the numerical choice function is "min", then to indicate "don't care"
simply offer the maximum value in the allowed range (which clearly the
offering side must be able to deal with if it really doesn't care).
The responder they replies with any number it wants to choose from the
allowed range, because by definition that will be the "min" value.
When the numerical choice function is "max", the offering side
simply offers the minimum value in the allowed range, etc.

By making 0 a special case, extra code is necessary on the receiving side,
and extra wording is needed in the standard, yet there is no gain in
functionality.  This is why I would like to have it removed -- it is
an unnecessary special case.

Thanks,
Bob Russell


On Fri, 30 Nov 2001, Julian Satran wrote:

> Robert,
>
> Sorry for the confusion.
> The value 0 was on purpose changed from its "unlimited" meaning in mode
> pages to a syntactic "don't care"
> in some negotiations to simplify exchanges where one of the parties does
> not care.
> In that case the "burden" of the decision is upon the responder.
>
>
> Julo
>
>
>
>
> "Robert D. Russell" <rdr@io.iol.unh.edu>
> 11/29/2001 12:30 PM
>
>
>         To:     Julian Satran/Haifa/IBM@IBMIL
>         cc:     ips@ece.cmu.edu
>         Subject:        Re: Value of "unlimited". Was Re: iSCSI: current
UNH Plugfest
>
>
>
> Julian:
>
> If I understand correctly what Tow was asking for, and your response to
> him, this means that the statement:
>
> "A value of 0 MAY be used as a "don't care" offer in negotiations."
>
> should be removed from the description in Appendix D of draft 9 for
> the 6 keys:
>
> MaxRecvPDULength
> MaxBurstSize
> FirstBurstSize
> LogoutLoginMaxTime
> LogoutLoginMinTime
> MaxOutstandingR2T
>
>
> The statement in section 2.2.4 on page 31 should also be removed:
>
> "For numerical negotiations, the value 0 MAY be specified by the
> offering party as a "don't care"/"unlimited" value for parameters
> that explicitly allow it; in this case, the responder may choose any
> legal value for the parameter."
>
>
> Thanks,
>
> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774
>
>
>
> On Thu, 29 Nov 2001, Julian Satran wrote:
>
> > 0 as a stand in for "whatever" is out of version 09.
> > We don't see any need for it. It was originally provide for 
> compatibility
> > with the T10 docs when we had values "residing" in mode pages accessible
> > by SCSI commands.
> >
> > Julo
> >
> >
> >
> >
> > Tow Wang <Tow_Wang@adaptec.com>
> > Sent by: owner-ips@ece.cmu.edu
> > 28-11-01 01:55
> >
> >
> >         To:     "Robert D. Russell" <rdr@io.iol.unh.edu>,
> ips@ece.cmu.edu
> >         cc:
> >         Subject:        Value of "unlimited". Was Re: iSCSI: current UNH
> Plugfest
> >
> >
> >
> > Hi all.
> >
> > I fully agree with the suggestions for issue 4. If we really need to
> > reserve a
> > value to mean "unlimited" or "infinite", could we use a value of all
> bits
> > set to
> > one to indicate this? (Specifically, 0xFFFFFF or 0xFFFFFFFF would be
> great
> > for
> > most 32-bit processors and above.) This would make arithmetic
> comparisons
> > more
> > intuitive, IMHO.
> >
> > "Robert D. Russell" wrote:
> >
> > > Attached are the new issues that arose during the iSCSI plugfest
> > > at UNH on Wednesday 31-Oct-2001.
> > >
> > > (Note: these issues do not take into account any modifications or
> > > clarifications that occured in the standard due to the issues raised
> > > on Monday or Tuesday.)
> > >
> > > 4. Three numeric keys (MaxRecvPDULength, MaxBurstSize, FirstBurstSize)
> > >    now allow: "A value of 0 indicates no limit."
> > >
> > >    Is this useful?  Does it buy anything?
> > >
> > >    The difficulties implementers are having with this are:
> > >
> > >    1) It is a special case.
> > >    2) It causes discontinuous ranges (for example, [0,64..2**24])
> > >    3) It violates the min/max function normally used for the key.
> > >    4) There is always a limit anyway.
> > >
> > >    Consider FirstBurstSize, which can have a value that is described
> > >    as "<0|number-64-2**24>", and for which the minimum of the 2
> numbers
> > >    is selected.
> > >
> > >    I one side offers 0 to mean unlimited, and the other side
> > >    has a limit, it will reply with that limit, say 128 Kbytes.
> > >    Therefore, the result is not min(0, 128K) but rather max(0, 128K).
> > >    The statement in the standard that "the minimum of the 2 numbers is
> > >    selected" is therefore wrong when one of the numbers is 0.
> > >
> > >    Furthermore, when an initiator or target receives an offer for one
> > >    of these keys, it cannot simply check that the offered value is
> > >    legal by testing it against some minimum and maximum.  It must
> first
> > >    check for 0 and then only if that check shows the value is non-zero
> > >    can it do the min/max range check for legality (i.e., 64-2**24).
> > >
> > >    Finally, there is always a limit. If nothing else it is the
> > >    limit imposed by the 24-bit DataSegmentLength field of the PDU
> > >    requesting the transfer.  It is useless to specify a FirstBurstSize
> > >    (or MaxRecvPDULength or MaxBurstSize) any bigger than that, because
> > >    the largest possible DataSegmentLength in any PDU that can use
> > >    this value is 2**24-1.
> > >
> > >    The suggestion is to just eliminate this special case of 0 and
> > require
> > >    that the range 64-to-(2**24-1) be used instead -- it has exactly
> the
> > >    same effect in all cases, it is easier to describe in the standard
> > >    because it avoids all the extra words, and it is easier to code
> > >    because it avoids all the special cases.
> > >
> > >    NOTE: the standard should specify the limit in the ranges for
> > >    MaxRecvPDULength, MaxBurstSize, and FirstBurstSize as 2**24-1
> instead
> > >    of 2**24.  The number 2**24 cannot be represented in the 24-bit
> > >    DataSegmentLength field and therefore can never be used.
> >
> > --
> > Tow Wang
> > Adaptec Software Engineer       Telephone: 408 957 4838
> > Mail stop 46                               800 869 8883 x4838
> > 691 South Milpitas Boulevard    Fax:       530 686 8023
> > Milpitas, California 95035      E-mail:    Tow_Wang@adaptec.com
> >
> >
> >
> >
> >
>
>
>
>