Re: [storm] Proposed text changes for the connection allocation problem

[Michael Ko <[e-mail]>]

David,

I have submiited a new version of the iSER draft incorporating all the
latest changes so far, including your recommendations below.  I have also
reword item #7 in the summary of changes to reflect the new use of the
iSERHelloRequired key.

Mike

On Fri, Sep 14, 2012 at 5:25 PM, Black, David <[e-mail]> wrote:

> Mike,****
>
> ** **
>
> I apologize for the delay in getting to this.  I think your latest text is
> close to what’s****
>
> needed, but I want to rewrite the latter part of your second paragraph for
> clarity and to****
>
> remove a “MUST” that appears easy to misinterpret (IMHO):****
>
> ** **
>
> OLD****
>
>    To prevent the potential problem caused by the target sending the
> number of****
>
>    unexpected iSCSI control-type PDUs as determined by the
> MaxOustandingUnexpectedPDUs****
>
>    key allowed in the FullFeaturePhase when "late" connection allocation
> is practised,****
>
>    the iSER Hello exchanges MUST be used.  This allows the initiator to
> allocate the****
>
>    connection resources before sending the iSER Hello Messages.  The
> iSERHelloRequired****
>
>    key is used by the initiator to determine if it is dealing with a
> target that****
>
>    supports the iSER Hello exchanges.****
>
> NEW
>    An initiator that employs “late” connection allocation may encounter
> problems (e.g.,****
>
>    RCaP connection closure) with a target that sends unexpected iSCSI PDUs
> immediately****
>
>    upon transitioning to Full Feature Phase, as allowed by the negotiated
> value of the****
>
>    the MaxOustandingUnexpectedPDUs key.  The only way to prevent this
> situation in ****
>
>    full generality is to use iSER Hello Messages, as they enable the
> initiator to allocate****
>
>    its connection resources before sending its iSER Hello Message.  The
> iSERHelloRequired****
>
>    key is used by the initiator to determine if it is dealing with a
> target that****
>
>    supports the iSER Hello exchanges.  Fortunately, known iSER target
> implementations****
>
>    do not take full advantage of the number of allowed unexpected PDUs
> immediately upon****
>
>    transition into full feature phase, enabling an initiator workaround
> that involves****
>
>    a smaller quantity of connection resources prior to full-feature phase,
> as explained****
>
>    further below.****
>
> END****
>
> ** **
>
> Would you please go ahead and submit a revised version of the draft with
> the text changes****
>
> that we’ve agreed to.  I’ll want to review the changes one more time in
> the context of an****
>
> entire draft before (finally) sending it to our AD with a request to
> publish it as an RFC.****
>
> ** **
>
> Thank you for your patience with this.****
>
> ** **
>
> Thanks,
> --David****
>