[storm] iSCSI - NOP loop avoidance

<david.black@emc.com> Thu, 28 June 2012 15:58 UTC

Return-Path: <david.black@emc.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 CAF8021F85A4 for <storm@ietfa.amsl.com>; Thu, 28 Jun 2012 08:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.384
X-Spam-Level:
X-Spam-Status: No, score=-102.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 IKXU7ciiZs9e for <storm@ietfa.amsl.com>; Thu, 28 Jun 2012 08:58:58 -0700 (PDT)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id BEC2B21F85AA for <storm@ietf.org>; Thu, 28 Jun 2012 08:58:58 -0700 (PDT)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5SFwtoA028127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <storm@ietf.org>; Thu, 28 Jun 2012 11:58:56 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for <storm@ietf.org>; Thu, 28 Jun 2012 11:58:44 -0400
Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.222.70.236]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q5SFwiuZ004969 for <storm@ietf.org>; Thu, 28 Jun 2012 11:58:44 -0400
Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub15.corp.emc.com ([128.222.70.236]) with mapi; Thu, 28 Jun 2012 11:58:44 -0400
From: <david.black@emc.com>
To: <storm@ietf.org>
Date: Thu, 28 Jun 2012 11:58:43 -0400
Thread-Topic: iSCSI - NOP loop avoidance
Thread-Index: Ac1VRuReo0UnniUrQz2rHgxcMSDpKA==
Message-ID: <8D3D17ACE214DC429325B2B98F3AE71208D3A71A@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: [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 15:58:59 -0000

<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
----------------------------------------------------