Re: iSCSI: enquiry key

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

Bob,

"Robert D. Russell" <rdr@io.iol.unh.edu> wrote on 20-12-2001 12:48:31:

> Julian:
> 
> A few questions:
> 
> 1. Does the value of MaxOutstandingR2T include the implied initial R2T
>    when operating in unsolicited mode (as described in 2.2.5)?
> 
>    I believe the answer is "no", but would suggest a minor rewording
>    in Appendix D item 29 to remove any doubt:
>    "Initiator and target negotiate the maximum number of outstanding R2Ts
>    per task, excluding any implied initial R2T that might be part of that
>    task."
>
OK 
> 
> 2. I believe the upper limit for MaxRecvPDULength should be 2**24-1,
>    not 2**24 as is currently shown in Appendix D item 24.
>    The reason is that the Data Segment Length field in the header is only
>    24 bits, so 2**24-1 is the largest number that can be stored in it
>    (i.e., a PDU with 2**24 bytes of data could never be sent).
>    To be consistent, if the limit for MaxRecvPDULength is changed to be
>    2**24-1, perhaps we should also change the limit for MaxBurstSize and
>    FirstBurstSize to be the same 2**24-1.
>
OK 
> 
> 3. In section 2.2.4 it says: The value "?" with any key has the meaning
>    of enquiry and should be answered with the current value of
>    "NotUnderstood."
> 
> 3a.It is not clear what this means when keys are "one-way".  For example,
>    assume the initiator sends the target "MaxRecvPDULength=?".  Should the
>    target send back the maximum PDU length it (the target) expects to
>    receive from the initiator, or should the target send back the maximum
>    PDU length it (the target) will ever send to the initiator?
>    The same question applies to "FMarker=?" and "RFMarkInt=?" and
>    "SFMarkInt=?".  Regardless of what the answer to this question is,
>    another question immediately arises -- how does one side ask for the
>    other value?
> 
Yes - I will clarify that both values have to sent and state how

> 3b.It is not clear if the usual restrictions to LO, IO, and FFPO
>    should apply to these enquiries.  For example, during a login for a
>    second (third, fourth, ...) connection in a session, can one side
>    send "MaxBurstSize=?" to the other side to obtain the current value
>    for the session, even though MaxBurstSize is an LO parameter and can
>    not be negotiated for the second (third, fourth, ...) connection?
>    Or in another example, can a text request from the initiator include
>    "MaxBurstSize=?" even though MaxBurstSize cannot be negotiated or
>    changed after the Leading Login?
> 
will clarify
>    If the answer to these examples is "yes", then further clarification in
>    the standard is necessary to indicate that the "key=?" can be sent
>    at any time and is not restricted by the LO, IO, and FFPO labels.
> 
>    In the "yes" case, we also need to clarify whether it is possible to
>    send "key=?" enquiries for operational keys during security negotiation,
>    and vice versa.
> 
>    If the answer to these examples is "no", then the value of an enquiry
>    appears to be marginal, and I would suggest that it be eliminated
>    from the spec (when can it be used to any benefit?).
> 
>    My personal opinion is that "key=?" seems fairly useless -- if they are
>    to operate correctly, both sides of a connection really have to know the
>    values of all the keys at all times, and the rules for negotiation make
>    it clear how and when these values change.  The only real "enquiry"
>    situation is when an initiator is attempting to discover targets, and
>    this is handled completely differently by the use of "SendTargets".
>    So when is there a use for either side to send "key=?".  Unless there
>    is a clear example where this is useful, we should eliminate it and thus
>    remove another special case during parameter processing.
> 
I am not sure that we have all the use scenarios to afford removing it
> 
> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774
>