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

["Mallikarjun C." <cbm@rose.hp.com>]

Julian and Bob,

Sometime ago, in my private email conversations with Julian,
I leaned towards retaining "0" for the reasons Julian suggested.
But as Bob suggests, a value of all-1's or a value of 0 would
be more straightforward than a special case value.  So, I also
recommend removing the "no limit" special value.

Thanks.
-- 
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com



"Robert D. Russell" wrote:
> 
> 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
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >