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

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

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