Re: [storm] MPA Draft - Review

arkady kanevsky <arkady.kanevsky@gmail.com> Mon, 14 March 2011 01:32 UTC

Return-Path: <arkady.kanevsky@gmail.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 37AEE3A6AB9 for <storm@core3.amsl.com>; Sun, 13 Mar 2011 18:32:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 G1FyvLN4uzZ0 for <storm@core3.amsl.com>; Sun, 13 Mar 2011 18:32:21 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id C75113A6AB7 for <storm@ietf.org>; Sun, 13 Mar 2011 18:32:21 -0700 (PDT)
Received: by pwi5 with SMTP id 5so1358899pwi.31 for <storm@ietf.org>; Sun, 13 Mar 2011 18:33:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lj5ujqGdvld2qX95jySzdRaRBXclPAeedVGHQgFxUwQ=; b=nVd63HL5zEFv1ZKSt7Ud1xNyr4X2WhmDxFH6sLbvd42PoBM4hGYE0Mr3WdHPnJ7Jt1 XAS7IpHK9l2QG8KSLMsqvcY1VmMglQq1ByHYBPbCQ5GjxuZpVdy0BbpmyOWZvPlMBnQD lY3ru2iLpkSbN7lUW6ffRZXz5P7LdtfG7m8Mo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YEfxi+WCxFv4NPhnu4K4/PtUgHjeb6nb6Hbq9KaiS+HUQJlotRZsxFv0+shpKJiYvz rtWTtRkdIZP6EsEmGC9Mx8nzXOrIMwpea+BmnWpdr+4jCUT8LTSvartAPH8Gm9cVea7D DX8VAux2Vl1McH5f6VNXvSfibcHy9Sh0DEhvg=
MIME-Version: 1.0
Received: by 10.142.250.5 with SMTP id x5mr9782454wfh.440.1300066423463; Sun, 13 Mar 2011 18:33:43 -0700 (PDT)
Received: by 10.142.239.14 with HTTP; Sun, 13 Mar 2011 18:33:43 -0700 (PDT)
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E03D74C7183@MX14A.corp.emc.com>
References: <AcuiSMs9BaSwGO4cTKyXNsSoFs8erQ==> <7C4DFCE962635144B8FAE8CA11D0BF1E03D74C7183@MX14A.corp.emc.com>
Date: Sun, 13 Mar 2011 21:33:43 -0400
Message-ID: <AANLkTimkFcULbRP=f1q_Z7PaUARY8pS1PAYgM6sdBQQv@mail.gmail.com>
From: arkady kanevsky <arkady.kanevsky@gmail.com>
To: david.black@emc.com, Tom Talpey <tmtalpey@rcn.com>, Caitlin Bestler <cait@asomi.com>
Content-Type: multipart/alternative; boundary=001636ed67825aec08049e674dfb
Cc: storm@ietf.org
Subject: Re: [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: Mon, 14 Mar 2011 01:32:23 -0000

David,
We had addressed the issues you had raised and I had submitted next version
(03).
Thanks,
Arkady

On Wed, Dec 22, 2010 at 9:26 PM, <david.black@emc.com> wrote:

> 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
> ----------------------------------------------------
>
> _______________________________________________
> storm mailing list
> storm@ietf.org
> https://www.ietf.org/mailman/listinfo/storm
>



-- 
Cheers,
Arkady Kanevsky