Re: [storm] iSCSI - NOP loop avoidance

Julian Satran <julians@infinidat.com> Thu, 28 June 2012 17:59 UTC

Return-Path: <julians@infinidat.com>
X-Original-To: storm@ietfa.amsl.com
Delivered-To: storm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FCF21F85AF for <storm@ietfa.amsl.com>; Thu, 28 Jun 2012 10:59:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level:
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVK4G7UFUjQZ for <storm@ietfa.amsl.com>; Thu, 28 Jun 2012 10:59:37 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id CE0CF21F85D8 for <storm@ietf.org>; Thu, 28 Jun 2012 10:59:36 -0700 (PDT)
Received: by wibhm11 with SMTP id hm11so285902wib.13 for <storm@ietf.org>; Thu, 28 Jun 2012 10:59:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=DkA+UrTlnUhMm05BcUwuik/EbNCLEKOUdj5im3G5Sr4=; b=EZAQ7SaFzqVAvjG1MwW3Fg3Q7IdhHko30mxJyRmMD9yhyIuTIbwJ6I92YqoU3WlMtG q5Vp7mGNONwrTMmcprmwsjBlpwboL+N5V+8UgZE2cNxNGLmcZPzANlY5eqoJSJU5cx6N 0OOVdnyyiMyj+BWOL1WXye3fk97onGsrnaHbdFFfiFjKDqkUVbEe3WTknoK4LmZiQGK5 WTK7+3upSrYcr9ivpm71OnrgPoijw0VWQPRHrwMIK+4+mBAX7t20c46n7+b77/p8US7i ygKghWVuiWoZMVRSDMLduYoKD7O/aycIb2m2kYwlGJFZTX1ZSHxAG72opa5QjYi4O/Dx aqMA==
Received: by 10.216.143.105 with SMTP id k83mr1509741wej.99.1340906375448; Thu, 28 Jun 2012 10:59:35 -0700 (PDT)
Received: from [192.168.1.4] ([109.160.140.196]) by mx.google.com with ESMTPS id cl8sm1370159wib.10.2012.06.28.10.59.32 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jun 2012 10:59:34 -0700 (PDT)
References: <8D3D17ACE214DC429325B2B98F3AE71208D3A71A@MX15A.corp.emc.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71208D3A71A@MX15A.corp.emc.com>
Mime-Version: 1.0 (1.0)
Content-Type: text/plain; charset=utf-8
Message-Id: <89361195-CDC2-415B-AB70-A8DAF1637AFB@infinidat.com>
Content-Transfer-Encoding: quoted-printable
X-Mailer: iPad Mail (9B206)
From: Julian Satran <julians@infinidat.com>
Date: Thu, 28 Jun 2012 20:59:31 +0300
To: "<david.black@emc.com>" <david.black@emc.com>
X-Gm-Message-State: ALoCoQm3Y7cR1ot18ndXf+Zl0IDXIs00avhEET+gotCoyFqrke4JetGtvqTKB6rlhy4J7xM+3+7G
X-Mailman-Approved-At: Fri, 29 Jun 2012 08:45:13 -0700
Cc: "<storm@ietf.org>" <storm@ietf.org>
Subject: Re: [storm] iSCSI - NOP loop avoidance
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2012 18:09:15 -0000

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, <david.black@emc.com> 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
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> david.black@emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
> 
> _______________________________________________
> storm mailing list
> storm@ietf.org
> https://www.ietf.org/mailman/listinfo/storm