[storm] MPA Draft - Review

<david.black@emc.com> Thu, 23 December 2010 02:24 UTC

Return-Path: <david.black@emc.com>
X-Original-To: storm@core3.amsl.com
Delivered-To: storm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D741E3A6AA6 for <storm@core3.amsl.com>; Wed, 22 Dec 2010 18:24:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQ4wiu3pBj7j for <storm@core3.amsl.com>; Wed, 22 Dec 2010 18:24:48 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id AFBDC3A6AA3 for <storm@ietf.org>; Wed, 22 Dec 2010 18:24:45 -0800 (PST)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oBN2Qi78028399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <storm@ietf.org>; Wed, 22 Dec 2010 21:26:44 -0500
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for <storm@ietf.org>; Wed, 22 Dec 2010 21:26:36 -0500
Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oBN2QP2c013672 for <storm@ietf.org>; Wed, 22 Dec 2010 21:26:26 -0500
Received: from mx14a.corp.emc.com ([169.254.1.169]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Wed, 22 Dec 2010 21:26:16 -0500
From: <david.black@emc.com>
To: <storm@ietf.org>
Date: Wed, 22 Dec 2010 21:26:24 -0500
Thread-Topic: MPA Draft - Review
Thread-Index: AcuiSMs9BaSwGO4cTKyXNsSoFs8erQ==
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03D74C7183@MX14A.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] MPA Draft - Review
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 23 Dec 2010 02:24:50 -0000

WG Last Call on this draft has run its course:

                 Enhanced RDMA Connection Establishment
                  draft-ietf-storm-mpa-peer-connect-02

I've done my review as a WG chair (and the person who will be shepherding this draft to the ADs and IESG):

- This draft is on the right track, but has open issues.
- Another version of the draft will be needed.

Also, it would be greatly appreciated if a few people other than the authors could take a look at this draft.  We have a very good author team on this draft, whose expertise is beyond doubt, but more eyes on this draft would help.

[1] My primary concern is that Section 9 on interoperability is inadequate:

   An initiator SHOULD NOT use the Enhanced DDP Connection Establishment
   formats or function codes when no enhanced functionality is desired.

   A responder SHOULD continue to accept the unenhanced connection
   requests.

The good news is that the first sentence is ok.
The bad news is that the second sentence has significant problems:
	- It uses SHOULD instead of MUST.
	- It doesn't lay out behavior for initiator and responder
		Revision mixes.
IETF interoperability requirements are usually expressed with MUST, including backwards compatibility.  If interop with unenhanced implementations is only a SHOULD, that will need a convincing explanation.

There are 3 Initiator/Responder cases that need attention (New/Old, Old/New and New/New).  I think they lead to roughly the following:

New/Old:
- Explain error or failure that the New Initiator will see because the Old responder
	doesn't support Revision 2 of the MPA protocol.
- Explain what the Initiator does when it sees that error or failure.  The
	easiest approach is to always retry with Revision 1, but that won't work
	if the Initiator has to send an RTR (that's the "convincing explanation"
	for why backwards compatibility is not always possible).  The result
	might be two requirements:
	- If the Initiator has data to send, it MUST retry with Revision 1.
	- If the Initiator has no data to send, and hence has to send an RTR,
		the connection setup fails, the TCP connection closes and that
		failure MUST to be reported to the application.

Old/New:
- If a responder receives a Revision 1 message, it MUST respond with a Revision 1 message.

New/New:
- If a responder receives a Revision 2 message, it MUST respond with a Revision 2 message.

I found a few other concerns:

[B]In Section 7, we need to get the listing of all the SCTP function codes into one place.  Either repeat the definitions of codes 1-4 from RFC 5043, or create an IANA registry in Section 10 and list all 7 codes as its initial contents.

[C] In Section 8, what happens if the responder sends an IRD or ORD value that's different from the corresponding initiator value?  Is the responder allowed to increase the value that was sent?  An important case to cover is that the initiator sends a valid value (e.g., 0x2000) but the responder returns the 0x3FFF value indicating that negotiation is not supported.  Also, what is the behavior of an IRD or ORD that is set to 0x0000?

[D] In contrast, the Section 8 discussion of Control Flag functionality is in better shape.  It would be helpful to add a sentence or two indicating when the RTR occurs (Request ->, <- Reply, RTR ->), even though that is discussed earlier in the draft.  Also, it's necessary to state whether negotiation of RTR functionality commits the Initiator to using an RTR (e.g., suppose the initiator negotiates control flags to allow an RTR and instead sends an FULPDU with payload data after receiving the Reply - is that ok or is it an error?).

[E] Nit: In the definition of Control Flag A: ULPDU -> FULPDU

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