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

[Tow Wang <Tow_Wang@adaptec.com>]

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