Re: [storm] iSCSI - NOP loop avoidance

[Julian Satran <[e-mail]>]

the text sounds fine although the added text to 11.18.1 is mostly decorative.

Sent from my iPad

On 28 ביונ 2012, at 18:58, <[e-mail]> wrote:

> <WG chair hat on>
> 
> This is the first of a number of emails to come on relatively small
> technical issues that have been discovered in reviews of the consolidated
> iSCSI draft.  Resolution of all of these issues should not require changes
> to implementations, but they do require the WG's attention.
> 
> <WG chair hat off>
> <Draft author hat on>
> 
> The specific issue for this email is NOP-loop avoidance, specifically
> tightening up the language in the draft that tells implementers what to
> do to avoid a lengthy sequence of NOP-In and NOP-Out PDUs sent in
> response to each other.  This is not believed to be a problem in practice
> because NOP-* PDUs are pure overhead, and there are no requirements to
> respond in a fashion that would create such a lengthy sequence, so
> implementations are likely to not respond in order to spend those resources
> on something more useful.  Nonetheless, the language in the draft on
> this subject is weak, and in particular contains no requirement (MUST/
> SHOULD/MAY) to not respond in a fashion that would create a lengthy
> sequence.  Yes, this is a corner case ;-).
> 
> The Initiator Task Tag (ITT) and Target Transfer Tag (TTT) are crucial
> to understanding what's going on here.  The NOP-In and NOP-Out PDUs
> (see 11.18 and 11.19) use these tags to support "ping" round trip
> functionality:
> 
> 1) The originator of the "ping" sets its tag to a valid value,
>    and sets the other tag to an invalid value in the first
>    NOP-* PDU.
> 2) The responder recognizes the valid value of the originator's
>    tag as a response request, and preserves those values in the
>    response NOP-* PDU.
> 3) The originator is expected not to continue because the responder's
>    tag is invalid in that second PDU.
> 
> There's one additional twist.  A 3-way "ping" is allowed when the
> Target is the originator - at step 2) above, the Initiator (but
> not the Target) is allowed to use valid values for both tags, in
> which case the target will respond with a NOP-In PDU that uses
> an invalid TTT value, and the "expected not to continue" in 3)
> applies when the initiator receives that PDU.
> 
> Here are the proposed text changes:
> 
> -----------------------------
> 
> 11.18. NOP-Out
> 
> Existing text:
> 
>  Upon receipt of a NOP-In with the Target Transfer Tag set to a
>  valid value (not the reserved 0xffffffff), the initiator MUST
>  respond with a NOP-Out. In this case, the NOP-Out Target Transfer
>  Tag MUST contain a copy of the NOP-In Target Transfer Tag.
> 
> Add the following sentence to the end of that paragraph:
> 
>  The initiator SHOULD NOT send a NOP-Out in response
>  to any other received NOP-In in order to avoid lengthy
>  sequences of NOP-In and NOP-Out PDUs sent in response to each other.
> 
> 11.19. NOP-In
> 
> Existing text:
> 
>   When a target receives the NOP-Out with a valid Initiator Task Tag
>   (not the reserved value 0xffffffff), it MUST respond with a NOP-In
>   with the same Initiator Task Tag that was provided in the NOP-Out
>   request. It MUST also duplicate up to the first
>   MaxRecvDataSegmentLength bytes of the initiator provided Ping
>   Data. For such a response, the Target Transfer Tag MUST be
>   0xffffffff.
> 
> Add the following sentence to the end of that paragraph:
> 
>  The target SHOULD NOT send a NOP-In in response
>  to any other received NOP-Out in order to avoid lengthy
>  sequences of NOP-In and NOP-Out PDUs sent in response to each other.
> 
> 11.19.1. Target Transfer Tag
> 
> Change "is set to" to "MUST be set to" in the following two sentences:
> 
>   If the target is responding to a NOP-Out, this is set to the
>   reserved value 0xffffffff.
> 
>   If the target is sending a NOP-In as a Ping (intending to receive
>   a corresponding NOP-Out), this field is set to a valid value (not
>   the reserved 0xffffffff).
> 
> -----------------------------
> 
> Please comment - as noted above, this should have no impact on
> existing implementations, but does tighten up and explicitly state
> what was an implicit requirement.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
> 
> 
> _______________________________________________
> storm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/storm