[storm] iSER draft progress!

["Black, David" <[e-mail]>]

Mike,

That new -12 version of the iSER draft looks fine, so I've sent it onward to our AD (Martin) for further review, along with a minor change to the PROTO writeup (new writeup is attached).  I do hope that this third attempt to complete this stage of storm WG technical work on iSER turns out to be the charm :).  Thank you for the quick turn-around on the new draft version.

Many thanks to everyone who's contributed to working through the iSER issues since the start of the year.  Although the delays to the iSER draft have not been ideal, they've occurred for good reasons, as we do need to make sure that the technical content of the draft is actually correct and matches the implementations.

Also - RDMAP draft authors - this is your heads-up that I will get to taking a look at the RDMAP draft in the next week or so ...

Thanks,
--David (storm WG co-chair)

From: Michael Ko [mailto:[e-mail]]
Sent: Sunday, September 16, 2012 1:20 PM
To: Black, David
Cc: [e-mail]
Subject: Re: [storm] Proposed text changes for the connection allocation problem

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]<mailto:[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