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

["Julian Satran" <Julian_Satran@il.ibm.com>]

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