Re: [Dime] Ben Campbell's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)

Steve Donovan <srdonovan@usdonovans.com> Wed, 04 May 2016 16:36 UTC

Return-Path: <srdonovan@usdonovans.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C8412D10D; Wed, 4 May 2016 09:36:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hV3TAwghXQuC; Wed, 4 May 2016 09:36:10 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6225912DA2F; Wed, 4 May 2016 09:25:39 -0700 (PDT)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:60054 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from <srdonovan@usdonovans.com>) id 1axzcE-000poH-NT; Wed, 04 May 2016 09:25:38 -0700
To: Ben Campbell <ben@nostrum.com>, The IESG <iesg@ietf.org>
References: <20160504023124.8242.52368.idtracker@ietfa.amsl.com>
From: Steve Donovan <srdonovan@usdonovans.com>
Message-ID: <572A227D.1040203@usdonovans.com>
Date: Wed, 04 May 2016 11:25:33 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <20160504023124.8242.52368.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-0.2
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/Y7_CfHLxtdiKDz3IK8p3VQjmPCI>
Cc: draft-ietf-dime-drmp@ietf.org, dime-chairs@ietf.org, dime@ietf.org
Subject: Re: [Dime] Ben Campbell's Discuss on draft-ietf-dime-drmp-05: (with DISCUSS and COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 May 2016 16:36:12 -0000

My comments inline.

Steve

On 5/3/16 9:31 PM, Ben Campbell wrote:
> Ben Campbell has entered the following ballot position for
> draft-ietf-dime-drmp-05: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I have a few concerns that I think need some discussion.
>
> 1) Priority between applications: The fact that agents can apply priority
> for messages from multiple applications without knowledge of those
> applications seems dangerous. Let's say application A is a critical
> infrastructure application, and application B is not. But clients for
> application B might set requests to have a higher priority than do
> clients for application A.  Further, application B could become a DoS
> vector for application A. One potential (and likely half-baked) way to
> mitigate this would be to say that nodes that are not "application aware"
> can only apply priority among messages for the same application.
SRD> This is similar to saying that priority setting across applications 
need to be set in a consistent way.  We might need to define the 
"priority scheme" or some similar concept as sketched out in my response 
to Alissa's DISCUSS.
>
> 2) Priority between clients of the same application: If you have multiple
> clients for the same application, don't they need to use the same
> prioritization strategy? How is this to be managed?
SRD> It is not directly defined.  This is back to the question of 
whether or not the mechanism is constrained to only work in a trusted 
environment.
>
> 3) Out of order requests: The draft explicitly allows agents to re-route
> and even explicitly re-order messages. Is it safe to have a
> non-application aware node change the order of messages?
SRD> This mechanism doesn't change the need for Diameter nodes to handle 
messages arriving out of order.  This exists in any protocol that has 
agents/proxies.
>
> 4) I am nervous about the idea that clients and servers would use a
> generic message priority mechanism to manage the allocation of resources
> that result from a requests and answers. It seems like that should be
> based on application specific rules and information. (Now, if the point
> is that these same AVPs might be used in an application according to
> application specific rules, that might be okay--but then you might run
> into issues where application-agnostic agents don't know the difference.)
SRD> The definition of what different priority levels mean will reflect 
the application specific knowledge.  Agents just route requests and with 
the introduction of DOIC, sometimes throttle them.  The agent doesn't 
need anything but the priority value, as long as the priority values are 
defined consistently across all applications.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> General: I approached this assuming prioritization would matter only in
> overload scenarios. But I gather you envision using this in non-overload
> scenarios? (This interacts with my discuss point about the use of DRMP to
> prioritize resource allocation that result result from successful
> diameter transactions.) Use case 5.3 is a bit worrisome in this context.
SRD> I don't understand the concern.
>
>
> -6, list item 4: Are there really use cases for answer senders to set a
> different priority on the answer than was on the request? That seems to
> add quite a bit of complexity.
SRD> This was an explicit conversation within the working group. I don't 
recall the specific use case off the top of my head, but this was 
changed to the current wording after discussions within the working 
group.  I can go back to the email archive to refresh my memory if 
necessary.
>
> - 6, list item 8: I'm not sure what it means for a client to prioritize
> answers to it's own requests.
SRD> The client could choose to complete the transaction, and initiate 
other dependent actions, based on the priority received in the answer 
message.  It is those dependent actions -- setting up a data channel, 
authorizing call completion, etc -- that would be impacted by the 
priorities received in the answer.
>
> -8,  "Diameter nodes SHOULD
>     include Diameter routing message priority in the DRMP AVP in all
>     Diameter request messages." :
> Does that apply to all nodes that touch a request, or just the request
> originator?
SRD> This statement was meant to apply to the request originator.  The 
statement should be updated.
>
> -- "Diameter nodes MUST use the priority indicated in the DRMP AVP
> carried in the answer message, if it exists."
> The MUST seems odd, since paying attention to the priority in the initial
> request was only SHOULD.
SRD> The wording here is cumbersome.  The full paragraph is as follows:

    When determining the priority to apply to answer messages, Diameter
    nodes MUST use the priority indicated in the DRMP AVP carried in the
    answer message, if it exists.  Otherwise, the Diameter node MUST use
    the priority indicated in the DRMP AVP of the associated request
    message.

This is meant to say that a Diameter node receiving an answer message 
MUST use the priority value in the answer message when processing the 
message.  If there is no DRMP AVP in the answer message then the 
receiving node uses the priority that was in the request message.  I'd 
be happy to re-craft this to be more clear.
>
> -- "Another is to use the Proxy-Info
>        mechanism defined in [RFC6733].":
> That probably needs some elaboration.
SRD> A reference to the document that defines Proxy-Info isn't sufficient?
>
>