From nobody Thu Jul 3 12:31:30 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA451B2B78; Thu, 3 Jul 2014 12:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 maskwMQDlh8a; Thu, 3 Jul 2014 12:31:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C08991B2B61; Thu, 3 Jul 2014 12:31:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> Date: Thu, 03 Jul 2014 12:31:24 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5CwngWTB-s2zqpd3Q4-fxovinII Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 19:31:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Overload Indication Conveyance Authors : Jouni Korhonen Steve Donovan Ben Campbell Lionel Morand Filename : draft-ietf-dime-ovli-03.txt Pages : 48 Date : 2014-07-03 Abstract: This specification documents a Diameter Overload Control (DOC) base solution and the dissemination of the overload report information. Requirements The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-ovli-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 4 14:58:56 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933881A0085; Fri, 4 Jul 2014 14:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 BJh_cuLx0rVm; Fri, 4 Jul 2014 14:58:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 797C61A00DB; Fri, 4 Jul 2014 14:58:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704215850.27210.11236.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 14:58:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/BPxzfmeGsIg3Jnu2p3fe8VkTaIY Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-group-signaling-04.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 21:58:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Group Signaling Authors : Mark Jones Marco Liebsch Lionel Morand Filename : draft-ietf-dime-group-signaling-04.txt Pages : 22 Date : 2014-07-04 Abstract: In large network deployments, a single Diameter peer can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter peers to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter peer using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-group-signaling-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-group-signaling-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 5 12:42:14 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944241B27F2 for ; Sat, 5 Jul 2014 12:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.279 X-Spam-Level: X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_NEUTRAL=0.779] autolearn=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 Og9qhfHtXVIF for ; Sat, 5 Jul 2014 12:42:10 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 CB8881B27F0 for ; Sat, 5 Jul 2014 12:42:10 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64470 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X3VqW-0004e8-KS for dime@ietf.org; Sat, 05 Jul 2014 12:42:09 -0700 Message-ID: <53B8550C.4050206@usdonovans.com> Date: Sat, 05 Jul 2014 14:42:04 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> In-Reply-To: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/H_bku_1Z-9FNVFjBvuitjsWBy7I Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 19:42:11 -0000 All, This version of the DOIC draft is a restructuring of previously agreed to content. The master plan for the restructuring is in Appendix C. This outlines where material from -02 was moved in -03. For those interested, the work was done in steps, with a snapshot for each step available here: https://github.com/jounikor/draft-docdt-dime-ovli Each step has the name draft-ietf-dime-ovli-03-nn-text.txt where nn indicates the subversion and "text" indicates the focus for that subversion. The next step will be to resolve open issues already identified and those yet those yet to be identified. Regards, Steve On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. > > Title : Diameter Overload Indication Conveyance > Authors : Jouni Korhonen > Steve Donovan > Ben Campbell > Lionel Morand > Filename : draft-ietf-dime-ovli-03.txt > Pages : 48 > Date : 2014-07-03 > > Abstract: > This specification documents a Diameter Overload Control (DOC) base > solution and the dissemination of the overload report information. > > Requirements > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dime-ovli-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Sat Jul 5 12:48:42 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E361B27F4 for ; Sat, 5 Jul 2014 12:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.779 X-Spam-Level: X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 hbmZyTqE8xgg for ; Sat, 5 Jul 2014 12:48:40 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 920401B27F3 for ; Sat, 5 Jul 2014 12:48:40 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:64526 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X3Vws-0000jL-8S for dime@ietf.org; Sat, 05 Jul 2014 12:48:39 -0700 Message-ID: <53B85695.2010208@usdonovans.com> Date: Sat, 05 Jul 2014 14:48:37 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" References: <20140703161711.24974.27021.idtracker@ietfa.amsl.com> In-Reply-To: <20140703161711.24974.27021.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140703161711.24974.27021.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020406070204070609000201" X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/jaO9K1PXJeB8CkCXXNR_XwjMGII Subject: [Dime] Fwd: New Version Notification for draft-donovan-doic-agent-cases-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 19:48:41 -0000 This is a multi-part message in MIME format. --------------020406070204070609000201 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit All, The below referenced draft focuses on a number of DOIC deployment scenarios involving agents. The goal of this draft is to identify any new DOIC behaviors required to address these deployment scenarios. This directly addresses open issues #25, #27, #60 and #61 while indirectly addressing other open issues. Regards, Steve -------- Original Message -------- Subject: New Version Notification for draft-donovan-doic-agent-cases-00.txt Date: Thu, 03 Jul 2014 09:17:11 -0700 From: internet-drafts@ietf.org To: Ben Campbell , "Steve Donovan" , Steve Donovan , "Ben Campbell" A new version of I-D, draft-donovan-doic-agent-cases-00.txt has been successfully submitted by Steve Donovan and posted to the IETF repository. Name: draft-donovan-doic-agent-cases Revision: 00 Title: Analysis of Agent Use Cases for Diameter Overload Information Conveyance (DOIC) Document date: 2014-07-03 Group: Individual Submission Pages: 34 URL: http://www.ietf.org/internet-drafts/draft-donovan-doic-agent-cases-00.txt Status: https://datatracker.ietf.org/doc/draft-donovan-doic-agent-cases/ Htmlized: http://tools.ietf.org/html/draft-donovan-doic-agent-cases-00 Abstract: The Diameter Overload Information Conveyance (DOIC) solution describes a mechanism for exchanging information about Diameter Overload among Diameter nodes. A DOIC node is a Diameter node that acts as either a reporting node are a reacting node. A reporting node originates overload reports, requesting reacting nodes to reduce the amount of traffic sent. DOIC allows Diameter agents to act as reporting nodes, reacting nodes, or both, but does not describe agent behavior. This document explores several use cases for agents to participate in overload control, and makes recommendations for certain agent behaviors to be added to DOIC. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------020406070204070609000201 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit All,

The below referenced draft focuses on a number of DOIC deployment scenarios involving agents.  The goal of this draft is to identify any new DOIC behaviors required to address these deployment scenarios. 

This directly addresses open issues #25, #27, #60 and #61 while indirectly addressing other open issues.

Regards,

Steve

-------- Original Message --------
Subject: New Version Notification for draft-donovan-doic-agent-cases-00.txt
Date: Thu, 03 Jul 2014 09:17:11 -0700
From: internet-drafts@ietf.org
To: Ben Campbell <ben@nostrum.com>, "Steve Donovan" <srdonovan@usdonovans.com>, Steve Donovan <srdonovan@usdonovans.com>, "Ben Campbell" <ben@nostrum.com> 


A new version of I-D, draft-donovan-doic-agent-cases-00.txt
has been successfully submitted by Steve Donovan and posted to the
IETF repository.

Name:		draft-donovan-doic-agent-cases
Revision:	00
Title:		Analysis of Agent Use Cases for Diameter Overload Information Conveyance (DOIC)
Document date:	2014-07-03
Group:		Individual Submission
Pages:		34
URL:            http://www.ietf.org/internet-drafts/draft-donovan-doic-agent-cases-00.txt
Status:         https://datatracker.ietf.org/doc/draft-donovan-doic-agent-cases/
Htmlized:       http://tools.ietf.org/html/draft-donovan-doic-agent-cases-00


Abstract:
   The Diameter Overload Information Conveyance (DOIC) solution
   describes a mechanism for exchanging information about Diameter
   Overload among Diameter nodes.  A DOIC node is a Diameter node that
   acts as either a reporting node are a reacting node.  A reporting
   node originates overload reports, requesting reacting nodes to reduce
   the amount of traffic sent.  DOIC allows Diameter agents to act as
   reporting nodes, reacting nodes, or both, but does not describe agent
   behavior.  This document explores several use cases for agents to
   participate in overload control, and makes recommendations for
   certain agent behaviors to be added to DOIC.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--------------020406070204070609000201-- From nobody Mon Jul 7 09:30:57 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553DC1A0352 for ; Mon, 7 Jul 2014 09:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 PJUs35lOFDlu for ; Mon, 7 Jul 2014 09:30:53 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951321A0344 for ; Mon, 7 Jul 2014 09:30:53 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id a108so3866271qge.18 for ; Mon, 07 Jul 2014 09:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=U0HXlBO7MJMQRAgZZuWBdXEeeYgHBqLn9E4+GWzGj0w=; b=T3wQcXFEVStXuVklVdJ5RHmUiHPDJTJsdMvp0C41btBSu3XUkpMngOv3KkYVB9/f30 bHH7NcxahdvzNd3Butqx+6YgwG1Jo6D+JlLHTdrT9VmYnn1V8ei8Z0XTPd2GqHDglVYa QjjpSz2zNuHtZrD3l30PJwIKPJ0j5mUljo8LpOEQ6MGtlPUNyNML1uF5O2aIzWg3FuUu gh/qop3yLx7KIH6EuwqqDlOpsLH7blnomCIYqXH3GXlW+dF5Iaew5XyAJl2rZx3Ks5zH geiEN1Zx2ZYYUUdKhxVnvh/dbedAjOpl7vgflYLWlhYwndF5eoxn5zyu2RoJIZAVqVsy 7Y5g== X-Received: by 10.140.47.48 with SMTP id l45mr46455615qga.24.1404750652570; Mon, 07 Jul 2014 09:30:52 -0700 (PDT) Received: from [172.17.48.97] (50-76-50-145-ip-static.hfc.comcastbusiness.net. [50.76.50.145]) by mx.google.com with ESMTPSA id q10sm75145430qah.9.2014.07.07.09.30.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 09:30:51 -0700 (PDT) Message-ID: <53BACB39.2080308@gmail.com> Date: Mon, 07 Jul 2014 19:30:49 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steve Donovan , "dime@ietf.org" References: <20140703161711.24974.27021.idtracker@ietfa.amsl.com> <53B85695.2010208@usdonovans.com> In-Reply-To: <53B85695.2010208@usdonovans.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/LhoUlM_zOMMqvJTaCu5MpqZjhjk Subject: Re: [Dime] Fwd: New Version Notification for draft-donovan-doic-agent-cases-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 16:30:55 -0000 Thanks Steve putting -03 together. For the WG, please review the document. The document has reshaped quite a bit. It would be ideal if the next revision were close to final from the WG point of view. - Jouni 7/5/2014 10:48 PM, Steve Donovan kirjoitti: > All, > > The below referenced draft focuses on a number of DOIC deployment > scenarios involving agents. The goal of this draft is to identify any > new DOIC behaviors required to address these deployment scenarios. > > This directly addresses open issues #25, #27, #60 and #61 while > indirectly addressing other open issues. > > Regards, > > Steve > > -------- Original Message -------- > Subject: New Version Notification for > draft-donovan-doic-agent-cases-00.txt > Date: Thu, 03 Jul 2014 09:17:11 -0700 > From: internet-drafts@ietf.org > To: Ben Campbell , "Steve Donovan" > , Steve Donovan , > "Ben Campbell" > > > > A new version of I-D, draft-donovan-doic-agent-cases-00.txt > has been successfully submitted by Steve Donovan and posted to the > IETF repository. > > Name: draft-donovan-doic-agent-cases > Revision: 00 > Title: Analysis of Agent Use Cases for Diameter Overload Information Conveyance (DOIC) > Document date: 2014-07-03 > Group: Individual Submission > Pages: 34 > URL:http://www.ietf.org/internet-drafts/draft-donovan-doic-agent-cases-00.txt > Status:https://datatracker.ietf.org/doc/draft-donovan-doic-agent-cases/ > Htmlized:http://tools.ietf.org/html/draft-donovan-doic-agent-cases-00 > > > Abstract: > The Diameter Overload Information Conveyance (DOIC) solution > describes a mechanism for exchanging information about Diameter > Overload among Diameter nodes. A DOIC node is a Diameter node that > acts as either a reporting node are a reacting node. A reporting > node originates overload reports, requesting reacting nodes to reduce > the amount of traffic sent. DOIC allows Diameter agents to act as > reporting nodes, reacting nodes, or both, but does not describe agent > behavior. This document explores several use cases for agents to > participate in overload control, and makes recommendations for > certain agent behaviors to be added to DOIC. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Mon Jul 7 10:00:43 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107AE1A0370 for ; Mon, 7 Jul 2014 10:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 205WMd7GQjWz for ; Mon, 7 Jul 2014 10:00:40 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD66B1A041F for ; Mon, 7 Jul 2014 10:00:40 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id rp18so1364889iec.2 for ; Mon, 07 Jul 2014 10:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=H8jRyn2A+ODHZFxWOiRqAmsrbKu3ubUSycEewY9Bp+Y=; b=tq1+EXHw3RfHSU4LFNsZVU89WyMvBtch9GIn5vgoXtO6y+I9VdLRolpBg5AR7Ifkb1 HVDrI9V8mQcAq0ySsKIBGGQVQcux5Z0W5ZZrdze8p7qTNBaAwgWMY8lO1R3nWfPq6naw pw61pNv+Z9BKoII0lGK/lxLm/3xPb1nXOSxHR8ivgAsVSdGjD2Ov/b7Ay14syW24ErPW 7AVqjRIBtTr+HevHj/nLnCG+jtW64JX455JbyNqKIcUKCQmKBQqIyRpk1q1hVMtkVOvA omc8I0/BQYlph3BUKZNe4glUx8xVm/I8SUKacg4k6VUyzdxGUWAeSoNfZviKwYdqXbs7 UEHQ== X-Received: by 10.51.17.97 with SMTP id gd1mr41365583igd.18.1404752440165; Mon, 07 Jul 2014 10:00:40 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-11-121.tor.primus.ca. [173.206.11.121]) by mx.google.com with ESMTPSA id v6sm13112274igz.21.2014.07.07.10.00.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Jul 2014 10:00:39 -0700 (PDT) Message-ID: <53BAD236.5000100@gmail.com> Date: Mon, 07 Jul 2014 13:00:38 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/o7oqNsZkwraaHD0SIzLgq5N6QDc Subject: [Dime] Adding a new derived type X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 17:00:42 -0000 I have wondered from time to time why the derived AVP data formats in RFC 6733 Section 4.3 were not a little more general. In particular, it would be nice to have an address-or-prefix type rather than just an address, and an FQDN broken out from DiameterIdentity. This is to lead in to our latest revision of draft-zhou-dime-4over6-provisioning, which, alas, I forgot to submit before the deadline. Within the updated document, several attributes are either addresses or prefixes. Reading the introduction to Section 4.3, I gathered that defining a new derived AVP data format is permissible, although none has been registered with IANA as they are supposed to be. I present below the current text of the unsubmitted draft-zhou-dime-4over6-provisioning-03 that defines a new derived AVP data format, AddressOrPrefix. Comments? Tom Taylor 3. Derived AVP Data Formats: AddressOrPrefix The above requirements involve IP addresses and prefixes in a number of contexts. To simplify specification of these attributes, this section defines a new derived AVP data format, AddressOrPrefix, according to the rules given in Section 4.3 of [RFC6733]. AddressOrPrefix The AddressOrPrefix data format is an extension of the Address data format defined in Section 4.3.1 of [RFC6733]. Like the Address data format, it is derived from the OctetString basic AVP format. As well as an AddressType, it contains a PrefixLength field. The detailed specification is as follows: * As with the Address AVP, the first two octets represent the AddressType, which contains an Address Family, defined in [IANAADFAM]. * The next two octets are interpreted as a 16-bit unsigned integer representing the PrefixLength. Valid values of PrefixLength are from 0 to 32 for IPv4 and from 0 to 128 for IPv6. The value 0 is included in each range to allow for presentation of a "null prefix", the meaning of which must be defined by applications that use AVPs based on the AddressOrPrefix data format. * The remaining octets present the prefix or address, most significant octet first. If the prefix does not extend to an octet boundary, the low-order bits of the final octet are padded with zeroes. From nobody Fri Jul 11 05:03:34 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058261B2878 for ; Fri, 11 Jul 2014 05:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 JaiO7oqMd8RK for ; Fri, 11 Jul 2014 05:03:26 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 065AA1B2877 for ; Fri, 11 Jul 2014 05:03:25 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s6BC3N7t008164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Jul 2014 12:03:23 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s6BC3Kj5005807 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Jul 2014 14:03:22 +0200 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 11 Jul 2014 14:03:20 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.37]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0181.006; Fri, 11 Jul 2014 14:03:20 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Fwd: New Version Notification for draft-donovan-doic-agent-cases-00.txt Thread-Index: AQHPmIoin2/POQT9m0ympVT5CI4JSZuabRIw Date: Fri, 11 Jul 2014 12:03:19 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151F77ED@DEMUMBX014.nsn-intra.net> References: <20140703161711.24974.27021.idtracker@ietfa.amsl.com> <53B85695.2010208@usdonovans.com> In-Reply-To: <53B85695.2010208@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.106] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 19250 X-purgate-ID: 151667::1405080203-000005B1-8C6F3D19/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/FpfQmQXE1AC3u1OYFvr3L93MQWw Cc: "Rauschenbach, Uwe \(NSN - DE/Munich\)" Subject: Re: [Dime] Fwd: New Version Notification for draft-donovan-doic-agent-cases-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 12:03:31 -0000 U3RldmUsDQoNCkhlcmUgYXJlIG15IGNvbW1lbnRzOg0KDQoxLiBBYnN0cmFjdCAybmQgc2VudGVu Y2U6DQpUaGUgc2VudGVuY2Ugc2hvdWxkIHJlYWQ6ICJBIERPSUMgbm9kZSBpcyBhIERpYW1ldGVy IG5vZGUgdGhhdCBpbiBhIGdpdmVuIGNvbnRleHQgbWF5IGFjdCBhcyBhIHJlcG9ydGluZyBub2Rl IG9yIGEgcmVhY3Rpbmcgbm9kZS4iDQpUaGlzIGlzIHRvIGFsaWduIHlvdXIgZGVmaW5pdGlvbiAi QW55IERpYW1ldGVyIG5vZGUgdGhhdCBzdXBwb3J0cyBET0lDIGlzIGEgRE9JQyBub2RlIiAoc2Vl IDEuIEludHJvZHVjdGlvbiwgbGFzdCBwYXJhZ3JhcGgpIHdpdGggb3VyIGNvbW1vbiB1bmRlcnN0 YW5kaW5nIG9mIHRoZSAiZW5kLXRvLWVuZCBjb25jZXB0IiB3aGljaCBhbGxvd3MgYSBET0lDIG5v ZGUgc2l0dGluZyBiZXR3ZWVuIGEgc3VwcG9ydGluZyBjbGllbnQgYW5kIGEgc3VwcG9ydGluZyBz ZXJ2ZXIgdG8gYmUgdHJhbnNwYXJlbnQuDQoNCjIuIGNsYXVzZSAxLjEgVGVybWlub2xvZ3kgYW5k IEFiYnJldmlhdGlvbnMsIEFiYXRpbmcgbm9kZToNClRoZSBkZWZpbml0aW9uIHNob3VsZCByZWFk OiAiQSByZWFjdGluZyBub2RlIHRoYXQgbG9jYWxseSBwZXJmb3JtcyBvdmVybG9hZCBhYmF0ZW1l bnQgKGkuZS4gdGhyb3R0bGluZyBvciBkaXZlcnNpb24gYnV0IG5vdCBkZWxlZ2F0aW9uKS4iDQoN CjMuIGxvdHMgb2YgY29sb25zIG1pc3NpbmcgaW4gY2xhdXNlIDEuMQ0KDQo0LiBjbGF1c2UgMS4x IFRlcm1pbm9sb2d5IGFuZCBBYmJyZXZpYXRpb25zLCBPdmVybG9hZCBBYmF0ZW1lbnQ6DQpUaGUg ZGVmaW5pdGlvbiBzaG91bGQgcmVhZDogIi4uLi4uLiBPdmVybG9hZCBhYmF0ZW1lbnQgYWN0aW9u cyBtYXkgaW52b2x2ZSBsb2NhbCB0cmFmZmljIHJlZHVjdGlvbiwgb3IgZGVsZWdhdGlvbiBvZiBh Y3Rpb25zIHRvd2FyZHMgdGhlIGNsaWVudCAoRGVsZWdhdGlvbikuIExvY2FsIHRyYWZmaWMgcmVk dWN0aW9uIGNhbiBiZSBhY2hpZXZlZCBieSBlaXRoZXIgcmVqZWN0aW5nIGEgcmVxdWVzdCAoVGhy b3R0bGluZykgb3IgYnkgcm91dGluZyBhIHJlcXVlc3QgdG8gYSBkaWZmZXJlbnQgZGVzdGluYXRp b24gKERpdmVyc2lvbikuIg0KDQo1LiBjbGF1c2UgMS4xIFRlcm1pbm9sb2d5IGFuZCBBYmJyZXZp YXRpb25zLCBEaXZlcnNpb246DQpJIHByb3Bvc2UgdG8gYWRkIHRoZSBmb2xsb3dpbmcgY2xhcmlm aWNhdGlvbjoNCkRpdmVyc2lvbiBpcyBzcGVjaWZpYyB0byBhZ2VudHMgdGhhdCBwZXJmb3JtIHNl cnZlciBzZWxlY3Rpb24gZm9yIHJlYWxtLXJvdXRlZCByZXF1ZXN0cy4NCg0KNi4gY2xhdXNlIDEu MSBUZXJtaW5vbG9neSBhbmQgQWJicmV2aWF0aW9uczoNCkkgcHJvcG9zZSB0byBhbHNvIGRlZmlu ZSB3aGF0IERlbGVnYXRpb24gaXM6IA0KIkRlbGVnYXRpb246IE92ZXJsb2FkIGFiYXRlbWVudCB0 aHJvdWdoIHRoZSBkZWxlZ2F0aW9uIG9mIGFjdGlvbiAoVGhyb3R0bGluZykgdG8gYSBmdXJ0aGVy IGRvd25zdHJlYW0gcmVhY3Rpbmcgbm9kZS4gRGVsZWdhdGlvbiBpcyBzcGVjaWZpYyB0byBhZ2Vu dHMgdGhhdCBwZXJmb3JtIHNlcnZlciBzZWxlY3Rpb24gZm9yIHJlYWxtLXJvdXRlZCByZXF1ZXN0 cywgYW5kIGlzIHR5cGljYWxseSBkb25lIHdoZW4gdGhlIGFnZW50IGRldGVjdHMgdGhhdCBhbGwg YXZhaWxhYmxlIHNlcnZlcnMgaGF2ZSByZXF1ZXN0ZWQgbG9hZCByZWR1Y3Rpb24sIGkuZS4gd2hl biByZWNlaXZpbmcgYW4gYW5zd2VyIG1lc3NhZ2UgaW4gcmVzcG9uc2UgdG8gYSAobm90IHRocm90 dGxlZCkgcmVxdWVzdCB0aGF0IHdhcyBmb3J3YXJkZWQgdG8gYSBzZWxlY3RlZCBzZXJ2ZXIgd2hp Y2ggaW4gdGhlIGFuc3dlciByZXBvcnRzIGFuIHVwZGF0ZSBvZiBpdHMgb3ZlcmxvYWQgaW5mb3Jt YXRpb24uIg0KDQo3LiBjbGF1c2UgMiBEZXBsb3ltZW50IEFyY2hpdGVjdHVyZXMNClRoZXJlIGFy ZSBtYW55IG1vcmUgYXJjaGl0ZWN0dXJlcyBhbmQgc2NlbmFyaW9zIHdoaWNoIGNhbm5vdCBhbGwg YmUgY292ZXJlZCBzZXBhcmF0ZWx5LiBJIHRoZXJlZm9yZSBwcm9wb3NlIHRvIGZvY3VzIG9uIGdl bmVyYWwgcHJpbmNpcGxlcyB0aGF0IERPSUMgYWdlbnRzIG11c3QgZm9sbG93IGluZGVwZW5kZW50 IGZyb20gYXJjaGl0ZWN0dXJlIGFuZCBzY2VuYXJpby4gVGhlc2UgcHJpbmNpcGxlcyBhcmU6DQoN CkEpIFdoZW4gYW4gYWdlbnQgcmVjZWl2ZXMgYSBob3N0LXJvdXRlZCByZXF1ZXN0IHRoYXQgY29u dGFpbnMgYW4gT0MtUy1GIEFWUCwgaXQgdGFrZXMgbm8gRE9JQy1zcGVjaWZpYyBhY3Rpb24sIGku ZS4gaXQgZm9yd2FyZHMgdGhlIHJlcXVlc3QgdG8gdGhlIG5leHQgaG9wIHdpdGhvdXQgcmVtb3Zp bmcsIG1vZGlmeWluZyBvciBpbnNlcnRpbmcgT0MgQVZQczsgYWxzbyBubyBET0lDIHNwZWNpZmlj IGFjdGlvbiBpcyBwZXJmb3JtZWQgd2hlbiByZWNlaXZpbmcgdGhlIGNvcnJlc3BvbmRpbmcgYW5z d2VyLiBUaGUgYWdlbnQgbWF5IGhvd2V2ZXIgc3RvcmUgT0xSIGluZm9ybWF0aW9uIHJlY2VpdmVk IGluIHRoZSBhbnN3ZXIgZm9yIHBvdGVudGlhbCBsYXRlciB1c2UgaWYgaXQgc3VwcG9ydHMgdGhl IGZlYXR1cmVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgT0xSLg0KDQpCKSBXaGVuIGFuIGFnZW50IHJl Y2VpdmVzIGEgaG9zdC1yb3V0ZWQgcmVxdWVzdCB0aGF0IGRvZXMgbm90IGNvbnRhaW4gYW4gT0Mt Uy1GIEFWUCwgaXQgcGVyZm9ybXMgdGhyb3R0bGluZyBhY2NvcmRpbmcgdG8gYSBwcmV2aW91c2x5 IHJlY2VpdmUgaG9zdC10eXBlIE9MUiAoaWYgYW55KS5JZiB0aGUgcmVxdWVzdCBzdXJ2aXZlcyAo b3Igbm8gdGhyb3R0bGluZyB3YXMgcGVyZm9ybWVkIGJlY2F1c2Ugbm8gaG9zdC10eXBlIE9MUiBt YXRjaGVkKSwgdGhlIGFnZW50IGluc2VydHMgYW4gT0MtUy1GIEFWUCBhbmQgc2VuZHMgdGhlIHJl cXVlc3QgdG8gdGhlIG5leHQgaG9wLiBXaGVuIHJlY2VpdmluZyB0aGUgY29ycmVzcG9uZGluZyBh bnN3ZXIsIHRoZSBhZ2VudCBjaGVja3Mgd2hldGhlciBpdCBjb250YWlucyBhbiBPTFIgdXBkYXRl IGFuZCBpZiBzbyByZXBsYWNlcyB0aGUgc3RvcmVkIGluZm8gKGlmIGFueSkgd2l0aCB0aGUgdXBk YXRlZCBpbmZvLiBJbiBhbnkgY2FzZSB0aGUgYWdlbnQgcmVtb3ZlcyB0aGUgT0xSIGZyb20gdGhl IGFuc3dlciBiZWZvcmUgc2VuZGluZyBpdCB0byB0aGUgcHJldmlvdXMgaG9wLg0KDQpDKSBXaGVu IGFuIGFnZW50IHRoYXQgaXMgbm90IGNvbmZpZ3VyZWQgdG8gcGVyZm9ybSBzZXJ2ZXIgc2VsZWN0 aW9uIGZvciByZWFsbS1yb3V0ZWQgcmVxdWVzdHMgcmVjZWl2ZXMgYSByZWFsbS1yb3V0ZWQgcmVx dWVzdCB0aGF0IGNvbnRhaW5zIGFuIE9DLVMtRiBBVlAsIGl0IHRha2VzIG5vIERPSUMtc3BlY2lm aWMgYWN0aW9uLCBpLmUuIGl0IGZvcndhcmRzIHRoZSByZXF1ZXN0IHRvIHRoZSBuZXh0IGhvcCB3 aXRob3V0IHJlbW92aW5nLCBtb2RpZnlpbmcgb3IgaW5zZXJ0aW5nIE9DIEFWUHM7IGFsc28gbm8g RE9JQyBzcGVjaWZpYyBhY3Rpb24gaXMgcGVyZm9ybWVkIHdoZW4gcmVjZWl2aW5nIHRoZSBjb3Jy ZXNwb25kaW5nIGFuc3dlci4gVGhlIGFnZW50IG1heSBob3dldmVyIHN0b3JlIE9MUiBpbmZvcm1h dGlvbiByZWNlaXZlZCBpbiB0aGUgYW5zd2VyIGZvciBwb3RlbnRpYWwgbGF0ZXIgdXNlIGlmIGl0 IHN1cHBvcnRzIHRoZSBmZWF0dXJlcyBhc3NvY2lhdGVkIHdpdGggdGhlIE9MUi4NCg0KRCkgV2hl biBhbiBhZ2VudCB0aGF0IGlzIG5vdCBjb25maWd1cmVkIHRvIHBlcmZvcm0gc2VydmVyIHNlbGVj dGlvbiBmb3IgcmVhbG0tcm91dGVkIHJlcXVlc3RzIHJlY2VpdmVzIGEgcmVhbG0tcm91dGVkIHJl cXVlc3QgdGhhdCBkb2VzIG5vdCBjb250YWluIGFuIE9DLVMtRiBBVlAsIGl0IHBlcmZvcm1zIHRo cm90dGxpbmcgYWNjb3JkaW5nIHRvIGEgcHJldmlvdXNseSByZWNlaXZlIHJlYWxtLXR5cGUgT0xS IChpZiBhbnkpLklmIHRoZSByZXF1ZXN0IHN1cnZpdmVzIChvciBubyB0aHJvdHRsaW5nIHdhcyBw ZXJmb3JtZWQgYmVjYXVzZSBubyByZWFsbS10eXBlIE9MUiBtYXRjaGVkKSwgdGhlIGFnZW50IGlu c2VydHMgYW4gT0MtUy1GIEFWUCBhbmQgc2VuZHMgdGhlIHJlcXVlc3QgdG8gdGhlIG5leHQgaG9w LiBXaGVuIHJlY2VpdmluZyB0aGUgY29ycmVzcG9uZGluZyBhbnN3ZXIsIHRoZSBhZ2VudCBjaGVj a3Mgd2hldGhlciBpdCBjb250YWlucyBhbiBPTFIgdXBkYXRlIGFuZCBpZiBzbyByZXBsYWNlcyB0 aGUgc3RvcmVkIGluZm8gKGlmIGFueSkgd2l0aCB0aGUgdXBkYXRlZCBpbmZvLiBJbiBhbnkgY2Fz ZSB0aGUgYWdlbnQgcmVtb3ZlcyB0aGUgT0xSIGZyb20gdGhlIGFuc3dlciBiZWZvcmUgc2VuZGlu ZyBpdCB0byB0aGUgcHJldmlvdXMgaG9wLg0KDQpFKSBXaGVuIGFuIGFnZW50IHRoYXQgaXMgY29u ZmlndXJlZCB0byBwZXJmb3JtIHNlcnZlciBzZWxlY3Rpb24gZm9yIHJlYWxtLXJvdXRlZCByZXF1 ZXN0cyByZWNlaXZlcyBhIHJlYWxtLXJvdXRlZCByZXF1ZXN0IHRoYXQgY29udGFpbnMgYW4gT0Mt Uy1GIEFWUCwgaXQgcGVyZm9ybXMgc2VydmVyIHNlbGVjdGlvbiwgYWRkcyB0aGUgRGVzdGluYXRp b24tSG9zdCBBVlAgd2l0aCB0aGUgdmFsdWUgaWRlbnRpZnlpbmcgdGhlIHNlbGVjdGVkIHNlcnZl ciB0byB0aGUgcmVxdWVzdCAodGhpcyBuZWVkIG5vdCBiZSBkb25lIHdoZW4gdGhlIHNlbGVjdGVk IHNlcnZlciBpcyBhbiBpbW1lZGlhdGUgcGVlciksIHJlcGxhY2VzIHRoZSByZWNlaXZlZCBPQy1T LUYgQVZQIHdpdGggaXRzIG93biBPQy1TLUYgQVZQIGluIHRoZSByZXF1ZXN0IGFuZCBmb3J3YXJk cyB0aGUgcmVxdWVzdCB0byB0aGUgbmV4dCBob3AuIFdoZW4gcmVjZWl2aW5nIHRoZSBjb3JyZXNw b25kaW5nIGFuc3dlciB0aGUgYWdlbnQgY2hlY2tzIHdoZXRoZXIgaXQgY29udGFpbnMgYW4gT0xS IHVwZGF0ZSBhbmQgaWYgc28gcmVwbGFjZXMgdGhlIHN0b3JlZCBpbmZvIChpZiBhbnkpIHdpdGgg dGhlIHVwZGF0ZWQgaW5mbywgY2FsY3VsYXRlcyBhbiAoYWdncmVnYXRlZCkgcmVhbG0tdHlwZSBP TFIgdGhhdCBmaXRzIHRvIHRoZSBzdXBwb3J0ZWQgZmVhdHVyZXMgYXMgcmVjZWl2ZWQgaW4gdGhl IHJlcXVlc3QuIEluIGFueSBjYXNlIHRoZSBhZ2VudCByZXBsYWNlcyB0aGUgT0MtUy1GIGluIHRo ZSBhbnN3ZXIgd2l0aCBpdHMgb3duIE9DLVMtRiAoaW5kaWNhdGluZyB0aGUgc2VsZWN0ZWQgYWxn b3JpdGhtKSwgcmVtb3ZlcyB0aGUgT0MtT0xSIGZyb20gdGhlIGFuc3dlciBhbmQgYWRkcyBpdHMg b3duIGNhbGN1bGF0ZWQgYWdncmVnYXRlZCByZWFsbS10eXBlIE9MUiAoaWYgYW55KSB0byB0aGUg YW5zd2VyIGJlZm9yZSBzZW5kaW5nIGl0IHRvIHRoZSBwcmV2aW91cyBob3AuDQoNCkYpIFdoZW4g YW4gYWdlbnQgdGhhdCBpcyBjb25maWd1cmVkIHRvIHBlcmZvcm0gc2VydmVyIHNlbGVjdGlvbiBm b3IgcmVhbG0tcm91dGVkIHJlcXVlc3RzIHJlY2VpdmVzIGEgcmVhbG0tcm91dGVkIHJlcXVlc3Qg dGhhdCBkb2VzIG5vdCBjb250YWluIGFuIE9DLVMtRiBBVlAsIGxvZ2ljYWxseSBhIGNvbWJpbmF0 aW9uIG9mIGNhc2UgRCkgZm9sbG93ZWQgYnkgY2FzZSBFKSBpcyBwZXJmb3JtZWQuDQoNCjguIGNs YXVzZSAzLiBEaWFtZXRlciBSb3V0aW5nLCAzcmQgcGFyYWdyYXBoOg0KU2hvdWxkIHJlYWQ6ICJJ biBnZW5lcmFsLCB0aHJvdHRsaW5nIChTZWN0aW9uIDQpIGlzIHRoZSBvbmx5IGxvY2FsIGFiYXRl bWVudCB0ZWNobmlxdWUgdGhhdCB3b3JrcyBmb3IgaG9zdC1yb3V0ZWQgcmVxdWVzdHMuIERpdmVy c2lvbiAoU2VjdGlvbiA0KSBpcyB0eXBpY2FsbHkgbm90IHBvc3NpYmxlLCBzaW5jZSBvbmx5IGEg c2luZ2xlIFRTIGNhbiBoYW5kbGUgYW55IGdpdmVuIGhvc3Qtcm91dGVkIHJlcXVlc3QuIg0KDQo5 LiBjbGF1c2UgMy4gRGlhbWV0ZXIgUm91dGluZywgbGFzdCBzZW50ZW5jZToNClNob3VsZCByZWFk OiAiU2luY2UgcmVhbG0tcm91dGVkIHJlcXVlc3RzIGFyZSBub3QgYm91bmQgdG8gYSBwYXJ0aWN1 bGFyIFRTLCBpdCBpcyBvZnRlbiBwb3NzaWJsZSBmb3IgdGhlIG5vZGUgdGhhdCBzZWxlY3RzIHRo ZSBzZXJ2ZXIgdG8gZGl2ZXJ0IGEgbnVtYmVyIG9mIHRoZW0gdG8gb3RoZXIgc2VydmVycyB0aGF0 IGFyZSBsZXNzIG92ZXJsb2FkZWQuIg0KDQoxMC4gY2xhdXNlIDQuIE92ZXJsb2FkIEFiYXRlbWVu dCBNZXRob2RzLCA0dGggd29yZDoNClNob3VsZCByZWFkICJzZXJ2ZXIiLiBBZ2VudCBvdmVybG9h ZCBpcyBvdXQgb2Ygc2NvcGUuDQoNCjExLiBjbGF1c2UgNC4gT3ZlcmxvYWQgQWJhdGVtZW50IE1l dGhvZCwgN3RoIHBhcmFncmFwaDoNCkRpdmVyc2lvbiAod2hpY2ggaXMgbGltaXRlZCB0byByZWFs bS1yb3V0ZWQgcmVxdWVzdHMpIGNhbiBvbmx5IG9jY3VyIGF0IHRoZSBEaWFtZXRlciBOb2RlIHRo YXQgcGVyZm9ybXMgdGhlIHNlcnZlciBzZWxlY3Rpb24uIFRvcG9sb2d5IGtub3dsZWRnZSBpcyBu b3QgbmVlZGVkLiBPdmVybG9hZCBzdGF0ZSBrbm93bGVkZ2UgYWN0dWFsbHkgaXMgcHVzaGVkIGZ1 cnRoZXIgZG93biB0aGUgY2hhaW4uIFRoZSBub2RlIGNhbiBjb250cm9sIGhvdyB0aGUgcmVjZWl2 ZWQgcmVhbG0tcm91dGVkIHJlcXVlc3QgaXMgcm91dGVkIHVwc3RyZWFtIGJ5IGluc2VydGluZyBh IERlc3RpbmF0aW9uLUhvc3QgQVZQLiANCg0KMTIuIGNsYXVzZSA0LiBPdmVybG9hZCBBYmF0ZW1l bnQgTWV0aG9kcywgbGFzdCBwYXJhZ3JhcGg6DQoibGVhc2UiIHNob3VsZCByZWFkICJsZWFzdCIN Cg0KMTMuIGNsYXVzZSA1LiBET0lDIFVzZSBDYXNlczoNCkkgaGF2ZSBsb3RzIG9mIGRldGFpbGVk IGNvbW1lbnRzIHdoaWNoIEkgY2FuIHNoYXJlIGluIGEgc2VwYXJhdGUgbWFpbC4gVGhlIGVzc2Vu Y2UgaXMgdGhhdCBhbGwgdGhlIHVzZSBjYXNlcyBkZXNjcmliZWQgc2hvdWxkIGZvbGxvdyB0aGUg Z2VuZXJhbCBwcmluY2lwbGVzIEEgdG8gRiBvdXRsaW5lZCBhYm92ZS4gSXQgbWF5IGJlIHdvcnRo IHRvIHRvdGFsbHkgcmV3cml0ZSB0aGlzIGNsYXVzZSB0byBpbGx1c3RyYXRlIHRoZSBnZW5lcmFs IHByaW5jaXBsZXMgQSB0byBGLg0KDQoxNC4gY2xhdXNlIDYuMS4gR2VuZXJhbCBSZWNvbW1lbmRh dGlvbiwgbGFzdCBwYXJhZ3JhcGg6DQpUaGlzIGlzIG5vdCBzdHJpY3RseSByZXF1aXJlZC4gTXVs dGlwbGUgb2NjdXJyZW5jZXMgb2YgT0MtT0xSIGNvdWxkIGJlIHJlZ2FyZGVkIGFuIGFuIG9wdGlt aXphdGlvbi4gQnV0IHRoZW4gdGhlcmUgYXJlIGlzc3Vlczogd2hlbiB0aGVyZSBhcmUgdHdvIE9M UnMgaW4gb25lIGFuc3dlciwgZS5nLiBvbmUgcmVhbG0tdHlwZSBPTFIgZm9yIGxvc3MgYW5kIG9u ZSBob3N0LXR5cGUgT0xSIGZvciByYXRlLCB3ZSB3b3VsZCBhbHNvIG5lZWQgdHdvIE9DLVMtRiBB VlBzOiBvbmUgaW5kaWNhdGluZyB0aGF0IGxvc3MgaXMgc2VsZWN0ZWQsIGFuZCBvbmUgaW5kaWNh dGluZyB0aGF0IHJhdGUgaXMgc2VsZWN0ZWQuIEJ1dCB0aGlzIHNlZW1zIHRvIGJlIGNvbnRyYWRp Y3RpbmcgaW5mb3JtYXRpb24uDQoNCjE1LiBjbGF1c2UgNi4yLjEgQ2FwYWJpbGl0aWVzIEV4Y2hh bmdlIEJlaGF2aW91cnMsIDNyZCBwYXJhZ3JhcGg6DQpTaG91bGQgcmVhZDogIkFuIGFnZW50IG1h eSBhY3QgYXMgYSByZXBvcnRpbmcgbm9kZSBvbiBiZWhhbGYgb2YgYSBub24tc3VwcG9ydGluZyBU Uywgb3IgYXMgcmVhY3Rpbmcgbm9kZSBvbiBiZWhhbGYgb2YgYSBub24tc3VwcG9ydGluZyBUQy5b U2VjdGlvbiA1LjNdIi4gSSdtIG5vdCBzdXJlIHdoZXRoZXIgd2Ugc2hvdWxkIGNvdmVyIHRoZSBm aXJzdCBjYXNlLiBBdCBsZWFzdCBpdCBzaG91bGQgYmUgbGltaXRlZCB0byBhcmNoaXRlY3R1cmVz IHdoZXJlIHRoZSBhZ2VudCAoYWN0aW5nIGFzIHJlcG9ydGluZyBub2RlIG9uIGJlaGFsZiBvZiB0 aGUgbm9uIHN1cHBvcnRpbmcgc2VydmVyKSBhbmQgdGhlIChub24gc3VwcG9ydGluZykgc2VydmVy IGFyZSBpbW1lZGlhdGUgcGVlcnMgYW5kIHRoZSBzZXJ2ZXIgaGFzIG5vIG90aGVyIGltbWVkaWF0 ZSBwZWVycywgc28gdGhhdCB0aGUgdHdvIG5vZGVzIGNhbiBiZSByZWdhcmRlZCBhIHNpbmdsZSBz dXBwb3J0aW5nIHNlcnZlci4NCg0KMTYuIGNsYXVzZSA2LjIuMSBDYXBhYmlsaXRpZXMgRXhjaGFu Z2UgQmVoYXZpb3VycywgNHRoIHBhcmFncmFwaDoNClRvIGFkZCBzb21lIGNsYXJpZmljYXRpb3Mg dGhpcyBzaG91bGQgcmVhZDoNCiJBbiBhZ2VudCB0aGF0IGFjdHMgYXMgYSByZWFjdGluZyBub2Rl IG11c3QgaW5jbHVkZSBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgaW4gZWFjaCBEaWFtZXRlciBy ZXF1ZXN0IHRoYXQgaXQgZm9yd2FyZHMgaW4gdGhhdCByb2xlLiBJZiB0aGUgaW5ib3VuZCByZXF1 ZXN0IGluY2x1ZGVkIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAsIHRoZSBhZ2VudCBtYXkg Y29weSBpdHMgY29udGVudCB0byB0aGUgb25lIGluIHRoZSBvdXRib3VuZCByZXF1ZXN0ICh0aGlz IGlzIHRoZSBjYXNlIHdoZXJlIHRoZSByZXF1ZXN0IGlzIGEpIGhvc3Qtcm91dGVkIG9yIGIpIHJl YWxtLXJvdXRlZCBhbmQgdGhlIGFnZW50IGlzIG5vdCBjb25maWd1cmVkIHRvIHBlcmZvcm0gc2Vy dmVyIHNlbGVjdGlvbiksIG9yIG1heSByZXBsYWNlIHRoZSBjb250ZW50cyBpbmRpY2F0aW5nIHRo ZSBET0lDIGNhcGFiaWxpdGllcyBvZiB0aGUgYWdlbnQgaXRzZWxmICh0aGlzIGlzIHRoZSBjYXNl IHdoZXJlIHRoZSByZXF1ZXN0IGlzIHJlYWxtIHJvdXRlZCBhbmQgdGhlIGFnZW50IGlzIGNvbmZp Z3VyZWQgdG8gcGVyZm9ybSBzZXJ2ZXIgc2VsZWN0aW9uKS4gSWYgYW4gaW5ib3VuZCByZXF1ZXN0 IGRvZXMgbm90IGNvbnRhaW4gYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCwgdGhlIGFnZW50 IG11c3QgaW5zZXJ0IG9uZSBpbnRvIHRoZSBvdXRib3VuZCByZXF1ZXN0LCBpbmRpY2F0aW5nIHRo ZSBET0lDIGNhcGFiaWxpdGllcyBvZiB0aGUgYWdlbnQgaXRzZWxmLiINCg0KMTcuIGNsYXVzZSA2 LjIuMSBDYXBhYmlsaXRpZXMgRXhjaGFuZ2UgQmVoYXZpb3VycywgbGFzdCBwYXJhZ3JhcGg6DQpT aG91bGQgcmVhZDogIkFuIGFnZW50IHRoYXQgZG9lcyBub3Qgc3VwcG9ydCB0aGUgRE9JQyBtZWNo YW5pc20gaXMgbGlrZWx5IHRvIGZvcndhcmQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCB3 aXRob3V0IG1vZGlmaWNhdGlvbi4gQSBET0lDIG5vZGUgbXVzdCBiZSBhYmxlIHRvIHRlbGwgYmV0 d2VlbiBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQIHRoYXQgd2FzIGluc2VydGVkIGJ5IGEg bm9kZSB3aXRoaW4gYSB0cnVzdGVkIGRvbWFpbiwgYW5kIG9uZSBpbnNlcnRlZCBieSBhIG5vZGUg d2l0aGluIGEgbm9uLXRydXN0ZWQgZG9tYWluLltTZWN0aW9uIDUuNF0iLiBUaGlzIGlzIGJlY2F1 c2UgdGhlIHJlcG9ydGluZyBub2RlIChpZiBpdCBzZW5kcyBhbiBPTFIgd2l0aGluIGFuIGFuc3dl cikgc2VuZHMgaXQncyBPTFIgdG8gdGhlIG5vZGUgdGhhdCBoYXMgaW5zZXJ0ZWQgdGhlIE9DLVMt RiBBVlAgdG8gdGhlIHJlcXVlc3QuDQoNCjE4LiBjbGF1c2UgNi4yLjIgT3ZlcmxvYWQgUmVwb3J0 IEJlaGF2aW91cnMsIDFzdCBzZW50ZW5jZSwgdGhlIHBhcnQgaW4gYnJhY2tldHM6DQpJIGRvIG5v dCBhZ3JlZTsgd2hlbiBwYXNzaW5nIHRocm91Z2gsIHRoZSByZXNwb25zaWJpbGl0eSBpcyBhdCB0 aGUgc291cmNlLCBub3QgYXQgdGhlIHJlbGF5LiBUaGUgc2VudGVuY2Ugc2hvdWxkIHJlYWQ6ICJX aGVuIGEgRE9JQy1zdXBwb3J0aW5nIHJlbGF5IGluc2VydHMgb3IgcmVwbGFjZXMgYW4gT0MtU3Vw cG9ydGVkLUZlYXR1cmVzIEFWUCwgaXQgYmVjb21lcyByZXNwb25zaWJsZSBmb3IgZW5zdXJpbmcg dGhhdCBhbnkgT0xScyBpdCByZWNlaXZlcyBmcm9tIHVwc3RyZWFtIG5vZGVzIGFyZSBob25vcmVk LiINCg0KMTkuIGNsYXVzZSA2LjIuMiBPdmVybG9hZCBSZXBvcnQgQmVoYXZpb3VycywgMm5kIHNl bnRlbmNlOg0KSWYgdGhlIGFiYXRlbWVudCBpcyBub3QgIkRpdmVyc2lvbiIgYW5kICJEZWxlZ2F0 aW9uIiBpcyBwb3NzaWJsZSwgIkRlbGVnYXRpb24iIHJhdGhlciB0aGFuICJUaHJvdHRsaW5nIiBt dXN0IGJlIGRvbmUuDQoNCjIwLiBjbGF1c2UgNi4yLjIgT3ZlcmxvYWQgUmVwb3J0IEJlaGF2aW91 cnMsIDJuZCBwYXJhZ3JhcGgsIGxhc3Qgc2VudGVuY2U6DQpJIGRvIG5vdCBhZ3JlZS4gU2VlIGFs c28gY29tbWVudCAxMS4gRGl2ZXJzaW9uIGlzIGxpbWl0ZWQgdG8gcmVhbG0tcm91dGVkIHJlcXVl c3RzIGFuZCBjYW4gb25seSBiZSBwZXJmb3JtZWQgYnkgbm9kZXMgdGhhdCBkbyB0aGUgc2VydmVy IHNlbGVjdGlvbi4gVGhlc2Ugbm9kZXMgY2FuIGNvbnZlcnQgdGhlIHJlYWxtLXJvdXRlZCByZXF1 ZXN0IHRvIGEgaG9zdC1yb3V0ZWQgcmVxdWVzdC4NCg0KMjEuIGNsYXVzZSA2LjIuMiBPdmVybG9h ZCBSZXBvcnQgQmVoYXZpb3VycywgM3JkIHBhcmFncmFwaCwgbGFzdCBzZW50ZW5jZToNCk1vZGlm eWluZyBPTFJzIG11c3QgZm9sbG93IHN0cmljdCBydWxlcy4gV2UgZWl0aGVyIGhhdmUNCmEpIG9u ZSBET0lDIGFzc29jaWF0aW9uIGJldHdlZSByZWFjdGluZyBub2RlIGFuZCByZXBvcnRpbmcgbm9k ZSB3aGVyZSBhbGwgYWdlbnRzIGluIGJldHdlZW4gYXJlIHRyYW5zcGFyZW50IGFuZCBkbyBub3Qg bW9kaWZ5IE9DLXh4eCBBVlBzLCBvciANCmIpIHR3byBpbmRlcGVuZGVudCBET0lDIGFzc29jaWF0 aW9ucywgb25lIGJldHdlZW4gcmVhY3Rpbmcgbm9kZSBhbmQgYWdlbnQgKGFjdGluZyBhcyByZXBv cnRpbmcgbm9kZSkgYW5kIG9uZSBiZXR3ZWVuIHRoZSBzYW1lIGFnZW50IChub3cgYWN0aW5nIGFz IHJlYWN0aW5nIG5vZGUpIGFuZCByZXBvcnRpbmcgbm9kZS4gSGVyZSB0aGUgYWdlbnQgcmVtb3Zl cyB0aGUgcmVjZWl2ZWQgaG9zdC10eXBlIE9MUiBhbmQgaW5zZXJ0cyBpdHMgb3duIGFnZ3JlZ2F0 ZWQgcmVhbG0tdHlwZSBPTFIuIEkgd291bGQgbm90IGNhbGwgdGhpcyBhIG1vZGlmaWNhdGlvbiBi dXQgYSByZXBsYWNlbWVudC4gTW9kaWZpY2F0aW9ucyBvdGhlciB0aGFuIHRoaXMgbWF5IG5vdCBi ZSBhIGdvb2QgaWRlYS4NCg0KMjIuIGNsYXVzZSA2LjIuMiBPdmVybG9hZCBSZXBvcnQgQmVoYXZp b3VycywgbGFzdCBidXQgb25lIHBhcmFncmFwaDoNCkl0IGlzIHRoZSBvdGhlciB3YXkgcm91bmQ6 DQpBbiBhZ2VudCBzaGFsbCBub3QgdGhyb3R0bGUgdHJhZmZpYyBsb2NhbGx5IHdoZW4gaXQgaGFz IGFscmVhZHkgc2VudCAob3Igd2lsbCBzb29uIHNlbmQpIGFuIE9MUiBkb3duc3RyZWFtIChpLmUu IHdoZW4gaXQgY2FuIG9yIGFscmVhZHkgaGFzIGRlbGVnYXRlZCB0aGUgYWJhdGVtZW50KS4gV2hl biByZWNlaXZpbmcgYSB4eFIgdGhhdCBjb250YWlucyBhbiBPQy1TLUYgQVZQIChhbmQgdGhlIHh4 UiBtYXRjaGVzIGFuIE9MUikgdGhlIGFnZW50IGNhbiBhbG1vc3Qgc2FmZWx5IGFzc3VtZSB0aGF0 IHRoaXMgcmVxdWVzdCBzdXJ2aXZlZCBhbiBvbmdvaW5nIHRocm90dGxpbmcgZG93bnN0cmVhbS4g VGhlIHByaW5jaXBsZSBpcyB0aGF0IHRocm90dGxpbmcgc2hvdWxkIGJlIGRvbmUgYXMgY2xvc2Ug YXMgcG9zc2libGUgdG8gdGhlIGNsaWVudC4NCg0KUmVnYXJkcywNClVscmljaA0KDQoNCkZyb206 IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgU3Rl dmUgRG9ub3Zhbg0KU2VudDogU2F0dXJkYXksIEp1bHkgMDUsIDIwMTQgOTo0OSBQTQ0KVG86IGRp bWVAaWV0Zi5vcmcNClN1YmplY3Q6IFtEaW1lXSBGd2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtZG9ub3Zhbi1kb2ljLWFnZW50LWNhc2VzLTAwLnR4dA0KDQpBbGwsDQoNClRo ZSBiZWxvdyByZWZlcmVuY2VkIGRyYWZ0IGZvY3VzZXMgb24gYSBudW1iZXIgb2YgRE9JQyBkZXBs b3ltZW50IHNjZW5hcmlvcyBpbnZvbHZpbmcgYWdlbnRzLsKgIFRoZSBnb2FsIG9mIHRoaXMgZHJh ZnQgaXMgdG8gaWRlbnRpZnkgYW55IG5ldyBET0lDIGJlaGF2aW9ycyByZXF1aXJlZCB0byBhZGRy ZXNzIHRoZXNlIGRlcGxveW1lbnQgc2NlbmFyaW9zLsKgIA0KDQpUaGlzIGRpcmVjdGx5IGFkZHJl c3NlcyBvcGVuIGlzc3VlcyAjMjUsICMyNywgIzYwIGFuZCAjNjEgd2hpbGUgaW5kaXJlY3RseSBh ZGRyZXNzaW5nIG90aGVyIG9wZW4gaXNzdWVzLg0KDQpSZWdhcmRzLA0KDQpTdGV2ZQ0KDQotLS0t LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tIA0KU3ViamVjdDogDQpOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWRvbm92YW4tZG9pYy1hZ2VudC1jYXNlcy0wMC50eHQNCkRh dGU6IA0KVGh1LCAwMyBKdWwgMjAxNCAwOToxNzoxMSAtMDcwMA0KRnJvbTogDQppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcNClRvOiANCkJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPiwgIlN0 ZXZlIERvbm92YW4iIDxzcmRvbm92YW5AdXNkb25vdmFucy5jb20+LCBTdGV2ZSBEb25vdmFuIDxz cmRvbm92YW5AdXNkb25vdmFucy5jb20+LCAiQmVuIENhbXBiZWxsIiA8YmVuQG5vc3RydW0uY29t Pg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZG9ub3Zhbi1kb2ljLWFnZW50LWNhc2Vz LTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTdGV2ZSBEb25vdmFu IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1kb25v dmFuLWRvaWMtYWdlbnQtY2FzZXMNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlBbmFseXNpcyBvZiBB Z2VudCBVc2UgQ2FzZXMgZm9yIERpYW1ldGVyIE92ZXJsb2FkIEluZm9ybWF0aW9uIENvbnZleWFu Y2UgKERPSUMpDQpEb2N1bWVudCBkYXRlOgkyMDE0LTA3LTAzDQpHcm91cDoJCUluZGl2aWR1YWwg U3VibWlzc2lvbg0KUGFnZXM6CQkzNA0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWRvbm92YW4tZG9pYy1hZ2VudC1jYXNlcy0wMC50eHQN ClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1k b25vdmFuLWRvaWMtYWdlbnQtY2FzZXMvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtZG9ub3Zhbi1kb2ljLWFnZW50LWNhc2VzLTAwDQoNCg0KQWJzdHJh Y3Q6DQogICBUaGUgRGlhbWV0ZXIgT3ZlcmxvYWQgSW5mb3JtYXRpb24gQ29udmV5YW5jZSAoRE9J Qykgc29sdXRpb24NCiAgIGRlc2NyaWJlcyBhIG1lY2hhbmlzbSBmb3IgZXhjaGFuZ2luZyBpbmZv cm1hdGlvbiBhYm91dCBEaWFtZXRlcg0KICAgT3ZlcmxvYWQgYW1vbmcgRGlhbWV0ZXIgbm9kZXMu ICBBIERPSUMgbm9kZSBpcyBhIERpYW1ldGVyIG5vZGUgdGhhdA0KICAgYWN0cyBhcyBlaXRoZXIg YSByZXBvcnRpbmcgbm9kZSBhcmUgYSByZWFjdGluZyBub2RlLiAgQSByZXBvcnRpbmcNCiAgIG5v ZGUgb3JpZ2luYXRlcyBvdmVybG9hZCByZXBvcnRzLCByZXF1ZXN0aW5nIHJlYWN0aW5nIG5vZGVz IHRvIHJlZHVjZQ0KICAgdGhlIGFtb3VudCBvZiB0cmFmZmljIHNlbnQuICBET0lDIGFsbG93cyBE aWFtZXRlciBhZ2VudHMgdG8gYWN0IGFzDQogICByZXBvcnRpbmcgbm9kZXMsIHJlYWN0aW5nIG5v ZGVzLCBvciBib3RoLCBidXQgZG9lcyBub3QgZGVzY3JpYmUgYWdlbnQNCiAgIGJlaGF2aW9yLiAg VGhpcyBkb2N1bWVudCBleHBsb3JlcyBzZXZlcmFsIHVzZSBjYXNlcyBmb3IgYWdlbnRzIHRvDQog ICBwYXJ0aWNpcGF0ZSBpbiBvdmVybG9hZCBjb250cm9sLCBhbmQgbWFrZXMgcmVjb21tZW5kYXRp b25zIGZvcg0KICAgY2VydGFpbiBhZ2VudCBiZWhhdmlvcnMgdG8gYmUgYWRkZWQgdG8gRE9JQy4N Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KDQoNCg== From nobody Fri Jul 11 15:05:58 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1F11B29DF for ; Fri, 11 Jul 2014 15:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 IYtyxVbmsK_I for ; Fri, 11 Jul 2014 15:05:52 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 1D2871B29DE for ; Fri, 11 Jul 2014 15:05:51 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6BM5nwJ037218 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 11 Jul 2014 17:05:51 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151F77ED@DEMUMBX014.nsn-intra.net> Date: Fri, 11 Jul 2014 17:05:49 -0500 X-Mao-Original-Outgoing-Id: 426809149.318951-9f949857517e574a005f57f4b049e232 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140703161711.24974.27021.idtracker@ietfa.amsl.com> <53B85695.2010208@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151F77ED@DEMUMBX014.nsn-intra.net> To: "dime@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/bieszREs7xU6QPEfxI3eX1SoTOQ Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2014 22:05:55 -0000 Hi Ulrich, Thanks for the feedback! We intended this draft as more of a discussion paper than something that = the working group would publish. I will respond to some of your = substantive comments inline. If we publish a new revision at some point, = we can address the editorial and clarification comments at that time. Thanks! Ben. On Jul 11, 2014, at 7:03 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: [...] > 7. clause 2 Deployment Architectures > There are many more architectures and scenarios which cannot all be = covered separately. I therefore propose to focus on general principles = that DOIC agents must follow independent from architecture and scenario. = These principles are: I agree the scenarios in the draft are not exhaustive. We picked some = that we think exercise certain behaviors, that are discussed in the = scenarios and in the recommendations section. I believe they are all = reasonable scenarios that DOIC should allow. >=20 > A) When an agent receives a host-routed request that contains an = OC-S-F AVP, it takes no DOIC-specific action, i.e. it forwards the = request to the next hop without removing, modifying or inserting OC = AVPs; also no DOIC specific action is performed when receiving the = corresponding answer. The agent may however store OLR information = received in the answer for potential later use if it supports the = features associated with the OLR. Do I understand correctly that you mean that an agent MUST NOT remove or = modify the OC-S-F from host routed requests? If so, I disagree. There = are real world scenarios that will require that modification or removal. = (For example, those in section 5.2) >=20 > B) When an agent receives a host-routed request that does not contain = an OC-S-F AVP, it performs throttling according to a previously receive = host-type OLR (if any).If the request survives (or no throttling was = performed because no host-type OLR matched), the agent inserts an OC-S-F = AVP and sends the request to the next hop. When receiving the = corresponding answer, the agent checks whether it contains an OLR update = and if so replaces the stored info (if any) with the updated info. In = any case the agent removes the OLR from the answer before sending it to = the previous hop. I agree in general, although I think we can separate the " what if this = request gets throttled" behaviors from the "how you treat OC-S-F in = forwarded requests" aspects. >=20 > C) When an agent that is not configured to perform server selection = for realm-routed requests receives a realm-routed request that contains = an OC-S-F AVP, it takes no DOIC-specific action, i.e. it forwards the = request to the next hop without removing, modifying or inserting OC = AVPs; also no DOIC specific action is performed when receiving the = corresponding answer. The agent may however store OLR information = received in the answer for potential later use if it supports the = features associated with the OLR. >=20 > D) When an agent that is not configured to perform server selection = for realm-routed requests receives a realm-routed request that does not = contain an OC-S-F AVP, it performs throttling according to a previously = receive realm-type OLR (if any).If the request survives (or no = throttling was performed because no realm-type OLR matched), the agent = inserts an OC-S-F AVP and sends the request to the next hop. When = receiving the corresponding answer, the agent checks whether it contains = an OLR update and if so replaces the stored info (if any) with the = updated info. In any case the agent removes the OLR from the answer = before sending it to the previous hop. >=20 > E) When an agent that is configured to perform server selection for = realm-routed requests receives a realm-routed request that contains an = OC-S-F AVP, it performs server selection, adds the Destination-Host AVP = with the value identifying the selected server to the request (this need = not be done when the selected server is an immediate peer), replaces the = received OC-S-F AVP with its own OC-S-F AVP in the request and forwards = the request to the next hop. When receiving the corresponding answer the = agent checks whether it contains an OLR update and if so replaces the = stored info (if any) with the updated info, calculates an (aggregated) = realm-type OLR that fits to the supported features as received in the = request. In any case the agent replaces the OC-S-F in the answer with = its own OC-S-F (indicating the selected algorithm), removes the OC-OLR = from the answer and adds its own calculated aggregated realm-type OLR = (if any) to the answer before sending it to the previous hop. >=20 > F) When an agent that is configured to perform server selection for = realm-routed requests receives a realm-routed request that does not = contain an OC-S-F AVP, logically a combination of case D) followed by = case E) is performed. >=20 >=20 [...] > 10. clause 4. Overload Abatement Methods, 4th word: > Should read "server". Agent overload is out of scope. >=20 It is currently out of scope for the DOIC draft, but I believe it will = eventually become in-scope for the working group. I'd prefer to keep = things general to "node" in this section. =20 > 11. clause 4. Overload Abatement Method, 7th paragraph: > Diversion (which is limited to realm-routed requests) can only occur = at the Diameter Node that performs the server selection. Topology = knowledge is not needed. Overload state knowledge actually is pushed = further down the chain. The node can control how the received = realm-routed request is routed upstream by inserting a Destination-Host = AVP.=20 The knowledge that an agent performs server selection is, in itself, = topology knowledge. In general, a node (TC or agent) selects the next = hop. That hop might be a TS, or it might be an agent. There are = scenarios in which a node cannot know which it is (e.g. certain proxies = may be indistinguishable from servers.) I believe there are scenarios where an agent that is not the last hop = before the TS could be configured to do diversion. That requires the = "topology knowledge" that the set possible servers that might receive = the overloaded request do not overlap with the set of possible servers = that the request was diverted away from. I'm not saying those scenarios = are common, or even a good idea--just that DOIC should not forbid them. > 13. clause 5. DOIC Use Cases: > I have lots of detailed comments which I can share in a separate mail. = The essence is that all the use cases described should follow the = general principles A to F outlined above. It may be worth to totally = rewrite this clause to illustrate the general principles A to F. I disagree. Use cases drive behaviors, not the other way around. >=20 > 14. clause 6.1. General Recommendation, last paragraph: > This is not strictly required. Multiple occurrences of OC-OLR could be = regarded an an optimization. But then there are issues: when there are = two OLRs in one answer, e.g. one realm-type OLR for loss and one = host-type OLR for rate, we would also need two OC-S-F AVPs: one = indicating that loss is selected, and one indicating that rate is = selected. But this seems to be contradicting information. I don't think we can solve the need for realm-type reports without = allowing multiple OLRs. Once a server declares a host-overload = condition, it will continue to send the host-report in every single = answer until the overload condition ends. If the agent needs to insert a = realm-report, it will have no where to put it unless we either let it = remove one of the realm reports (which I think would be a bad idea) or = let it insert another one. I think it's worth discussion whether multiple OLRs in the same answer = are allowed to have different algorithms. (But this particular aspect of = that discussion would be a non-issue if the OLR included the selected = algorithm, as I have previously argued.) >=20 > 15. clause 6.2.1 Capabilities Exchange Behaviours, 3rd paragraph: > Should read: "An agent may act as a reporting node on behalf of a = non-supporting TS, or as reacting node on behalf of a non-supporting = TC.[Section 5.3]". I'm not sure whether we should cover the first case. = At least it should be limited to architectures where the agent (acting = as reporting node on behalf of the non supporting server) and the (non = supporting) server are immediate peers and the server has no other = immediate peers, so that the two nodes can be regarded a single = supporting server. What do we gain by that limitation? Keep in mind, we are not suggesting = that the DOIC draft specify how you build out networks--It should try = really hard to avoid that. We only propose that the specified agent = behaviors are flexible enough to handle the listed scenarios.=20 > 16. clause 6.2.1 Capabilities Exchange Behaviours, 4th paragraph: > To add some clarificatios this should read: > "An agent that acts as a reacting node must include an = OC-Supported-Features in each Diameter request that it forwards in that = role. If the inbound request included an OC-Supported-Features AVP, the = agent may copy its content to the one in the outbound request (this is = the case where the request is a) host-routed or b) realm-routed and the = agent is not configured to perform server selection), or may replace the = contents indicating the DOIC capabilities of the agent itself (this is = the case where the request is realm routed and the agent is configured = to perform server selection). If an inbound request does not contain an = OC-Supported-Features AVP, the agent must insert one into the outbound = request, indicating the DOIC capabilities of the agent itself." I think that goes into more details than we need to specifiy. = Specifically, I don't think the type of the request changes whether an = agent can change the supported features. >=20 > 17. clause 6.2.1 Capabilities Exchange Behaviours, last paragraph: > Should read: "An agent that does not support the DOIC mechanism is = likely to forward an OC-Supported-Features AVP without modification. A = DOIC node must be able to tell between an OC-Supported-Features AVP that = was inserted by a node within a trusted domain, and one inserted by a = node within a non-trusted domain.[Section 5.4]". This is because the = reporting node (if it sends an OLR within an answer) sends it's OLR to = the node that has inserted the OC-S-F AVP to the request. I think we agree in general (although I think the last sentence is = unnecessary.) But, until we have an end-to-end security mechanism (or = add one to DOIC, which I hope we don't do) , trust relationships are = really hop-by-hop. So the practical meaning is that you can tell the AVP = was inserted (or validated--more on that in a second) by the peer vs = something on the other side of that peer. When I say "validated", I am talking about potential transitive trust = relationship. That is, I know my peer supports DOIC, and I trust it to = only send me stuff that it generated itself, or that it received from a = peer that _it_ trusts. (and so on.) Since I can assume a peer that does _not_ support DOIC, will do neither, = it really comes down to knowing whether my peer supports DOIC or not. = Any further trust relationship has to be determined administratively.=20 >=20 > 18. clause 6.2.2 Overload Report Behaviours, 1st sentence, the part in = brackets: > I do not agree; when passing through, the responsibility is at the = source, not at the relay. The sentence should read: "When a = DOIC-supporting relay inserts or replaces an OC-Supported-Features AVP, = it becomes responsible for ensuring that any OLRs it receives from = upstream nodes are honored." I disagree. "Responsible for ensuring..." abatement is not the same as = "responsible for performing abatement". In your example, the agent = "ensures" abatement by delegating it to the source, which "performs" = abatement. In the context of a transaction, this is the only distinction between an = agent that supports DOIC, but forwards OC-S-F without change, and one = that does not support it at all. But I think the trust issues from the previous comment are going to make = this moot. If we are to distinguish a supporting agent from a = non-supporting one that simply forwards unknown AVPs, then supporting = agents are going to need to make _some_ modification to the OC-S-F prior = to forwarding it. For example, it may need to insert it's diameter = identity as a forwarding agent. If we go that route, there will be no = such thing as a _supporting_ agent forwarding an OC-S-F AVP without = change.) >=20 > 19. clause 6.2.2 Overload Report Behaviours, 2nd sentence: > If the abatement is not "Diversion" and "Delegation" is possible, = "Delegation" rather than "Throttling" must be done. Why is this a requirement? If someone wants to deploy an agent that = never delegates, we should not prevent them. I wouldn't build my network = that way, but don't see why the IETF should put anything more than = guidance about why delegation might be better. (That said, it would be perfectly reasonable for 3GPP to require = delegation whenever possible.) >=20 > 20. clause 6.2.2 Overload Report Behaviours, 2nd paragraph, last = sentence: > I do not agree. See also comment 11. Diversion is limited to = realm-routed requests and can only be performed by nodes that do the = server selection. These nodes can convert the realm-routed request to a = host-routed request. I agree that diversion typically cannot be done for host-routed = requests, but I don't think we can say it "never" can. There are = situations where an agent (or client) can divert host-routed requests. = For example, you might have more than one physical server that can = handle requests for the same Destination-Host value. Otherwise, I don't see how your text disagrees with the text in the = draft. >=20 > 21. clause 6.2.2 Overload Report Behaviours, 3rd paragraph, last = sentence: > Modifying OLRs must follow strict rules. We either have > a) one DOIC association betwee reacting node and reporting node where = all agents in between are transparent and do not modify OC-xxx AVPs, or=20= > b) two independent DOIC associations, one between reacting node and = agent (acting as reporting node) and one between the same agent (now = acting as reacting node) and reporting node. Here the agent removes the = received host-type OLR and inserts its own aggregated realm-type OLR. I = would not call this a modification but a replacement. Modifications = other than this may not be a good idea. I'm happy to call a modification a replacement. (Replacing an AVP with = one that is similar to the original but slightly different is = indistinguishable from modification.) But I don't think we (the IETF) = can specify any formal limitations on how an agent can modify any OC-XXX = without making perfectly reasonable network designs become illegal. = Again, it's perfectly reasonable for 3GPP to add additional constraints. (After working with Steve to put this draft together, I am no longer = convinced that the "DOIC association" is useful as a formal concept. ) >=20 > 22. clause 6.2.2 Overload Report Behaviours, last but one paragraph: > It is the other way round: > An agent shall not throttle traffic locally when it has already sent = (or will soon send) an OLR downstream (i.e. when it can or already has = delegated the abatement). When receiving a xxR that contains an OC-S-F = AVP (and the xxR matches an OLR) the agent can almost safely assume that = this request survived an ongoing throttling downstream. The principle is = that throttling should be done as close as possible to the client. Again, I don't think we should forbid either approach at the IETF. Doing = throttling as close to the client as possible is guidance, not a = normative rule. Or at least nothing stronger than SHOULD strength. (And again, 3GPP can add further constraints...) >=20 > Regards, > Ulrich >=20 >=20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve = Donovan > Sent: Saturday, July 05, 2014 9:49 PM > To: dime@ietf.org > Subject: [Dime] Fwd: New Version Notification for = draft-donovan-doic-agent-cases-00.txt >=20 > All, >=20 > The below referenced draft focuses on a number of DOIC deployment = scenarios involving agents. The goal of this draft is to identify any = new DOIC behaviors required to address these deployment scenarios. =20 >=20 > This directly addresses open issues #25, #27, #60 and #61 while = indirectly addressing other open issues. >=20 > Regards, >=20 > Steve >=20 > -------- Original Message --------=20 > Subject:=20 > New Version Notification for draft-donovan-doic-agent-cases-00.txt > Date:=20 > Thu, 03 Jul 2014 09:17:11 -0700 > From:=20 > internet-drafts@ietf.org > To:=20 > Ben Campbell , "Steve Donovan" = , Steve Donovan , = "Ben Campbell" >=20 > A new version of I-D, draft-donovan-doic-agent-cases-00.txt > has been successfully submitted by Steve Donovan and posted to the > IETF repository. >=20 > Name: draft-donovan-doic-agent-cases > Revision: 00 > Title: Analysis of Agent Use Cases for Diameter = Overload Information Conveyance (DOIC) > Document date: 2014-07-03 > Group: Individual Submission > Pages: 34 > URL: = http://www.ietf.org/internet-drafts/draft-donovan-doic-agent-cases-00.txt > Status: = https://datatracker.ietf.org/doc/draft-donovan-doic-agent-cases/ > Htmlized: = http://tools.ietf.org/html/draft-donovan-doic-agent-cases-00 >=20 >=20 > Abstract: > The Diameter Overload Information Conveyance (DOIC) solution > describes a mechanism for exchanging information about Diameter > Overload among Diameter nodes. A DOIC node is a Diameter node that > acts as either a reporting node are a reacting node. A reporting > node originates overload reports, requesting reacting nodes to = reduce > the amount of traffic sent. DOIC allows Diameter agents to act as > reporting nodes, reacting nodes, or both, but does not describe = agent > behavior. This document explores several use cases for agents to > participate in overload control, and makes recommendations for > certain agent behaviors to be added to DOIC. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Sun Jul 13 12:43:10 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174001A00E6 for ; Sun, 13 Jul 2014 12:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=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 I2-9lh02hnP2 for ; Sun, 13 Jul 2014 12:43:05 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 33C101A00E5 for ; Sun, 13 Jul 2014 12:43:05 -0700 (PDT) Received: from [41.164.142.123] (port=60336 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X6Pfn-00055A-0X; Sun, 13 Jul 2014 12:43:02 -0700 Message-ID: <53C2E13F.8070406@usdonovans.com> Date: Sun, 13 Jul 2014 21:42:55 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" References: <20140703161711.24974.27021.idtracker@ietfa.amsl.com> <53B85695.2010208@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151F77ED@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151F77ED@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/uFUefQlWBSZmJVWGXZGn7I_4oG8 Cc: "Rauschenbach, Uwe \(NSN - DE/Munich\)" Subject: Re: [Dime] Fwd: New Version Notification for draft-donovan-doic-agent-cases-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Jul 2014 19:43:08 -0000 Ulrich, Some comments inline. Steve On 7/11/14, 2:03 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > Here are my comments: > > 1. Abstract 2nd sentence: > The sentence should read: "A DOIC node is a Diameter node that in a giv= en context may act as a reporting node or a reacting node." > This is to align your definition "Any Diameter node that supports DOIC = is a DOIC node" (see 1. Introduction, last paragraph) with our common und= erstanding of the "end-to-end concept" which allows a DOIC node sitting b= etween a supporting client and a supporting server to be transparent. > > 2. clause 1.1 Terminology and Abbreviations, Abating node: > The definition should read: "A reacting node that locally performs over= load abatement (i.e. throttling or diversion but not delegation)." > > 3. lots of colons missing in clause 1.1 > > 4. clause 1.1 Terminology and Abbreviations, Overload Abatement: > The definition should read: "...... Overload abatement actions may invo= lve local traffic reduction, or delegation of actions towards the client = (Delegation). Local traffic reduction can be achieved by either rejecting= a request (Throttling) or by routing a request to a different destinatio= n (Diversion)." > > 5. clause 1.1 Terminology and Abbreviations, Diversion: > I propose to add the following clarification: > Diversion is specific to agents that perform server selection for realm= -routed requests. SRD> I disagree. Diversion is also a valid abatement action that can be = taken on realm-routed requests by a transaction client that has a direct = transport connection to an overloaded transaction server. > > 6. clause 1.1 Terminology and Abbreviations: > I propose to also define what Delegation is: > "Delegation: Overload abatement through the delegation of action (Throt= tling) to a further downstream reacting node. Delegation is specific to a= gents that perform server selection for realm-routed requests, and is typ= ically done when the agent detects that all available servers have reques= ted load reduction, i.e. when receiving an answer message in response to = a (not throttled) request that was forwarded to a selected server which i= n the answer reports an update of its overload information." > > 7. clause 2 Deployment Architectures > There are many more architectures and scenarios which cannot all be cov= ered separately. I therefore propose to focus on general principles that = DOIC agents must follow independent from architecture and scenario. These= principles are: SRD> I agree that we need to resolve to general principles, but they=20 need to address reasonable deployment architectures. We cannot, and do=20 not, know in advance the deployment architectures that will be=20 implemented by users of the Diameter protocol. In addition, we should=20 not knowingly limit those deployment architectures in the way the=20 protocol is designed. > > A) When an agent receives a host-routed request that contains an OC-S-F= AVP, it takes no DOIC-specific action, i.e. it forwards the request to t= he next hop without removing, modifying or inserting OC AVPs; also no DOI= C specific action is performed when receiving the corresponding answer. T= he agent may however store OLR information received in the answer for pot= ential later use if it supports the features associated with the OLR. SRD> I disagree. I think the draft shows multiple reasons where it=20 would be reasonable for an agent to modify OS-S-F AVPs in a request=20 message. > > B) When an agent receives a host-routed request that does not contain a= n OC-S-F AVP, it performs throttling according to a previously receive ho= st-type OLR (if any).If the request survives (or no throttling was perfor= med because no host-type OLR matched), the agent inserts an OC-S-F AVP an= d sends the request to the next hop. When receiving the corresponding ans= wer, the agent checks whether it contains an OLR update and if so replace= s the stored info (if any) with the updated info. In any case the agent r= emoves the OLR from the answer before sending it to the previous hop. SRD> The agent must have inserted OC-S-F AVPs in previous requests in=20 order to receive an OC-OLR in an answer. It feels like you are making=20 in much more complex than needed and are trying to constrain user's of=20 the Diameter protocol in the way overload can be handled. SRD> It can be kept simple -- If an agent receives a request --=20 realm-routed or host-routed -- that does not contain a OC-S-F AVP then=20 it SHOULD/MAP (strength of the requirement TBD) insert an OC-S-F AVP in=20 the request message. If local policy indicates that the agent is taking = on responsibility for handling overload for non supporting transaction=20 clients then the agent MUST insert an OC-S-F AVP in the request message. > > C) When an agent that is not configured to perform server selection for= realm-routed requests receives a realm-routed request that contains an O= C-S-F AVP, it takes no DOIC-specific action, i.e. it forwards the request= to the next hop without removing, modifying or inserting OC AVPs; also n= o DOIC specific action is performed when receiving the corresponding answ= er. The agent may however store OLR information received in the answer fo= r potential later use if it supports the features associated with the OLR= =2E SRD> There are scenarios where it should, based on local policy, modify=20 the OC-S-F AVP, this was shown in the draft. Why are you proposing to=20 limit how a user of Diameter can manage overload in their networks? Why = do you propose that the rate algorithm cannot be turned on when=20 transaction clients only support the loss algorithm? > > D) When an agent that is not configured to perform server selection for= realm-routed requests receives a realm-routed request that does not cont= ain an OC-S-F AVP, it performs throttling according to a previously recei= ve realm-type OLR (if any).If the request survives (or no throttling was = performed because no realm-type OLR matched), the agent inserts an OC-S-F= AVP and sends the request to the next hop. When receiving the correspond= ing answer, the agent checks whether it contains an OLR update and if so = replaces the stored info (if any) with the updated info. In any case the = agent removes the OLR from the answer before sending it to the previous h= op. SRD> I'm not sure this is a valid scenario. An agent that receives a=20 realm-routed request must be configured to perform server selection. =20 It's pretty useless otherwise. > > E) When an agent that is configured to perform server selection for rea= lm-routed requests receives a realm-routed request that contains an OC-S-= F AVP, it performs server selection, adds the Destination-Host AVP with t= he value identifying the selected server to the request (this need not be= done when the selected server is an immediate peer), replaces the receiv= ed OC-S-F AVP with its own OC-S-F AVP in the request and forwards the req= uest to the next hop. When receiving the corresponding answer the agent c= hecks whether it contains an OLR update and if so replaces the stored inf= o (if any) with the updated info, calculates an (aggregated) realm-type O= LR that fits to the supported features as received in the request. In any= case the agent replaces the OC-S-F in the answer with its own OC-S-F (in= dicating the selected algorithm), removes the OC-OLR from the answer and = adds its own calculated aggregated realm-type OLR (if any) to the answer = before sending it to the previous hop. SRD> On the service, this looks like the processing that should apply to = all realm-routed requests, independent of the presence or absence of=20 OC-S-F in the request. > > F) When an agent that is configured to perform server selection for rea= lm-routed requests receives a realm-routed request that does not contain = an OC-S-F AVP, logically a combination of case D) followed by case E) is = performed. SRD> Minus D). > > 8. clause 3. Diameter Routing, 3rd paragraph: > Should read: "In general, throttling (Section 4) is the only local abat= ement technique that works for host-routed requests. Diversion (Section 4= ) is typically not possible, since only a single TS can handle any given = host-routed request." SRD> Ok. > > 9. clause 3. Diameter Routing, last sentence: > Should read: "Since realm-routed requests are not bound to a particular= TS, it is often possible for the node that selects the server to divert = a number of them to other servers that are less overloaded." SRD> Ok. > > 10. clause 4. Overload Abatement Methods, 4th word: > Should read "server". Agent overload is out of scope. SRD> I agree with Ben's response here. Agent overload needs to be=20 addressed and we need to make sure that the base DOIC spec doesn't make=20 it impossible to add it in the future. > > 11. clause 4. Overload Abatement Method, 7th paragraph: > Diversion (which is limited to realm-routed requests) can only occur at= the Diameter Node that performs the server selection. Topology knowledge= is not needed. Overload state knowledge actually is pushed further down = the chain. The node can control how the received realm-routed request is = routed upstream by inserting a Destination-Host AVP. SRD> I have nothing to add to Ben's response. > > 12. clause 4. Overload Abatement Methods, last paragraph: > "lease" should read "least" > > 13. clause 5. DOIC Use Cases: > I have lots of detailed comments which I can share in a separate mail. = The essence is that all the use cases described should follow the general= principles A to F outlined above. It may be worth to totally rewrite thi= s clause to illustrate the general principles A to F. SRD> I don't agree with the general principles A to F so I don't agree=20 with this section. I also agree with Ben's response. The use cases=20 presented are all reasonable and the protocol needs to support them. We = should not be constraining how Diameter is used by limiting the=20 reasonable deployment scenarios. > > 14. clause 6.1. General Recommendation, last paragraph: > This is not strictly required. Multiple occurrences of OC-OLR could be = regarded an an optimization. But then there are issues: when there are tw= o OLRs in one answer, e.g. one realm-type OLR for loss and one host-type = OLR for rate, we would also need two OC-S-F AVPs: one indicating that los= s is selected, and one indicating that rate is selected. But this seems t= o be contradicting information. SRD> I agree that there is a constraint in the current DOIC spec that=20 would force all overload reports to apply to the same algorithm. We=20 need to make sure this is a reasonable constraint. I do not agree that=20 we can assume a single overload report in an answer message and the use=20 cases presented clearly show this to be the case. > > 15. clause 6.2.1 Capabilities Exchange Behaviours, 3rd paragraph: > Should read: "An agent may act as a reporting node on behalf of a non-s= upporting TS, or as reacting node on behalf of a non-supporting TC.[Secti= on 5.3]". I'm not sure whether we should cover the first case. At least i= t should be limited to architectures where the agent (acting as reporting= node on behalf of the non supporting server) and the (non supporting) se= rver are immediate peers and the server has no other immediate peers, so = that the two nodes can be regarded a single supporting server. SRD> I don't see the need for such a limitation. In the end, it should=20 be up to the operator of the Diameter network to determine how to manage = overload which includes which of those nodes are reporting nodes and=20 which of those nodes are reacting nodes. > > 16. clause 6.2.1 Capabilities Exchange Behaviours, 4th paragraph: > To add some clarificatios this should read: > "An agent that acts as a reacting node must include an OC-Supported-Fea= tures in each Diameter request that it forwards in that role. If the inbo= und request included an OC-Supported-Features AVP, the agent may copy its= content to the one in the outbound request (this is the case where the r= equest is a) host-routed or b) realm-routed and the agent is not configur= ed to perform server selection), or may replace the contents indicating t= he DOIC capabilities of the agent itself (this is the case where the requ= est is realm routed and the agent is configured to perform server selecti= on). If an inbound request does not contain an OC-Supported-Features AVP,= the agent must insert one into the outbound request, indicating the DOIC= capabilities of the agent itself." SRD> I agree with Ben's response. > > 17. clause 6.2.1 Capabilities Exchange Behaviours, last paragraph: > Should read: "An agent that does not support the DOIC mechanism is like= ly to forward an OC-Supported-Features AVP without modification. A DOIC n= ode must be able to tell between an OC-Supported-Features AVP that was in= serted by a node within a trusted domain, and one inserted by a node with= in a non-trusted domain.[Section 5.4]". This is because the reporting nod= e (if it sends an OLR within an answer) sends it's OLR to the node that h= as inserted the OC-S-F AVP to the request. > > 18. clause 6.2.2 Overload Report Behaviours, 1st sentence, the part in = brackets: > I do not agree; when passing through, the responsibility is at the sour= ce, not at the relay. The sentence should read: "When a DOIC-supporting r= elay inserts or replaces an OC-Supported-Features AVP, it becomes respons= ible for ensuring that any OLRs it receives from upstream nodes are honor= ed." > > 19. clause 6.2.2 Overload Report Behaviours, 2nd sentence: > If the abatement is not "Diversion" and "Delegation" is possible, "Dele= gation" rather than "Throttling" must be done. > > 20. clause 6.2.2 Overload Report Behaviours, 2nd paragraph, last senten= ce: > I do not agree. See also comment 11. Diversion is limited to realm-rout= ed requests and can only be performed by nodes that do the server selecti= on. These nodes can convert the realm-routed request to a host-routed req= uest. > > 21. clause 6.2.2 Overload Report Behaviours, 3rd paragraph, last senten= ce: > Modifying OLRs must follow strict rules. We either have > a) one DOIC association betwee reacting node and reporting node where a= ll agents in between are transparent and do not modify OC-xxx AVPs, or > b) two independent DOIC associations, one between reacting node and age= nt (acting as reporting node) and one between the same agent (now acting = as reacting node) and reporting node. Here the agent removes the received= host-type OLR and inserts its own aggregated realm-type OLR. I would not= call this a modification but a replacement. Modifications other than thi= s may not be a good idea. > > 22. clause 6.2.2 Overload Report Behaviours, last but one paragraph: > It is the other way round: > An agent shall not throttle traffic locally when it has already sent (o= r will soon send) an OLR downstream (i.e. when it can or already has dele= gated the abatement). When receiving a xxR that contains an OC-S-F AVP (a= nd the xxR matches an OLR) the agent can almost safely assume that this r= equest survived an ongoing throttling downstream. The principle is that t= hrottling should be done as close as possible to the client. SRD> I have nothing to add to Ben's comments on the above with the=20 exception that I also see little value to carrying the concept of a DOIC = Endpoint forward. Multiple Diameter nodes and and will need to perform=20 abatement on a single overload report. It won't only be an endpoint as=20 previously conceived that does so. > > Regards, > Ulrich > > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donova= n > Sent: Saturday, July 05, 2014 9:49 PM > To: dime@ietf.org > Subject: [Dime] Fwd: New Version Notification for draft-donovan-doic-ag= ent-cases-00.txt > > All, > > The below referenced draft focuses on a number of DOIC deployment scena= rios involving agents. The goal of this draft is to identify any new DOI= C behaviors required to address these deployment scenarios. > > This directly addresses open issues #25, #27, #60 and #61 while indirec= tly addressing other open issues. > > Regards, > > Steve > > -------- Original Message -------- > Subject: > New Version Notification for draft-donovan-doic-agent-cases-00.txt > Date: > Thu, 03 Jul 2014 09:17:11 -0700 > From: > internet-drafts@ietf.org > To: > Ben Campbell , "Steve Donovan" , Steve Donovan , "Ben Campbell" > > A new version of I-D, draft-donovan-doic-agent-cases-00.txt > has been successfully submitted by Steve Donovan and posted to the > IETF repository. > > Name: draft-donovan-doic-agent-cases > Revision: 00 > Title: Analysis of Agent Use Cases for Diameter Overload Information C= onveyance (DOIC) > Document date: 2014-07-03 > Group: Individual Submission > Pages: 34 > URL: http://www.ietf.org/internet-drafts/draft-donovan-doic-= agent-cases-00.txt > Status: https://datatracker.ietf.org/doc/draft-donovan-doic-age= nt-cases/ > Htmlized: http://tools.ietf.org/html/draft-donovan-doic-agent-cas= es-00 > > > Abstract: > The Diameter Overload Information Conveyance (DOIC) solution > describes a mechanism for exchanging information about Diameter > Overload among Diameter nodes. A DOIC node is a Diameter node that= > acts as either a reporting node are a reacting node. A reporting > node originates overload reports, requesting reacting nodes to redu= ce > the amount of traffic sent. DOIC allows Diameter agents to act as > reporting nodes, reacting nodes, or both, but does not describe age= nt > behavior. This document explores several use cases for agents to > participate in overload control, and makes recommendations for > certain agent behaviors to be added to DOIC. > > = =20 > > > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > From nobody Mon Jul 14 12:10:20 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDE31A0071 for ; Mon, 14 Jul 2014 12:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 3jD0qTCf5wr8 for ; Mon, 14 Jul 2014 12:10:15 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6A01A0053 for ; Mon, 14 Jul 2014 12:10:15 -0700 (PDT) Received: from BL2FFO11FD036.protection.gbl (10.173.160.34) by BL2FFO11HUB046.protection.gbl (10.173.161.122) with Microsoft SMTP Server (TLS) id 15.0.980.11; Mon, 14 Jul 2014 19:10:13 +0000 Received: from pdaasdm2.corp.sprint.com (144.229.32.57) by BL2FFO11FD036.mail.protection.outlook.com (10.173.161.132) with Microsoft SMTP Server (TLS) id 15.0.980.11 via Frontend Transport; Mon, 14 Jul 2014 19:10:13 +0000 Received: from plsasen1.corp.sprint.com (default-server.local [144.226.201.28]) by pdaasdm2.corp.sprint.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.2.2) with ESMTP id s6EJACVK017143 (version=TLSv1/SSLv3 cipher=ADH-AES256-SHA bits=256 verify=NO) for ; Mon, 14 Jul 2014 14:10:12 -0500 Received: from PREWE13M01.ad.sprint.com (prewe13m01.corp.sprint.com [144.226.128.20]) by plsasen1.corp.sprint.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.2.2) with ESMTP id s6EJABWq001392 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 14 Jul 2014 14:10:11 -0500 Received: from PREWE13M19.ad.sprint.com (2002:90e2:8026::90e2:8026) by PREWE13M01.ad.sprint.com (2002:90e2:8014::90e2:8014) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 14 Jul 2014 15:10:10 -0400 Received: from PREWE13M19.ad.sprint.com ([fe80::d43e:559c:727b:991a]) by PREWE13M19.ad.sprint.com ([fe80::d43e:559c:727b:991a%15]) with mapi id 15.00.0847.030; Mon, 14 Jul 2014 15:10:10 -0400 From: "Hirschman, Brent B [CTO]" To: "dime@ietf.org" Thread-Topic: [Dime] draft-ietf-dime-congestion-flow-attributes-00 Thread-Index: Ac+flzqlY8lmI3g6QrCFmcxNKIp54A== Date: Mon, 14 Jul 2014 19:10:09 +0000 Message-ID: <43b91d90d8db46ffab81474a1d583221@PREWE13M19.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.214.116.36] Content-Type: multipart/alternative; boundary="_000_43b91d90d8db46ffab81474a1d583221PREWE13M19adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:144.229.32.57; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438002)(189002)(199002)(584324001)(86362001)(19300405004)(33646001)(19625215002)(26826002)(85852003)(92566001)(87936001)(50986999)(54356999)(99396002)(71186001)(80022001)(81342001)(20776003)(79102001)(77982001)(110136001)(2351001)(81542001)(30436002)(64706001)(4396001)(76482001)(46102001)(106466001)(74502001)(16236675004)(83322001)(84326002)(15202345003)(77096002)(512954002)(83072002)(15975445006)(2656002)(107046002)(21056001)(6806004)(95666004)(31966008)(85306003)(74662001)(19580395003)(44976005)(108616002)(4546003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB046; H:pdaasdm2.corp.sprint.com; FPR:; MLV:ovrnspm; PTR:smtpda2.sprint.com; MX:1; A:1; LANG:en; X-OriginatorOrg: sprint.onmicrosoft.com X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02723F29C4 Received-SPF: Pass (: domain of sprint.com designates 144.229.32.57 as permitted sender) receiver=; client-ip=144.229.32.57; helo=pdaasdm2.corp.sprint.com; Authentication-Results: spf=pass (sender IP is 144.229.32.57) smtp.mailfrom=Brent.Hirschman@sprint.com; Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gTG1coJa4Vly7fzQt1zwMFSAyug Cc: "Rajagopal, Arun \[CTO\]" , "Sershen, Dan J \[CTO\]" Subject: Re: [Dime] draft-ietf-dime-congestion-flow-attributes-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 19:10:18 -0000 --_000_43b91d90d8db46ffab81474a1d583221PREWE13M19adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to encourage review of this draft prior to the Toronto meeting= . I have tried to raise awareness of the draft since London. If there are= no objections, I would propose that the draft be moved to WGLC immediately= following the Toronto meeting. Brent Hirschman Tech Dev Strategist III Sprint Corporation 6220 Sprint Parkway Overland Park, KS 66251 Office - 913-762-6736 Mobile - 913-593-6221 ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_43b91d90d8db46ffab81474a1d583221PREWE13M19adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would like to encour= age review of this draft prior to the Toronto meeting.  I have tried t= o raise awareness of the draft since London.  If there are no objectio= ns, I would propose that the draft be moved to WGLC immediately following the Toronto meeting.

 

Brent Hirschman

Tech Dev Strategist III

Sprint Corporation

6220 Sprint Parkway

Overland Park, KS 66251

Office – 913-762-6736

Mobile – 913-593-6221

 

 



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_43b91d90d8db46ffab81474a1d583221PREWE13M19adsprintcom_-- From nobody Mon Jul 14 13:33:30 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FB31A8BB2 for ; Mon, 14 Jul 2014 13:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 NlOdyeAcaTOx for ; Mon, 14 Jul 2014 13:33:21 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D88B81A0AA0 for ; Mon, 14 Jul 2014 13:33:20 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s6EKXINg011952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 Jul 2014 20:33:18 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s6EKXHOA005562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Jul 2014 22:33:18 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.93]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0181.006; Mon, 14 Jul 2014 22:33:17 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt Thread-Index: AQHPlvVsB56hVVSy3UODi6hlfxzXKpuRwvIAgA42/kA= Date: Mon, 14 Jul 2014 20:33:16 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> In-Reply-To: <53B8550C.4050206@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 8638 X-purgate-ID: 151667::1405369998-00007A71-7CCA5329/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/V_HlqF2ck86lKRB1MTM2xVeTbh8 Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 20:33:26 -0000 Hi Steve, here are my comments. They focus on new text you introduced. I agree that restructuring may requi= re new text, however, I believe that with the new text a new concepts is in= troduced which macerates the agreed end-to-end concept and allows all DOIC = agents on the path to do what they wants, so that we end up in a hop-by-hop= concept. 1. clause 2.3, second paragraph: Should read: "Reacting nodes indicate support for DOIC by including the OC-= Supported-Features AVP into all request messages originated or relayed by t= he Reacting node." 2. clause 2.3, 3rd paragraph, 1st sentence: OC-xxx AVPs must not be included in an answer message when the correspondin= g request did not contain an OC-S-F AVP. 3. clause 3.3, 7th paragraph: Should read "The reporting node only includes an indication of support for = one overload abatement algorithm. This is the algorithm that the reporting= node intends to use should it enter an overload condition or requests to u= se while it actually is in an overload condition. Reacting nodes can use th= e indicated overload abatement algorithm to prepare for possible overload r= eports and must use the indicated overload abatement algorithm if traffic r= eduction is actually requested." 4. clause 3.3, 10th paragraph: The 1st sentence is misleading. In the general case, agents on the path bet= ween reacting node and reporting node are transparent. I agree that there a= re exceptions to the general case where an agent on the path is not transpa= rent, but then the agent IS the reporting node (reporting to the sender of = the request) and it also IS the reacting node (reacting on reports received= from the upstream reporting node). =20 The first 3 words of the second sentence "in this case" need clarification:= "In the case where an agent takes the role of a reporting node (reporting = to the downstream reacting node) and at the same time takes the role of a r= eacting node (reacting on reports received from an upstream reporting node)= ". Last sentence: Its not an update but a replacement. The two DOIC associatio= ns are handled independently. 5. clause 3.3, last paragraph: General rules shall be followed for each of the two associations separately= . The content of the OC-S-F AVP sent by the agent upstream should reflect w= hat the agent is able and willing to support (as always). 6. clause 3.4, 2nd paragraph: Should read: "The OC-OLR AVP is referred to as an overload report. The OC-= OLR AVP includes the type of report, a sequence number, the length of time = that the report is valid and abatement algorithm specific AVPs." 7. clause 3.4, 4th paragraph, 2nd sentence: I cannot understand this sentence. Probably only simple typos but I don't k= now.=20 8. clause 3.4, 4th paragraph last 2 sentences: I don't understand and probably do not agree. 9. clause 3.5, 3rd paragraph, last word: Should read "communicated" 10. clause 3.5, 4th paragraph, 1st sentence: I don't understand. I can understand: "Reporting nodes use the OC-OLR AVP t= o communicate overload occurances towards reacting nodes." 11. clause 4.1, 3rd paragraph, last 4 words: may be misleading. A DOIC supporting agent sitting between DOIC supporting = client and DOIC supporting Server is transparent with regard to DOIC. This = agent does not indicate DOIC support. 12. clause 4.1, 4th paragraph, 2nd sentence: Should read:"If a request message handled by the DOIC agent does not includ= e the OC-Supported-Features AVP then the DOIC agent inserts the AVP." 13. clause 4.1, last sentence: Should read "If the message already has the AVP then the agent either leave= s it unchanged in the relayed message or replaces it to reflect the feature= s the agent is able and willing to support." Clarification is needed to say= that strict rules must be followed by the agent to select the correct opti= on. These rules take into account whether the request is host-routed or rel= am-routed and whether the agent is configured to select the server for real= m-routed requests. 14. clause 4.1.2, 2nd paragraph: Should read: "Based on the content of the OC-Supported-Features AVP in the = request message, the reporting node knows what overload control functionali= ty is supported by the reacting node. The reporting node then acts accordi= ngly for the subsequent answer messages it initiates for the transaction." =20 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: Should read: "message's" 16. clause 4.1, 6th paragraph: This should be left to the (future) specification that introduces other DOI= C features. 17. clause 4.1, 7th paragraph, last 6 words: should be based on requiements set by the (future) specification that intro= duces other DOIC features=20 18. clause 4.1, 8th paragraph, last sentence: Should read: "Lack of the OC-Supported-Features AVP in the request message = indicates that there is no downstream reacting node for the transaction." 19. clause 4.1, last sentence: Should read: "An agent MAY replace the OC-Supported-Features AVP carried in= answer messages." This replacement must follow general rules. Its not so t= hat the agent may do what ever it wants to. The decision must be based on w= hether or not the agent has replaced the OC-S-F in the corresponding reques= t. 20. clause 5.2, 1st sentence: Should read: "A reporting node using the loss algorithm must use the OC-Red= uction-Percentage AVP (Section 6.7) to indicated the desired percentage of = traffic reduction." 21. clause 5.2, last sentence: Should read: "Editor's note: The above duplicates what is in the OC-Reducti= on-Percentage AVP section and can probably be removed." 22. clause 5.4, 6th paragraph: Should read: "If the reacting node does not receive a an OLR in the answer = that corresponds to the probe request messages sent to the formally overloa= ded node then the reacting node should slowly increase the rate of traffic = sent to the overloaded node." Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Saturday, July 05, 2014 9:42 PM To: dime@ietf.org Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt All, This version of the DOIC draft is a restructuring of previously agreed=20 to content. The master plan for the restructuring is in Appendix C. This outlines=20 where material from -02 was moved in -03. For those interested, the work was done in steps, with a snapshot for=20 each step available here: https://github.com/jounikor/draft-docdt-dime-ovli Each step has the name draft-ietf-dime-ovli-03-nn-text.txt where nn indicates the subversion and "text" indicates the focus for=20 that subversion. The next step will be to resolve open issues already identified and=20 those yet those yet to be identified. Regards, Steve On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Diameter Maintenance and Extensions Wo= rking Group of the IETF. > > Title : Diameter Overload Indication Conveyance > Authors : Jouni Korhonen > Steve Donovan > Ben Campbell > Lionel Morand > Filename : draft-ietf-dime-ovli-03.txt > Pages : 48 > Date : 2014-07-03 > > Abstract: > This specification documents a Diameter Overload Control (DOC) base > solution and the dissemination of the overload report information. > > Requirements > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dime-ovli-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-ovli-03 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Mon Jul 14 21:37:54 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5DB1A02FA for ; Mon, 14 Jul 2014 21:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 7hct8dhgAWI0 for ; Mon, 14 Jul 2014 21:37:49 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5704E1A029D for ; Mon, 14 Jul 2014 21:37:49 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id et14so1109427pad.7 for ; Mon, 14 Jul 2014 21:37:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/po4OzoHUHrMscbRCiGflma1tDJ7zH5w8FNUtZ5s7K0=; b=AnTFZ24yh9wU3dzclptNrHe5vJHZOxuBUNp+AWwWsK/TQRn8VLOwocUPtLJRCFGNZS g1/ZllAaWfSMe5/Fj1A3qxNbpt1tbbW3f8VlZIyKs5JfQjw1+aAitulspLaCsYCAoKwx eg8edJr/oTZrtBergNPKRsLMtTiCSWFInbpaL67bFMEiLEuCiFdRKZxwVVADBFop0hES 3O+OxYztJTLrqcMqS9L++VC6mfHakfoP+f6rQ2pizDvIZNvlvT2o79R143DJyfrdnR/I dJAjhQgNgSVCmaIR/aJCiTo40XnKeLo0UXfj7CT6gbtpY9S33zM9llPNevb8mwK1bwO9 TY5g== X-Received: by 10.70.131.134 with SMTP id om6mr20395720pdb.95.1405399068969; Mon, 14 Jul 2014 21:37:48 -0700 (PDT) Received: from [10.100.20.19] ([63.133.199.244]) by mx.google.com with ESMTPSA id q7sm16787856pdm.17.2014.07.14.21.37.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 14 Jul 2014 21:37:47 -0700 (PDT) Message-ID: <53C4B019.5060305@gmail.com> Date: Tue, 15 Jul 2014 07:37:45 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Hirschman, Brent B [CTO]" , "dime@ietf.org" References: <43b91d90d8db46ffab81474a1d583221@PREWE13M19.ad.sprint.com> In-Reply-To: <43b91d90d8db46ffab81474a1d583221@PREWE13M19.ad.sprint.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KDYKaHG-W9yBNyFfY0qeI_ZTbbM Cc: "Rajagopal, Arun \[CTO\]" , "Sershen, Dan J \[CTO\]" Subject: Re: [Dime] draft-ietf-dime-congestion-flow-attributes-00 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 04:37:51 -0000 I read the document. The general feeling is that the document is more or less ready. There is one thing that I think would improved the document: a couple of examples showing the use cases listed/discussed in the document already. It also would not harm stating in IANA considerations that *no* new registry is created for the ECN-IP-Codepoint AVP. - Jouni 7/14/2014 10:10 PM, Hirschman, Brent B [CTO] kirjoitti: > I would like to encourage review of this draft prior to the Toronto > meeting. I have tried to raise awareness of the draft since London. If > there are no objections, I would propose that the draft be moved to WGLC > immediately following the Toronto meeting. > > */Brent Hirschman/* > > Tech Dev Strategist III > > Sprint Corporation > > 6220 Sprint Parkway > > Overland Park, KS 66251// > > Office – 913-762-6736 > > Mobile – 913-593-6221 > > > ------------------------------------------------------------------------ > > This e-mail may contain Sprint proprietary information intended for the > sole use of the recipient(s). Any use by others is prohibited. If you > are not the intended recipient, please contact the sender and delete all > copies of the message. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Tue Jul 15 01:36:23 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CCD1A001A for ; Tue, 15 Jul 2014 01:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 BSFkTQKgWAFo for ; Tue, 15 Jul 2014 01:36:17 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9EE1A0368 for ; Tue, 15 Jul 2014 01:36:16 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s6F8aDBc031797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Jul 2014 08:36:13 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s6F8aADQ002917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jul 2014 10:36:10 +0200 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 15 Jul 2014 10:36:10 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.93]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0181.006; Tue, 15 Jul 2014 10:36:10 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Ben Campbell , "dime@ietf.org" Thread-Topic: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt Thread-Index: AQHPnVRNpme7ahOAGUKc60BfufTrZJuguhCA Date: Tue, 15 Jul 2014 08:36:09 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151FDA48@DEMUMBX014.nsn-intra.net> References: <20140703161711.24974.27021.idtracker@ietfa.amsl.com> <53B85695.2010208@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151F77ED@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.113] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 22063 X-purgate-ID: 151667::1405413373-000005B1-653450F1/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/QM-hiob2oUHJifHuUHZGsxckqxY Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 08:36:21 -0000 Hi Ben, please see inline, Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell Sent: Saturday, July 12, 2014 12:06 AM To: dime@ietf.org Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-c= ases-00.txt Hi Ulrich, Thanks for the feedback! We intended this draft as more of a discussion paper than something that th= e working group would publish. I will respond to some of your substantive c= omments inline. If we publish a new revision at some point, we can address = the editorial and clarification comments at that time. Thanks! Ben. On Jul 11, 2014, at 7:03 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: [...] > 7. clause 2 Deployment Architectures > There are many more architectures and scenarios which cannot all be cover= ed separately. I therefore propose to focus on general principles that DOIC= agents must follow independent from architecture and scenario. These princ= iples are: I agree the scenarios in the draft are not exhaustive. We picked some that = we think exercise certain behaviors, that are discussed in the scenarios an= d in the recommendations section. I believe they are all reasonable scenari= os that DOIC should allow. [Wiehe, Ulrich (NSN - DE/Munich)] I'm ok with limited non-exhaustive exampl= e scenarios as long as A) to F) is followed. >=20 > A) When an agent receives a host-routed request that contains an OC-S-F A= VP, it takes no DOIC-specific action, i.e. it forwards the request to the n= ext hop without removing, modifying or inserting OC AVPs; also no DOIC spec= ific action is performed when receiving the corresponding answer. The agent= may however store OLR information received in the answer for potential lat= er use if it supports the features associated with the OLR. Do I understand correctly that you mean that an agent MUST NOT remove or mo= dify the OC-S-F from host routed requests? If so, I disagree. There are rea= l world scenarios that will require that modification or removal. (For exam= ple, those in section 5.2) [Wiehe, Ulrich (NSN - DE/Munich)] yes, you understand correctly, and no I d= o not agree with your "real world scenarios". >=20 > B) When an agent receives a host-routed request that does not contain an = OC-S-F AVP, it performs throttling according to a previously receive host-t= ype OLR (if any).If the request survives (or no throttling was performed be= cause no host-type OLR matched), the agent inserts an OC-S-F AVP and sends = the request to the next hop. When receiving the corresponding answer, the a= gent checks whether it contains an OLR update and if so replaces the stored= info (if any) with the updated info. In any case the agent removes the OLR= from the answer before sending it to the previous hop. I agree in general, although I think we can separate the " what if this req= uest gets throttled" behaviors from the "how you treat OC-S-F in forwarded = requests" aspects. >=20 > C) When an agent that is not configured to perform server selection for r= ealm-routed requests receives a realm-routed request that contains an OC-S-= F AVP, it takes no DOIC-specific action, i.e. it forwards the request to th= e next hop without removing, modifying or inserting OC AVPs; also no DOIC s= pecific action is performed when receiving the corresponding answer. The ag= ent may however store OLR information received in the answer for potential = later use if it supports the features associated with the OLR. >=20 > D) When an agent that is not configured to perform server selection for r= ealm-routed requests receives a realm-routed request that does not contain = an OC-S-F AVP, it performs throttling according to a previously receive rea= lm-type OLR (if any).If the request survives (or no throttling was performe= d because no realm-type OLR matched), the agent inserts an OC-S-F AVP and s= ends the request to the next hop. When receiving the corresponding answer, = the agent checks whether it contains an OLR update and if so replaces the s= tored info (if any) with the updated info. In any case the agent removes th= e OLR from the answer before sending it to the previous hop. >=20 > E) When an agent that is configured to perform server selection for realm= -routed requests receives a realm-routed request that contains an OC-S-F AV= P, it performs server selection, adds the Destination-Host AVP with the val= ue identifying the selected server to the request (this need not be done wh= en the selected server is an immediate peer), replaces the received OC-S-F = AVP with its own OC-S-F AVP in the request and forwards the request to the = next hop. When receiving the corresponding answer the agent checks whether = it contains an OLR update and if so replaces the stored info (if any) with = the updated info, calculates an (aggregated) realm-type OLR that fits to th= e supported features as received in the request. In any case the agent repl= aces the OC-S-F in the answer with its own OC-S-F (indicating the selected = algorithm), removes the OC-OLR from the answer and adds its own calculated = aggregated realm-type OLR (if any) to the answer before sending it to the p= revious hop. >=20 > F) When an agent that is configured to perform server selection for realm= -routed requests receives a realm-routed request that does not contain an O= C-S-F AVP, logically a combination of case D) followed by case E) is perfor= med. >=20 >=20 [...] > 10. clause 4. Overload Abatement Methods, 4th word: > Should read "server". Agent overload is out of scope. >=20 It is currently out of scope for the DOIC draft, but I believe it will even= tually become in-scope for the working group. I'd prefer to keep things gen= eral to "node" in this section. =20 [Wiehe, Ulrich (NSN - DE/Munich)] I'd prefer to keep things consistent.=20 > 11. clause 4. Overload Abatement Method, 7th paragraph: > Diversion (which is limited to realm-routed requests) can only occur at t= he Diameter Node that performs the server selection. Topology knowledge is = not needed. Overload state knowledge actually is pushed further down the ch= ain. The node can control how the received realm-routed request is routed u= pstream by inserting a Destination-Host AVP.=20 The knowledge that an agent performs server selection is, in itself, topolo= gy knowledge. In general, a node (TC or agent) selects the next hop. That h= op might be a TS, or it might be an agent. There are scenarios in which a n= ode cannot know which it is (e.g. certain proxies may be indistinguishable = from servers.) I believe there are scenarios where an agent that is not the last hop befo= re the TS could be configured to do diversion. That requires the "topology = knowledge" that the set possible servers that might receive the overloaded = request do not overlap with the set of possible servers that the request wa= s diverted away from. I'm not saying those scenarios are common, or even a = good idea--just that DOIC should not forbid them. [Wiehe, Ulrich (NSN - DE/Munich)] "topology knowlege" seems to be too gener= al; all that is needed is knowledge whether or not the server is selected.= A non-DOIC agents may not be able to know whether the selected next hop is= a server or not (i.e. it selecst a server but is aware of this), DOIC-agen= ts need to be aware. > 13. clause 5. DOIC Use Cases: > I have lots of detailed comments which I can share in a separate mail. Th= e essence is that all the use cases described should follow the general pri= nciples A to F outlined above. It may be worth to totally rewrite this clau= se to illustrate the general principles A to F. I disagree. Use cases drive behaviors, not the other way around. [Wiehe, Ulrich (NSN - DE/Munich)] The agent cannot arbitrarily chose the us= e case. The use case is determined by a) request being host-routed or realm-routed b) request containing/not containing an OC-S-F AVP c) agent is configured to select the server for realm-routed requests >=20 > 14. clause 6.1. General Recommendation, last paragraph: > This is not strictly required. Multiple occurrences of OC-OLR could be re= garded an an optimization. But then there are issues: when there are two OL= Rs in one answer, e.g. one realm-type OLR for loss and one host-type OLR fo= r rate, we would also need two OC-S-F AVPs: one indicating that loss is sel= ected, and one indicating that rate is selected. But this seems to be contr= adicting information. I don't think we can solve the need for realm-type reports without allowing= multiple OLRs. Once a server declares a host-overload condition, it will c= ontinue to send the host-report in every single answer until the overload c= ondition ends. If the agent needs to insert a realm-report, it will have no= where to put it unless we either let it remove one of the realm reports (w= hich I think would be a bad idea) or let it insert another one. [Wiehe, Ulrich (NSN - DE/Munich)] I think it's a good idea to let the agent= remove THE host-report and insert A realm-report. This reflects the princi= ple of DOIC associations. I think it's worth discussion whether multiple OLRs in the same answer are = allowed to have different algorithms. (But this particular aspect of that d= iscussion would be a non-issue if the OLR included the selected algorithm, = as I have previously argued.) [Wiehe, Ulrich (NSN - DE/Munich)] I would agree to have the selected algo w= ithin the OC-OLR rather than within the OC-S-F. This makes it easier to all= ow multiple OLRs, but again: I don't think it is strictly required to have = multiple OLRs in the answer. >=20 > 15. clause 6.2.1 Capabilities Exchange Behaviours, 3rd paragraph: > Should read: "An agent may act as a reporting node on behalf of a non-sup= porting TS, or as reacting node on behalf of a non-supporting TC.[Section 5= .3]". I'm not sure whether we should cover the first case. At least it shou= ld be limited to architectures where the agent (acting as reporting node on= behalf of the non supporting server) and the (non supporting) server are i= mmediate peers and the server has no other immediate peers, so that the two= nodes can be regarded a single supporting server. What do we gain by that limitation? Keep in mind, we are not suggesting tha= t the DOIC draft specify how you build out networks--It should try really h= ard to avoid that. We only propose that the specified agent behaviors are f= lexible enough to handle the listed scenarios.=20 [Wiehe, Ulrich (NSN - DE/Munich)] This limitation is needed to avoid lots o= f problems. > 16. clause 6.2.1 Capabilities Exchange Behaviours, 4th paragraph: > To add some clarificatios this should read: > "An agent that acts as a reacting node must include an OC-Supported-Featu= res in each Diameter request that it forwards in that role. If the inbound = request included an OC-Supported-Features AVP, the agent may copy its conte= nt to the one in the outbound request (this is the case where the request i= s a) host-routed or b) realm-routed and the agent is not configured to perf= orm server selection), or may replace the contents indicating the DOIC capa= bilities of the agent itself (this is the case where the request is realm r= outed and the agent is configured to perform server selection). If an inbou= nd request does not contain an OC-Supported-Features AVP, the agent must in= sert one into the outbound request, indicating the DOIC capabilities of the= agent itself." I think that goes into more details than we need to specifiy. Specifically,= I don't think the type of the request changes whether an agent can change = the supported features. [Wiehe, Ulrich (NSN - DE/Munich)] Ist the other way rond: An agent that sel= ects the server changes the type of request (from realm-routed to host-rout= ed). It terminates the DOIC association downstream and opens a new DOIC ass= ociation upstream, and therefore replaces the supported features. >=20 > 17. clause 6.2.1 Capabilities Exchange Behaviours, last paragraph: > Should read: "An agent that does not support the DOIC mechanism is likely= to forward an OC-Supported-Features AVP without modification. A DOIC node = must be able to tell between an OC-Supported-Features AVP that was inserted= by a node within a trusted domain, and one inserted by a node within a non= -trusted domain.[Section 5.4]". This is because the reporting node (if it s= ends an OLR within an answer) sends it's OLR to the node that has inserted = the OC-S-F AVP to the request. I think we agree in general (although I think the last sentence is unnecess= ary.) But, until we have an end-to-end security mechanism (or add one to DO= IC, which I hope we don't do) , trust relationships are really hop-by-hop. = So the practical meaning is that you can tell the AVP was inserted (or vali= dated--more on that in a second) by the peer vs something on the other side= of that peer. When I say "validated", I am talking about potential transitive trust relat= ionship. That is, I know my peer supports DOIC, and I trust it to only send= me stuff that it generated itself, or that it received from a peer that _i= t_ trusts. (and so on.) Since I can assume a peer that does _not_ support DOIC, will do neither, it= really comes down to knowing whether my peer supports DOIC or not. Any fur= ther trust relationship has to be determined administratively.=20 >=20 > 18. clause 6.2.2 Overload Report Behaviours, 1st sentence, the part in br= ackets: > I do not agree; when passing through, the responsibility is at the source= , not at the relay. The sentence should read: "When a DOIC-supporting relay= inserts or replaces an OC-Supported-Features AVP, it becomes responsible f= or ensuring that any OLRs it receives from upstream nodes are honored." I disagree. "Responsible for ensuring..." abatement is not the same as "res= ponsible for performing abatement". In your example, the agent "ensures" ab= atement by delegating it to the source, which "performs" abatement. In the context of a transaction, this is the only distinction between an ag= ent that supports DOIC, but forwards OC-S-F without change, and one that do= es not support it at all. [Wiehe, Ulrich (NSN - DE/Munich)] The concept of end-to-end piggybacking en= sures that non-DOIC agents ensure abatement by delegation without being awa= re of it. But I think the trust issues from the previous comment are going to make th= is moot. If we are to distinguish a supporting agent from a non-supporting = one that simply forwards unknown AVPs, then supporting agents are going to = need to make _some_ modification to the OC-S-F prior to forwarding it. For = example, it may need to insert it's diameter identity as a forwarding agent= . If we go that route, there will be no such thing as a _supporting_ agent = forwarding an OC-S-F AVP without change.) [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. A supporting agent may de= cide to be transparent (see e.g. A) above). If so, it forwards OC-S-F witho= ut change (without modifying the identity of the node that inserted the OC-= S-F (if we decide that the OC-S-F must include the identity of the node tha= t inserts the OC-S-F)).=20 >=20 > 19. clause 6.2.2 Overload Report Behaviours, 2nd sentence: > If the abatement is not "Diversion" and "Delegation" is possible, "Delega= tion" rather than "Throttling" must be done. Why is this a requirement? If someone wants to deploy an agent that never d= elegates, we should not prevent them. I wouldn't build my network that way,= but don't see why the IETF should put anything more than guidance about wh= y delegation might be better. (That said, it would be perfectly reasonable for 3GPP to require delegation= whenever possible.) >=20 > 20. clause 6.2.2 Overload Report Behaviours, 2nd paragraph, last sentence= : > I do not agree. See also comment 11. Diversion is limited to realm-routed= requests and can only be performed by nodes that do the server selection. = These nodes can convert the realm-routed request to a host-routed request. I agree that diversion typically cannot be done for host-routed requests, b= ut I don't think we can say it "never" can. There are situations where an a= gent (or client) can divert host-routed requests. For example, you might ha= ve more than one physical server that can handle requests for the same Dest= ination-Host value. Otherwise, I don't see how your text disagrees with the text in the draft. >=20 > 21. clause 6.2.2 Overload Report Behaviours, 3rd paragraph, last sentence= : > Modifying OLRs must follow strict rules. We either have > a) one DOIC association betwee reacting node and reporting node where all= agents in between are transparent and do not modify OC-xxx AVPs, or=20 > b) two independent DOIC associations, one between reacting node and agent= (acting as reporting node) and one between the same agent (now acting as r= eacting node) and reporting node. Here the agent removes the received host-= type OLR and inserts its own aggregated realm-type OLR. I would not call th= is a modification but a replacement. Modifications other than this may not = be a good idea. I'm happy to call a modification a replacement. (Replacing an AVP with one = that is similar to the original but slightly different is indistinguishable= from modification.) But I don't think we (the IETF) can specify any formal= limitations on how an agent can modify any OC-XXX without making perfectly= reasonable network designs become illegal. Again, it's perfectly reasonabl= e for 3GPP to add additional constraints. (After working with Steve to put this draft together, I am no longer convin= ced that the "DOIC association" is useful as a formal concept. ) [Wiehe, Ulrich (NSN - DE/Munich)] The principle of DOIC associations is fun= damental for the end-to-end piggybacking concept. This principle has been a= greed and we should stick with it. >=20 > 22. clause 6.2.2 Overload Report Behaviours, last but one paragraph: > It is the other way round: > An agent shall not throttle traffic locally when it has already sent (or = will soon send) an OLR downstream (i.e. when it can or already has delegate= d the abatement). When receiving a xxR that contains an OC-S-F AVP (and the= xxR matches an OLR) the agent can almost safely assume that this request s= urvived an ongoing throttling downstream. The principle is that throttling = should be done as close as possible to the client. Again, I don't think we should forbid either approach at the IETF. Doing th= rottling as close to the client as possible is guidance, not a normative ru= le. Or at least nothing stronger than SHOULD strength. (And again, 3GPP can add further constraints...) >=20 > Regards, > Ulrich >=20 >=20 > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan > Sent: Saturday, July 05, 2014 9:49 PM > To: dime@ietf.org > Subject: [Dime] Fwd: New Version Notification for draft-donovan-doic-agen= t-cases-00.txt >=20 > All, >=20 > The below referenced draft focuses on a number of DOIC deployment scenari= os involving agents. The goal of this draft is to identify any new DOIC be= haviors required to address these deployment scenarios. =20 >=20 > This directly addresses open issues #25, #27, #60 and #61 while indirectl= y addressing other open issues. >=20 > Regards, >=20 > Steve >=20 > -------- Original Message --------=20 > Subject:=20 > New Version Notification for draft-donovan-doic-agent-cases-00.txt > Date:=20 > Thu, 03 Jul 2014 09:17:11 -0700 > From:=20 > internet-drafts@ietf.org > To:=20 > Ben Campbell , "Steve Donovan" , Steve Donovan , "Ben Campbell" >=20 > A new version of I-D, draft-donovan-doic-agent-cases-00.txt > has been successfully submitted by Steve Donovan and posted to the > IETF repository. >=20 > Name: draft-donovan-doic-agent-cases > Revision: 00 > Title: Analysis of Agent Use Cases for Diameter Overload Information Con= veyance (DOIC) > Document date: 2014-07-03 > Group: Individual Submission > Pages: 34 > URL: http://www.ietf.org/internet-drafts/draft-donovan-doic-ag= ent-cases-00.txt > Status: https://datatracker.ietf.org/doc/draft-donovan-doic-agent= -cases/ > Htmlized: http://tools.ietf.org/html/draft-donovan-doic-agent-cases= -00 >=20 >=20 > Abstract: > The Diameter Overload Information Conveyance (DOIC) solution > describes a mechanism for exchanging information about Diameter > Overload among Diameter nodes. A DOIC node is a Diameter node that > acts as either a reporting node are a reacting node. A reporting > node originates overload reports, requesting reacting nodes to reduce > the amount of traffic sent. DOIC allows Diameter agents to act as > reporting nodes, reacting nodes, or both, but does not describe agent > behavior. This document explores several use cases for agents to > participate in overload control, and makes recommendations for > certain agent behaviors to be added to DOIC. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Tue Jul 15 05:16:27 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3C71B2873 for ; Tue, 15 Jul 2014 05:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=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 so-CMl4Czqnq for ; Tue, 15 Jul 2014 05:16:24 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 4391E1B2879 for ; Tue, 15 Jul 2014 05:16:23 -0700 (PDT) Received: from [41.0.204.98] (port=56948 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X71ef-0004qs-IX for dime@ietf.org; Tue, 15 Jul 2014 05:16:22 -0700 Message-ID: <53C51B93.4060505@usdonovans.com> Date: Tue, 15 Jul 2014 14:16:19 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <20140703161711.24974.27021.idtracker@ietfa.amsl.com> <53B85695.2010208@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151F77ED@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151FDA48@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151FDA48@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Iq1uGlZCGM03mqaa2gV24yhqMk0 Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 12:16:25 -0000 Ulrich, Can you be specific on which of the use cases in the specification do not need to be supported by the DOIC solution? Thanks, Steve > Do I understand correctly that you mean that an agent MUST NOT remove or modify the OC-S-F from host routed requests? If so, I disagree. There are real world scenarios that will require that modification or removal. (For example, those in section 5.2) > [Wiehe, Ulrich (NSN - DE/Munich)] yes, you understand correctly, and no I do not agree with your "real world scenarios". > From nobody Tue Jul 15 06:53:09 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6CD1A0564 for ; Tue, 15 Jul 2014 06:53:06 -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, SPF_NEUTRAL=0.779] autolearn=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 UOMvwsaXL5Io for ; Tue, 15 Jul 2014 06:53:02 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 79B881A03CE for ; Tue, 15 Jul 2014 06:53:02 -0700 (PDT) Received: from [41.0.204.98] (port=58678 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X73A6-00016M-VZ for dime@ietf.org; Tue, 15 Jul 2014 06:53:01 -0700 Message-ID: <53C53234.9090007@usdonovans.com> Date: Tue, 15 Jul 2014 15:52:52 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/tFswVdsTudgILTiv83n0fTgf2Q8 Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 13:53:07 -0000 Ulrich, Thanks for the comments. Please see my responses inline. Regards, Steve On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Hi Steve, > here are my comments. > They focus on new text you introduced. I agree that restructuring may require new text, however, I believe that with the new text a new concepts is introduced which macerates the agreed end-to-end concept and allows all DOIC agents on the path to do what they wants, so that we end up in a hop-by-hop concept. SRD> We have never had an agreement on end-to-end versus hop-by-hop and I believe that we will end up with a hybrid of the two. We have open issues on agent behavior that Ben and I are attempting to address with the agent cases draft. SRD> That said, this type of restructuring of the document is likely to put agreed to behavior in a new light. If there are cases where I have implied changes to agreed to normative behavior, or if the informative text is not accurate, then these things need to be corrected. > > 1. clause 2.3, second paragraph: > Should read: "Reacting nodes indicate support for DOIC by including the OC-Supported-Features AVP into all request messages originated or relayed by the Reacting node." SRD> You mean clause 3.2. I agree with the change. > > 2. clause 2.3, 3rd paragraph, 1st sentence: > OC-xxx AVPs must not be included in an answer message when the corresponding request did not contain an OC-S-F AVP. SRD> Agreed. > > 3. clause 3.3, 7th paragraph: > Should read "The reporting node only includes an indication of support for one overload abatement algorithm. This is the algorithm that the reporting node intends to use should it enter an overload condition or requests to use while it actually is in an overload condition. Reacting nodes can use the indicated overload abatement algorithm to prepare for possible overload reports and must use the indicated overload abatement algorithm if traffic reduction is actually requested." SRD. OK. > > 4. clause 3.3, 10th paragraph: > The 1st sentence is misleading. In the general case, agents on the path between reacting node and reporting node are transparent. I agree that there are exceptions to the general case where an agent on the path is not transparent, but then the agent IS the reporting node (reporting to the sender of the request) and it also IS the reacting node (reacting on reports received from the upstream reporting node). > The first 3 words of the second sentence "in this case" need clarification: "In the case where an agent takes the role of a reporting node (reporting to the downstream reacting node) and at the same time takes the role of a reacting node (reacting on reports received from an upstream reporting node)". > Last sentence: Its not an update but a replacement. The two DOIC associations are handled independently. SRD> I don't know what you mean when you say an agent is transparent. Agents must take an active role in even the most basic case for overload handling to work, so they cannot be transparent. > > 5. clause 3.3, last paragraph: > General rules shall be followed for each of the two associations separately. The content of the OC-S-F AVP sent by the agent upstream should reflect what the agent is able and willing to support (as always). SRD> What two associations? Is there one association (end-to-end) or is the an association on both sides of the agent (hop-by-hop)? Or is there an association that involves three entities, the reporting node, an agent reacting node for realm-routed requests and a transaction-client reporting node for handling host-routed requests? > > 6. clause 3.4, 2nd paragraph: > Should read: "The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP includes the type of report, a sequence number, the length of time that the report is valid and abatement algorithm specific AVPs." SRD> The sequence number is being used as an overload report ID. I can make the change but I don't see it as necessary. > > 7. clause 3.4, 4th paragraph, 2nd sentence: > I cannot understand this sentence. Probably only simple typos but I don't know. SRD> Yes, a typo (this instead of the) and awkward wording. How about "This applies to requests that contain the Destination-Host AVP with a DiameterIdentity that matches the overload report. > > 8. clause 3.4, 4th paragraph last 2 sentences: > I don't understand and probably do not agree. SRD> See above. > > 9. clause 3.5, 3rd paragraph, last word: > Should read "communicated" SRD> Agreed. > > 10. clause 3.5, 4th paragraph, 1st sentence: > I don't understand. I can understand: "Reporting nodes use the OC-OLR AVP to communicate overload occurances towards reacting nodes." SRD> Who else would reports be sent to? > > 11. clause 4.1, 3rd paragraph, last 4 words: > may be misleading. A DOIC supporting agent sitting between DOIC supporting client and DOIC supporting Server is transparent with regard to DOIC. This agent does not indicate DOIC support. SRD> I disagree. > > 12. clause 4.1, 4th paragraph, 2nd sentence: > Should read:"If a request message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent inserts the AVP." SRD> That is what it already says. > > 13. clause 4.1, last sentence: > Should read "If the message already has the AVP then the agent either leaves it unchanged in the relayed message or replaces it to reflect the features the agent is able and willing to support." Clarification is needed to say that strict rules must be followed by the agent to select the correct option. These rules take into account whether the request is host-routed or relam-routed and whether the agent is configured to select the server for realm-routed requests. SRD> This is a topic on agent behavior that is addressed in the agent cases draft. I'll leave the discussion for what the wording should be to the discussion on that draft. > > 14. clause 4.1.2, 2nd paragraph: > Should read: "Based on the content of the OC-Supported-Features AVP in the request message, the reporting node knows what overload control functionality is supported by the reacting node. The reporting node then acts accordingly for the subsequent answer messages it initiates for the transaction." SRD> It would be easier if you didn't make it difficult to understand the change you are proposing. I think you are proposing changing node(s) to node. I don't agree but that will be addressed as part of the agent cases discussion. > > 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: > Should read: "message's" SRD> I'm assuming you mean section 4.1.2. I agree to the change. > > 16. clause 4.1, 6th paragraph: > This should be left to the (future) specification that introduces other DOIC features. > > 17. clause 4.1, 7th paragraph, last 6 words: > should be based on requiements set by the (future) specification that introduces other DOIC features SRD> Again, clause 4.1.2 -- I don't understand the issue when these two paragraphs are taken together. > > 18. clause 4.1, 8th paragraph, last sentence: > Should read: "Lack of the OC-Supported-Features AVP in the request message indicates that there is no downstream reacting node for the transaction." SRD> I think you mean clause 4.1.2. I don't see the need for the change. > > 19. clause 4.1, last sentence: > Should read: "An agent MAY replace the OC-Supported-Features AVP carried in answer messages." This replacement must follow general rules. Its not so that the agent may do what ever it wants to. The decision must be based on whether or not the agent has replaced the OC-S-F in the corresponding request. SRD> What is the difference between modify and replace? I am ok with removing this statement until we have the agent behavior discussion. I thought I had taken the agent specific statements out of this version. > > 20. clause 5.2, 1st sentence: > Should read: "A reporting node using the loss algorithm must use the OC-Reduction-Percentage AVP (Section 6.7) to indicated the desired percentage of traffic reduction." SRD> Agreed. > > 21. clause 5.2, last sentence: > Should read: "Editor's note: The above duplicates what is in the OC-Reduction-Percentage AVP section and can probably be removed." SRD> Yes, bad wording. The note will be removed, bad wording and all, once there is a discussion on if this is redundant. > > 22. clause 5.4, 6th paragraph: > Should read: "If the reacting node does not receive a an OLR in the answer that corresponds to the probe request messages sent to the formally overloaded node then the reacting node should slowly increase the rate of traffic sent to the overloaded node." SRD Agreed, this is more clear. > > > Best regards > Ulrich > > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan > Sent: Saturday, July 05, 2014 9:42 PM > To: dime@ietf.org > Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt > > All, > > This version of the DOIC draft is a restructuring of previously agreed > to content. > > The master plan for the restructuring is in Appendix C. This outlines > where material from -02 was moved in -03. > > For those interested, the work was done in steps, with a snapshot for > each step available here: > > https://github.com/jounikor/draft-docdt-dime-ovli > > Each step has the name draft-ietf-dime-ovli-03-nn-text.txt > > where nn indicates the subversion and "text" indicates the focus for > that subversion. > > The next step will be to resolve open issues already identified and > those yet those yet to be identified. > > Regards, > > Steve > > > On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. >> >> Title : Diameter Overload Indication Conveyance >> Authors : Jouni Korhonen >> Steve Donovan >> Ben Campbell >> Lionel Morand >> Filename : draft-ietf-dime-ovli-03.txt >> Pages : 48 >> Date : 2014-07-03 >> >> Abstract: >> This specification documents a Diameter Overload Control (DOC) base >> solution and the dissemination of the overload report information. >> >> Requirements >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-03 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Tue Jul 15 06:59:00 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C6C1B2881 for ; Tue, 15 Jul 2014 06:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 b7KdSyvtBnIo for ; Tue, 15 Jul 2014 06:58:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FC11B28B5 for ; Tue, 15 Jul 2014 06:58:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140715135854.24751.86697.idtracker@ietfa.amsl.com> Date: Tue, 15 Jul 2014 06:58:54 -0700 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/dime/SLPYWfCOf7vRDvg9M_rLhiP8Fwk Subject: [Dime] Milestones changed for dime WG X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 13:58:58 -0000 Changed milestone "Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document", resolved as "Done". Changed milestone "Submit I-D 'Diameter Overload Control' as a working group document. To be Standards Track RFC", resolved as "Done". URL: http://datatracker.ietf.org/wg/dime/charter/ From nobody Tue Jul 15 07:06:20 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12041B2886 for ; Tue, 15 Jul 2014 07:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 KIZ83fPy0-RL for ; Tue, 15 Jul 2014 07:06:16 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D201A03DE for ; Tue, 15 Jul 2014 07:06:15 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s6FE6EVx018503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Jul 2014 14:06:14 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s6FE6Eo2002992 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jul 2014 16:06:14 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.93]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0181.006; Tue, 15 Jul 2014 16:06:13 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt Thread-Index: AQHPnVRNpme7ahOAGUKc60BfufTrZJuguhCAgAA26oCAAD20MA== Date: Tue, 15 Jul 2014 14:06:13 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151FDAB7@DEMUMBX014.nsn-intra.net> References: <20140703161711.24974.27021.idtracker@ietfa.amsl.com> <53B85695.2010208@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151F77ED@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151FDA48@DEMUMBX014.nsn-intra.net> <53C51B93.4060505@usdonovans.com> In-Reply-To: <53C51B93.4060505@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1133 X-purgate-ID: 151667::1405433174-00007A71-69D639D9/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/eKKRIF7rK88rkjMysq63NZRZ5fw Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 14:06:19 -0000 Steve, all use cases that do not follow A) to F), e.g. where C and S both supports DOIC, C sends a host-routed request to S and A in the= path modifies OC-xxx AVPs (see figure 7).=20 Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Tuesday, July 15, 2014 2:16 PM To: dime@ietf.org Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-c= ases-00.txt Ulrich, Can you be specific on which of the use cases in the specification do=20 not need to be supported by the DOIC solution? Thanks, Steve > Do I understand correctly that you mean that an agent MUST NOT remove or = modify the OC-S-F from host routed requests? If so, I disagree. There are r= eal world scenarios that will require that modification or removal. (For ex= ample, those in section 5.2) > [Wiehe, Ulrich (NSN - DE/Munich)] yes, you understand correctly, and no I= do not agree with your "real world scenarios". > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Tue Jul 15 07:30:32 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB3A1B2875 for ; Tue, 15 Jul 2014 07:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] autolearn=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 4Pbji97bPqKT for ; Tue, 15 Jul 2014 07:30:27 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 C035B1A03FC for ; Tue, 15 Jul 2014 07:30:27 -0700 (PDT) Received: from [41.0.204.98] (port=59987 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X73kQ-0001RN-2P; Tue, 15 Jul 2014 07:30:26 -0700 Message-ID: <53C53AFF.2030706@usdonovans.com> Date: Tue, 15 Jul 2014 16:30:23 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" References: <20140703161711.24974.27021.idtracker@ietfa.amsl.com> <53B85695.2010208@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151F77ED@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151FDA48@DEMUMBX014.nsn-intra.net> <53C51B93.4060505@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FDAB7@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151FDAB7@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/PSl50HjG_oHs0QehQLBMtWvuO7I Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 14:30:30 -0000 Ulrich, Which of the use cases in the draft do not follow A) to F)? Steve On 7/15/14, 4:06 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > all use cases that do not follow A) to F), > e.g. where > > C and S both supports DOIC, C sends a host-routed request to S and A in the path modifies OC-xxx AVPs (see figure 7). > > Ulrich > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan > Sent: Tuesday, July 15, 2014 2:16 PM > To: dime@ietf.org > Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt > > Ulrich, > > Can you be specific on which of the use cases in the specification do > not need to be supported by the DOIC solution? > > Thanks, > > Steve >> Do I understand correctly that you mean that an agent MUST NOT remove or modify the OC-S-F from host routed requests? If so, I disagree. There are real world scenarios that will require that modification or removal. (For example, those in section 5.2) >> [Wiehe, Ulrich (NSN - DE/Munich)] yes, you understand correctly, and no I do not agree with your "real world scenarios". >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Tue Jul 15 10:26:05 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF50C1A0ADC for ; Tue, 15 Jul 2014 10:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 MZz7deBwdfGI for ; Tue, 15 Jul 2014 10:26:00 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEEEC1A0ABB for ; Tue, 15 Jul 2014 10:26:00 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id lj1so1227851pab.19 for ; Tue, 15 Jul 2014 10:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jCQ8pQNFYbkNyAFcGYzDNwmZugGgjr8XWX2kteJMMug=; b=EV46eP1VKfsSvKiGkQJdfJzcy0bD2rimpCVuAgHTZullerKxCWHY8ihys/0GwRc2Ak eWgtfKcR9w5X0egrLYoPiabuCbMZu7/hga8JVSWO9rlVuUKUeWvXN+RB/M0wdHrEDTw+ 6lgmMSz/z/zYV+BWSc3KZZOtcSgTtQPDmq8Wax71FclZ7MsDHQ1SPUwCmIkZU7sCdSkC PLfx40z+tj+vJ3oHCBWn8yIsUxMWCj8cPI9Qjp+CYFr7fuaWKKdmcK9TVe1xY1sKVACx dONNNNFDtMEz7JN8KMh1Bwi3flHY17cBvc8s/2YVPcneU1Qp9q+ugpWM2Jp2zhGBa2g7 wD9w== X-Received: by 10.68.252.73 with SMTP id zq9mr3800710pbc.146.1405445160393; Tue, 15 Jul 2014 10:26:00 -0700 (PDT) Received: from [10.100.20.19] ([63.133.199.244]) by mx.google.com with ESMTPSA id qv9sm14532362pbc.71.2014.07.15.10.25.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 10:25:59 -0700 (PDT) Message-ID: <53C56425.7040908@gmail.com> Date: Tue, 15 Jul 2014 20:25:57 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Hirschman, Brent B [CTO]" , "dime@ietf.org" References: <9203f8d398b14340b45617e019dc512e@PREWE13M04.ad.sprint.com> In-Reply-To: <9203f8d398b14340b45617e019dc512e@PREWE13M04.ad.sprint.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ul3le4n0pF6kCimkyqvvSTbPKyY Cc: "Rajagopal, Arun \[CTO\]" , "Sershen, Dan J \[CTO\]" Subject: Re: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-00 - Use Cases X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 17:26:03 -0000 Brent, I do agree with your conclusion that adding examples would be minimal incremental addition to what RFC5777 already has. Also, IMHO use cases for ECN should be rather well known. I see no reason to add text for "topic 2". - Jouni 4/29/2014 5:35 PM, Hirschman, Brent B [CTO] kirjoitti: > At IETF 89 in London, during the discussion of the > draft-ietf-dime-congestion-flow-attributes-00.txt, Two areas were > requested to be investigated further. We will be addressing them in > separate email threads to keep the discussion focused on each topic. > This is Topic 2: > > Second, we were requested to investigate providing example use cases of > ECN. RFC5777 already provides a set of use cases for reporting and ECN > is just one of many such reporting parameters such as byte count. > Adding a paragraph of text such as the following may add some > information but the authors feel little incremental information is > needed because of the work already in RFC 5777. > > “Diameter nodes along the bearer path can implement filters to collect > accounting and policy control information based on these congestion > parameters similar to byte count information. These filters on flows and > overall node congestion for these AVPs can report a measure of quality > of byte counts to collection points in the network where decisions can > be made to mitigate or mediate any congestion conditions for accounting > or real time policy control. These AVPs provide supplemental information > as described in the use cases discussed in RFC5777.” > > Thus, the authors are proposing no modification to the working group > draft at this time. Comments are welcome. > > */Brent Hirschman/* > > Tech Dev Strategist III > > Sprint Corporation > > 6220 Sprint Parkway > > Overland Park, KS 66251// > > Office – 913-762-6736 > > Mobile – 913-593-6221 > > > ------------------------------------------------------------------------ > > This e-mail may contain Sprint proprietary information intended for the > sole use of the recipient(s). Any use by others is prohibited. If you > are not the intended recipient, please contact the sender and delete all > copies of the message. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Tue Jul 15 11:12:00 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D565D1A0AD9 for ; Tue, 15 Jul 2014 11:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_102=0.6, SPF_PASS=-0.001] autolearn=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 IjlNsDzclEQx for ; Tue, 15 Jul 2014 11:11:58 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 411D51A04E7 for ; Tue, 15 Jul 2014 11:11:58 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kx10so6383971pab.20 for ; Tue, 15 Jul 2014 11:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pD+Q7wgR2QC9TMTF7LBquWbWptuiPkIsVnXeWAJ3kqI=; b=IRJyvw0s2b9/YZMOlNdrM3Ph+DhGZs8jvQRQ8fCLBbRBMFE6FXdCW6Slw0nuZA7ORx 2VTbWXmCWUPpAUMFItNMUJrT6BoC2q3B0ziBVkFJZqASR/2WmdMdXWRLY3YbK3R/Apqf yARZIU4V0U9Otae6bzZ+VajDyY1dF3/Gvrd6Zq1F8h8J0uyTDadekdEiSE8wQjHcfOFn Pu1rJOHl6zcJT1mTOivg7QnGMUiQ3+xmn2rxmghWT+3x1tmsS+PGGf0xSEYnDHBq5FMf UMyZWFvB4Xmc0GKVNzbRZZ1XPlhcwhondjPp4Bt36q4Kiv/F62tiLBR67WfwcQVM0WIr ZCIA== X-Received: by 10.66.227.196 with SMTP id sc4mr22480187pac.15.1405447917914; Tue, 15 Jul 2014 11:11:57 -0700 (PDT) Received: from [10.100.20.19] ([63.133.199.244]) by mx.google.com with ESMTPSA id ez1sm14611655pbd.91.2014.07.15.11.11.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 15 Jul 2014 11:11:57 -0700 (PDT) Message-ID: <53C56EEB.8030202@gmail.com> Date: Tue, 15 Jul 2014 21:11:55 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Hirschman, Brent B [CTO]" , "dime@ietf.org" References: <514f538ef4f74db8a2103cc222be5baa@PREWE13M04.ad.sprint.com> In-Reply-To: <514f538ef4f74db8a2103cc222be5baa@PREWE13M04.ad.sprint.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/D_8HMdoiLaPzGS6GHF6hZOxqqIo Cc: "Rajagopal, Arun \[CTO\]" , "Sershen, Dan J \[CTO\]" Subject: Re: [Dime] Topic 1 of draft-ietf-dime-congestion-flow-attributes-00 - ECE and CWR X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 18:12:00 -0000 Brent, Comments inline. 4/29/2014 5:34 PM, Hirschman, Brent B [CTO] kirjoitti: > At IETF 89 in London, during the discussion of the > draft-ietf-dime-congestion-flow-attributes-00.txt, Two areas were > requested to be investigated further. We will be addressing them in > separate email threads to keep the discussion focused on each topic. > This is Topic 1. > > First discussion topic, whether ECE and CWR flags needed to be added to > this draft. After further investigation, these flags are already > included as part of Section 4.1.8.10 or RFC5777. Correct. > The TCP-Flag-Type AVP (AVP Code 544) is of type Unsigned32 and > > specifies the TCP control flag types that must be matched. The first > > 16 bits match the TCP header format defined in [RFC3168 > ], and the > > subsequent 16 bits are unused. Within the first 16 bits, bits 0 to 3 > > are unused and bits 4 to 15 are managed by IANA under the TCP Header > > Flag registry as defined in [RFC3168 > ]. > > The support of ECN flags (in this draft) are needed since they were > omitted in RFC5777: > > The ECN flags are still required and here is why. The > problem is that RFC 2474 (DSCP) update was made prior to 3168. They RFC3168 updates RFC2474, thus it is not really an issue that DSCP update was done before RFC3168. However, ECN flags are still needed since RFC5777 limits ECN use strictly to TCP transport. > studied and made recommendations for this situation in RFC 3260 Section 4. > > The DS Field has a six bit Diffserv Codepoint and two "currently unused" > bits. > > … > > It has been pointed out that this leads to inconsistencies and > > ambiguities. In particular, the "Currently Unused" (CU) bits of the > > DS Field have not been assigned to Diffserv, and subsequent to the > > publication of RFC 2474 , they > were assigned for explicit congestion > > notification, as defined in RFC 3168 > [4 > ] > > … > > Therefore, for use in future documents, including the next update to > > RFC 2474 , the following definitions > should apply: > > - the Differentiated Services Field (DSField) is the six most > > significant bits of the (former) IPV4 TOS octet or the (former) > > IPV6 Traffic Class octet. > > - the Differentiated Services Codepoint (DSCP) is a value which > > is encoded in the DS field, and which each DS Node MUST use to > > select the PHB which is to be experienced by each packet it > > forwards. > > The two least significant bits of the IPV4 TOS octet and the IPV6 > > Traffic Class octet are not used by Diffserv. > > When RFC 2474 is updated, > consideration should be given to changing > > the designation "currently unused (CU)" to "explicit congestion > > notification (ECN)" and referencing RFC 3168 > (or its successor). > > Note here they are essentially dropping the “CU” bits in the definition > itself. This removes overlap in ECN 3186. > > For RFC 5777, the authors wrote the AVP definition for DSCP in such a > way that it is not impacted so long as the registry is correct from 2474 > and its successors. Below is the RFC 5777 definition for DSCP. > > *4.1.8.1 . > Diffserv-Code-Point AVP* > > The Diffserv-Code-Point AVP (AVP Code 535) is of type Enumerated and > > specifies the Differentiated Services Field Codepoints to match in > > the IP header. The values are managed by IANA under the > > Differentiated Services Field Codepoints registry a The following statement in Section 2.5.1 of the IPv6 addressing architecture [RFC4291]: For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. is replaced by: For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. If derived from an IEEE MAC-layer address, they must be constructed in Modified EUI-64 format. The following statement in Section 2.5.1 of the IPv6 addressing architecture [RFC4291] is obsoleted: The use of the universal/local bit in the Modified EUI-64 format identifier is to allow development of future technology that can take advantage of interface identifiers with universal scope. As far as is known, no existing implementation will be affected by these changes. The benefit is that future design discussions are simplified.gs defined in > > [RFC2474 ]. Mmm.. right.. One could argue that RFC3168 update to RFC2474 would suffice. However, my recollection was that RFC5777 DSCP was really done only the 6 DSCP bits in mind (I could remember wrong but the explicit RFC2474 reference indicates that). I still think it makes perfect sense to have different AVPs for DSCP and ECN for IP header. Otherwise we cannot have a rule to match only ECN bits and neglecting other 6 DSCP bits, as an example.. - Jouni > > The registry is to be updated to exclude the LU/Exp DSCPs from 2474. > This is specified in RFC 3260. > > *8 . IANA Considerations* > > IANA has requested clarification of a point in RFC 2474 > , concerning > > registration of experimental/local use DSCPs. When RFC 2474 > is > > revised, the following should be added to Section 6 > : > > IANA is requested to maintain a registry of RECOMMENDED DSCP > > values assigned by standards action. EXP/LU values are not to be > > registered. > > In summary the ECN flags are no longer considered DSCP “CU” bits. They > are also not covered any IANA value. This results in a gap in 5777 and > requires the update. > > */Brent Hirschman/* > > Tech Dev Strategist III > > Sprint Corporation > > 6220 Sprint Parkway > > Overland Park, KS 66251// > > Office – 913-762-6736 > > Mobile – 913-593-6221 > > > ------------------------------------------------------------------------ > > This e-mail may contain Sprint proprietary information intended for the > sole use of the recipient(s). Any use by others is prohibited. If you > are not the intended recipient, please contact the sender and delete all > copies of the message. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Tue Jul 15 13:24:06 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAABC1A00B1 for ; Tue, 15 Jul 2014 13:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 k_s5zBTWCuHx for ; Tue, 15 Jul 2014 13:24:01 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BF881A0061 for ; Tue, 15 Jul 2014 13:24:00 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s6FKNwc6032703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Jul 2014 20:23:59 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s6FKNvkl027164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Jul 2014 22:23:58 +0200 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 15 Jul 2014 22:23:57 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.93]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0181.006; Tue, 15 Jul 2014 22:23:57 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt Thread-Index: AQHPnVRNpme7ahOAGUKc60BfufTrZJuguhCAgAA26oCAAD20MP//58GAgAB/4qA= Date: Tue, 15 Jul 2014 20:23:56 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151FDB32@DEMUMBX014.nsn-intra.net> References: <20140703161711.24974.27021.idtracker@ietfa.amsl.com> <53B85695.2010208@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151F77ED@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151FDA48@DEMUMBX014.nsn-intra.net> <53C51B93.4060505@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FDAB7@DEMUMBX014.nsn-intra.net> <53C53AFF.2030706@usdonovans.com> In-Reply-To: <53C53AFF.2030706@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1814 X-purgate-ID: 151667::1405455839-00007A71-A11E38F8/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/uy5H1NO_Q3qKwV3Ny0M6JaMZsTE Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 20:24:04 -0000 Steve, e.g.the use case shown in figure 7 where the agent modifies the OC-S-F with= in the xxR no matter whether the xxR is host-routed or realm-routed. If xxR= is host routed, A) is not followed. Ulrich -----Original Message----- From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Tuesday, July 15, 2014 4:30 PM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-c= ases-00.txt Ulrich, Which of the use cases in the draft do not follow A) to F)? Steve On 7/15/14, 4:06 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > all use cases that do not follow A) to F), > e.g. where > > C and S both supports DOIC, C sends a host-routed request to S and A in t= he path modifies OC-xxx AVPs (see figure 7). > > Ulrich > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan > Sent: Tuesday, July 15, 2014 2:16 PM > To: dime@ietf.org > Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent= -cases-00.txt > > Ulrich, > > Can you be specific on which of the use cases in the specification do > not need to be supported by the DOIC solution? > > Thanks, > > Steve >> Do I understand correctly that you mean that an agent MUST NOT remove or= modify the OC-S-F from host routed requests? If so, I disagree. There are = real world scenarios that will require that modification or removal. (For e= xample, those in section 5.2) >> [Wiehe, Ulrich (NSN - DE/Munich)] yes, you understand correctly, and no = I do not agree with your "real world scenarios". >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Wed Jul 16 00:16:21 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4AC1B299E for ; Wed, 16 Jul 2014 00:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.279 X-Spam-Level: X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_NEUTRAL=0.779] autolearn=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 6fhdcQOFN-Hv for ; Wed, 16 Jul 2014 00:16:18 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 6812E1B299D for ; Wed, 16 Jul 2014 00:16:18 -0700 (PDT) Received: from [41.0.92.142] (port=65425 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X7JRh-0004tY-6X; Wed, 16 Jul 2014 00:16:14 -0700 Message-ID: <53C626B2.2000602@usdonovans.com> Date: Wed, 16 Jul 2014 09:16:02 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" References: <20140703161711.24974.27021.idtracker@ietfa.amsl.com> <53B85695.2010208@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151F77ED@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151FDA48@DEMUMBX014.nsn-intra.net> <53C51B93.4060505@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FDAB7@DEMUMBX014.nsn-intra.net> <53C53AFF.2030706@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FDB32@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151FDB32@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/_kvF8tivyyzwd16uih2-xOAmRkA Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 07:16:20 -0000 Ulrich, The mismatched capabilities use case is required for extensibility. We have at least two cases where the use case is required. First is agent overload and the second is the rate abatement algorithm. Consider the agent overload feature. This feature requires knowledge of whether or not the adjacent nodes support the feature. This cannot be achieved if the transaction client does not support the feature and the agent is not allowed to change the OC-S-F AVP. As I indicated in my initial response, I do not agree with the A-F principles. The DOIC solution needs to support required use cases. The behavior specified needs to be based on those use cases. Steve On 7/15/14, 10:23 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > e.g.the use case shown in figure 7 where the agent modifies the OC-S-F within the xxR no matter whether the xxR is host-routed or realm-routed. If xxR is host routed, A) is not followed. > > Ulrich > > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Tuesday, July 15, 2014 4:30 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org > Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt > > Ulrich, > > Which of the use cases in the draft do not follow A) to F)? > > Steve > > On 7/15/14, 4:06 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Steve, >> >> all use cases that do not follow A) to F), >> e.g. where >> >> C and S both supports DOIC, C sends a host-routed request to S and A in the path modifies OC-xxx AVPs (see figure 7). >> >> Ulrich >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan >> Sent: Tuesday, July 15, 2014 2:16 PM >> To: dime@ietf.org >> Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt >> >> Ulrich, >> >> Can you be specific on which of the use cases in the specification do >> not need to be supported by the DOIC solution? >> >> Thanks, >> >> Steve >>> Do I understand correctly that you mean that an agent MUST NOT remove or modify the OC-S-F from host routed requests? If so, I disagree. There are real world scenarios that will require that modification or removal. (For example, those in section 5.2) >>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, you understand correctly, and no I do not agree with your "real world scenarios". >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > From nobody Wed Jul 16 02:01:02 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307D01B2AFA for ; Wed, 16 Jul 2014 02:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 WFYlbxXTj4GG for ; Wed, 16 Jul 2014 02:00:57 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 663AE1B2B02 for ; Wed, 16 Jul 2014 02:00:57 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s6G90sR6032136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Jul 2014 09:00:54 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s6G90qP7002181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Jul 2014 11:00:53 +0200 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 16 Jul 2014 11:00:51 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.93]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0181.006; Wed, 16 Jul 2014 11:00:51 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt Thread-Index: AQHPnVRNpme7ahOAGUKc60BfufTrZJuguhCAgAA26oCAAD20MP//58GAgAB/4qCAAJkYAIAALSrA Date: Wed, 16 Jul 2014 09:00:50 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151FDC56@DEMUMBX014.nsn-intra.net> References: <20140703161711.24974.27021.idtracker@ietfa.amsl.com> <53B85695.2010208@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151F77ED@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151FDA48@DEMUMBX014.nsn-intra.net> <53C51B93.4060505@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FDAB7@DEMUMBX014.nsn-intra.net> <53C53AFF.2030706@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FDB32@DEMUMBX014.nsn-intra.net> <53C626B2.2000602@usdonovans.com> In-Reply-To: <53C626B2.2000602@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3843 X-purgate-ID: 151667::1405501254-00007A71-D295627E/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/rKPf8Tzv5A2QgYllrb4o2N3B-fs Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 09:01:00 -0000 Steve, with regard to extensions introducing new algorithms like rate I do not see= what is wrong with the A-F principles: Algorithm negotiation is end-to-end= and it is irrelevant whether and which algorithms are supported by an agen= t in the middle. With regard to agent overload, many things are unclear and my understanding= is that nothing has been agreed so far. Please see my comments to your age= nt overload draft I sent earlier. Principle here seems to be that agent overload information (capabilities an= d reports) is only relevant for the next hop and must not be forwarded furt= her by the next hop (and if the next hop does not support agent overload, m= ust not be sent at all to the next hop). Piggibacking this information on (= end-to-end) application messages therefore may not be the best choice. Rath= er CER and WDR should be used for agent overload. =20 Ulrich -----Original Message----- From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Wednesday, July 16, 2014 9:16 AM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-c= ases-00.txt Ulrich, The mismatched capabilities use case is required for extensibility. We have at least two cases where the use case is required. First is=20 agent overload and the second is the rate abatement algorithm. Consider the agent overload feature. This feature requires knowledge=20 of whether or not the adjacent nodes support the feature. This cannot be=20 achieved if the transaction client does not support the feature and the=20 agent is not allowed to change the OC-S-F AVP. As I indicated in my initial response, I do not agree with the A-F=20 principles. The DOIC solution needs to support required use cases. The=20 behavior specified needs to be based on those use cases. Steve On 7/15/14, 10:23 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > e.g.the use case shown in figure 7 where the agent modifies the OC-S-F wi= thin the xxR no matter whether the xxR is host-routed or realm-routed. If x= xR is host routed, A) is not followed. > > Ulrich > > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Tuesday, July 15, 2014 4:30 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org > Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent= -cases-00.txt > > Ulrich, > > Which of the use cases in the draft do not follow A) to F)? > > Steve > > On 7/15/14, 4:06 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Steve, >> >> all use cases that do not follow A) to F), >> e.g. where >> >> C and S both supports DOIC, C sends a host-routed request to S and A in = the path modifies OC-xxx AVPs (see figure 7). >> >> Ulrich >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan >> Sent: Tuesday, July 15, 2014 2:16 PM >> To: dime@ietf.org >> Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agen= t-cases-00.txt >> >> Ulrich, >> >> Can you be specific on which of the use cases in the specification do >> not need to be supported by the DOIC solution? >> >> Thanks, >> >> Steve >>> Do I understand correctly that you mean that an agent MUST NOT remove o= r modify the OC-S-F from host routed requests? If so, I disagree. There are= real world scenarios that will require that modification or removal. (For = example, those in section 5.2) >>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, you understand correctly, and no= I do not agree with your "real world scenarios". >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > From nobody Wed Jul 16 05:51:35 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681E41B2872 for ; Wed, 16 Jul 2014 05:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=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 1w4AlTPM36yl for ; Wed, 16 Jul 2014 05:51:32 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 63B411B2863 for ; Wed, 16 Jul 2014 05:51:32 -0700 (PDT) Received: from [41.0.92.142] (port=51712 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X7OgE-0001Q4-6u for dime@ietf.org; Wed, 16 Jul 2014 05:51:31 -0700 Message-ID: <53C6754B.5020600@usdonovans.com> Date: Wed, 16 Jul 2014 14:51:23 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/btmgJwk5fVf9JSxWIQ_xnhvaH3s Subject: [Dime] DOIC #54: OC-Report-Type as mandatory AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 12:51:33 -0000 All, Now that the restructure of the DOIC specification is complete we need to start resolving open issues. Those that entered the issues are encouraged to work to get them closed. I'll start on #54 in this email. The question is whether the OC-Report-Type AVP is required any time that an OC-OLR AVP is sent. The current version of the draft is the same as the -02 version, showing the AVP as being required. This was based on an earlier attempt to close the issue prior to -02 being published. Susan has stated that she does not think it should be required. If I understand correctly this is based on the assumption that an HSS would never send an OLR with report-type of any value but host. Susan, please correct me if I'm mistaken. I don't believe this is a correct assumption. It is reasonable for an HSS to send an OLR with report-type of realm. This might happen in a non agent based deployment or in a deployment where the HSS (or more generically, server) has knowledge of the status of all servers for the application. Based on this, I propose that the text be kept as is and that this issue be closed without changes to the specification. The threshold for changing what is currently in the DOIC specification is rough consensus in the group that it should be changed. Anyone with an opinion is encouraged to state it now. This is not a vote (we don't vote in the IETF...) but an attempt to see if we have consensus to either close the issue without a change in the specification or if we have consensus to change the specification. Regards, Steve From nobody Wed Jul 16 05:59:27 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989D31B2A4A for ; Wed, 16 Jul 2014 05:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=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 NxGB47MIP-Yw for ; Wed, 16 Jul 2014 05:59:24 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 421041B2A08 for ; Wed, 16 Jul 2014 05:59:24 -0700 (PDT) Received: from [41.0.92.142] (port=51744 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X7Onq-0000JW-PB for dime@ietf.org; Wed, 16 Jul 2014 05:59:23 -0700 Message-ID: <53C67728.1040907@usdonovans.com> Date: Wed, 16 Jul 2014 14:59:20 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/k0ovCf7cGuUW-ppRsKZ45-odX_E Subject: [Dime] DOIC #62 - Section 3 needs to be made consistent with DIOC solution X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 12:59:25 -0000 All, One of the side effects of the restructuring of the DOIC specification was to align section 3 with the normative sections of the document. Based on this, I propose that we close this issue. Any problems with the text in section 3 of -03 should be dealt with as new problem reports and should propose specific wording changes. In addition, we need to make sure that any changes to the normative sections get reflected in the informative text in section 3. If there are no objections then I will close the issue. Regards, Steve From nobody Wed Jul 16 06:10:18 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C9A1B2A3E for ; Wed, 16 Jul 2014 06:10:14 -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, SPF_NEUTRAL=0.779] autolearn=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 AIYyzJvU4YMR for ; Wed, 16 Jul 2014 06:10:12 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 589561B29DB for ; Wed, 16 Jul 2014 06:10:12 -0700 (PDT) Received: from [41.0.92.142] (port=51802 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X7OyE-0003uh-Ka; Wed, 16 Jul 2014 06:10:11 -0700 Message-ID: <53C679AB.4080304@usdonovans.com> Date: Wed, 16 Jul 2014 15:10:03 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" References: <20140703161711.24974.27021.idtracker@ietfa.amsl.com> <53B85695.2010208@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151F77ED@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151FDA48@DEMUMBX014.nsn-intra.net> <53C51B93.4060505@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FDAB7@DEMUMBX014.nsn-intra.net> <53C53AFF.2030706@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FDB32@DEMUMBX014.nsn-intra.net> <53C626B2.2000602@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FDC56@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151FDC56@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/J6fllmLQcenRl3IXoVzMioehab0 Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 13:10:14 -0000 Ulrich, Please see my comments inline Steve On 7/16/14, 11:00 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > with regard to extensions introducing new algorithms like rate I do not see what is wrong with the A-F principles: Algorithm negotiation is end-to-end and it is irrelevant whether and which algorithms are supported by an agent in the middle. SRD> I do not agree that algorithm negotiation is end-to-end. In addition, we should not preclude the case discussed in section 5.2.2. > > With regard to agent overload, many things are unclear and my understanding is that nothing has been agreed so far. Please see my comments to your agent overload draft I sent earlier. > Principle here seems to be that agent overload information (capabilities and reports) is only relevant for the next hop and must not be forwarded further by the next hop (and if the next hop does not support agent overload, must not be sent at all to the next hop). Piggibacking this information on (end-to-end) application messages therefore may not be the best choice. Rather CER and WDR should be used for agent overload. SRD> There are clearly options in how to design agent overload. My preference is to use the same mechanisms for transport of agent overload AVPs as are used for other report types. Others might have different opinions. We should not, however, assume a solution at this point. In addition, we should not limit the options for future extensions. > > Ulrich > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, July 16, 2014 9:16 AM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org > Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt > > Ulrich, > > The mismatched capabilities use case is required for extensibility. > > We have at least two cases where the use case is required. First is > agent overload and the second is the rate abatement algorithm. > > Consider the agent overload feature. This feature requires knowledge > of whether or not the adjacent nodes support the feature. This cannot be > achieved if the transaction client does not support the feature and the > agent is not allowed to change the OC-S-F AVP. > > As I indicated in my initial response, I do not agree with the A-F > principles. The DOIC solution needs to support required use cases. The > behavior specified needs to be based on those use cases. > > Steve > > > On 7/15/14, 10:23 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Steve, >> >> e.g.the use case shown in figure 7 where the agent modifies the OC-S-F within the xxR no matter whether the xxR is host-routed or realm-routed. If xxR is host routed, A) is not followed. >> >> Ulrich >> >> >> -----Original Message----- >> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Tuesday, July 15, 2014 4:30 PM >> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org >> Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt >> >> Ulrich, >> >> Which of the use cases in the draft do not follow A) to F)? >> >> Steve >> >> On 7/15/14, 4:06 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>> Steve, >>> >>> all use cases that do not follow A) to F), >>> e.g. where >>> >>> C and S both supports DOIC, C sends a host-routed request to S and A in the path modifies OC-xxx AVPs (see figure 7). >>> >>> Ulrich >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan >>> Sent: Tuesday, July 15, 2014 2:16 PM >>> To: dime@ietf.org >>> Subject: Re: [Dime] New Version Notification for draft-donovan-doic-agent-cases-00.txt >>> >>> Ulrich, >>> >>> Can you be specific on which of the use cases in the specification do >>> not need to be supported by the DOIC solution? >>> >>> Thanks, >>> >>> Steve >>>> Do I understand correctly that you mean that an agent MUST NOT remove or modify the OC-S-F from host routed requests? If so, I disagree. There are real world scenarios that will require that modification or removal. (For example, those in section 5.2) >>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, you understand correctly, and no I do not agree with your "real world scenarios". >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> > From nobody Wed Jul 16 07:17:49 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6860A1B288D for ; Wed, 16 Jul 2014 07:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 EMzMpqZf-HKY for ; Wed, 16 Jul 2014 07:17:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 49C2A1B287B for ; Wed, 16 Jul 2014 07:17:47 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6GEGiew013753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Jul 2014 09:17:46 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53C67728.1040907@usdonovans.com> Date: Wed, 16 Jul 2014 09:17:44 -0500 X-Mao-Original-Outgoing-Id: 427213064.873787-cac14900045518c087c5f5299590c716 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53C67728.1040907@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/p0sz99FKE4ACwANONr0aepLanco Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC #62 - Section 3 needs to be made consistent with DIOC solution X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 14:17:48 -0000 On Jul 16, 2014, at 7:59 AM, Steve Donovan = wrote: > All, >=20 > One of the side effects of the restructuring of the DOIC specification = was to align section 3 with the normative sections of the document. = Based on this, I propose that we close this issue. >=20 > Any problems with the text in section 3 of -03 should be dealt with as = new problem reports and should propose specific wording changes. >=20 > In addition, we need to make sure that any changes to the normative = sections get reflected in the informative text in section 3. >=20 > If there are no objections then I will close the issue. >=20 No objection here. From nobody Wed Jul 16 07:18:52 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F4D1B288D for ; Wed, 16 Jul 2014 07:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 myNjX6hTaKBh for ; Wed, 16 Jul 2014 07:18:50 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A0A3E1B287B for ; Wed, 16 Jul 2014 07:18:50 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6GEImCw013923 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Jul 2014 09:18:49 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53C6754B.5020600@usdonovans.com> Date: Wed, 16 Jul 2014 09:18:47 -0500 X-Mao-Original-Outgoing-Id: 427213127.2936-b9228952ea58e58a8da095d23426682b Content-Transfer-Encoding: quoted-printable Message-Id: References: <53C6754B.5020600@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Y15pzBucLSe407B_5TORySelEKI Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC #54: OC-Report-Type as mandatory AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 14:18:52 -0000 I thought our chairs had declared a rough consensus on this. Do I have = that confused with another issue? On Jul 16, 2014, at 7:51 AM, Steve Donovan = wrote: > All, >=20 > Now that the restructure of the DOIC specification is complete we need = to start resolving open issues. Those that entered the issues are = encouraged to work to get them closed. >=20 > I'll start on #54 in this email. >=20 > The question is whether the OC-Report-Type AVP is required any time = that an OC-OLR AVP is sent. >=20 > The current version of the draft is the same as the -02 version, = showing the AVP as being required. This was based on an earlier attempt = to close the issue prior to -02 being published. >=20 > Susan has stated that she does not think it should be required. If I = understand correctly this is based on the assumption that an HSS would = never send an OLR with report-type of any value but host. >=20 > Susan, please correct me if I'm mistaken. >=20 > I don't believe this is a correct assumption. It is reasonable for an = HSS to send an OLR with report-type of realm. This might happen in a = non agent based deployment or in a deployment where the HSS (or more = generically, server) has knowledge of the status of all servers for the = application. >=20 > Based on this, I propose that the text be kept as is and that this = issue be closed without changes to the specification. >=20 > The threshold for changing what is currently in the DOIC specification = is rough consensus in the group that it should be changed. Anyone with = an opinion is encouraged to state it now. This is not a vote (we don't = vote in the IETF...) but an attempt to see if we have consensus to = either close the issue without a change in the specification or if we = have consensus to change the specification. >=20 > Regards, >=20 > Steve >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed Jul 16 07:25:20 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCFD1B289F for ; Wed, 16 Jul 2014 07:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=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 Rsr10nXtxxjc for ; Wed, 16 Jul 2014 07:25:17 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 7426B1B287B for ; Wed, 16 Jul 2014 07:25:17 -0700 (PDT) Received: from [41.0.92.142] (port=53226 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X7Q8u-00017X-HX; Wed, 16 Jul 2014 07:25:16 -0700 Message-ID: <53C68B45.1020408@usdonovans.com> Date: Wed, 16 Jul 2014 16:25:09 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Campbell References: <53C6754B.5020600@usdonovans.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/941nUhLra5A4lIBGh8lIgmX0e_c Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC #54: OC-Report-Type as mandatory AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 14:25:18 -0000 You are correct, that is what lead to the current text in the -03 draft. There has been an objection raised to the declaration. Steve On 7/16/14, 4:18 PM, Ben Campbell wrote: > I thought our chairs had declared a rough consensus on this. Do I have that confused with another issue? > > On Jul 16, 2014, at 7:51 AM, Steve Donovan wrote: > >> All, >> >> Now that the restructure of the DOIC specification is complete we need to start resolving open issues. Those that entered the issues are encouraged to work to get them closed. >> >> I'll start on #54 in this email. >> >> The question is whether the OC-Report-Type AVP is required any time that an OC-OLR AVP is sent. >> >> The current version of the draft is the same as the -02 version, showing the AVP as being required. This was based on an earlier attempt to close the issue prior to -02 being published. >> >> Susan has stated that she does not think it should be required. If I understand correctly this is based on the assumption that an HSS would never send an OLR with report-type of any value but host. >> >> Susan, please correct me if I'm mistaken. >> >> I don't believe this is a correct assumption. It is reasonable for an HSS to send an OLR with report-type of realm. This might happen in a non agent based deployment or in a deployment where the HSS (or more generically, server) has knowledge of the status of all servers for the application. >> >> Based on this, I propose that the text be kept as is and that this issue be closed without changes to the specification. >> >> The threshold for changing what is currently in the DOIC specification is rough consensus in the group that it should be changed. Anyone with an opinion is encouraged to state it now. This is not a vote (we don't vote in the IETF...) but an attempt to see if we have consensus to either close the issue without a change in the specification or if we have consensus to change the specification. >> >> Regards, >> >> Steve >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > From nobody Wed Jul 16 15:40:50 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2111A0380 for ; Wed, 16 Jul 2014 15:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 udeA63yri1xG for ; Wed, 16 Jul 2014 15:40:47 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C7061A037F for ; Wed, 16 Jul 2014 15:40:47 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id z10so1978280pdj.30 for ; Wed, 16 Jul 2014 15:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=OOhE3/+wRRJLzux8VE+L8WXhU4fDOHD3HWXPUvD4R4o=; b=X8K95Pqk1eSwMSW/j3ebEKzHgUkZQZIaFsCDrEPq4XzDUmmAQ0/yL1/mKkclv2FE+F wEM/5DmQJizMQW4DCg3H1dFLdGMzfAnkBq9hVfgj7/SV54gGdK810QuVqgFZuRViHGuG U/tsp5wxNeofkMihbJAsO3lO/K4HiNbagulM5NDu0FKovj3zC6mq7/wFF4kGjLvKBK8Q gj/9R5YixIHXG0uqWvvv07WrOCt1xTgowAFf7g8oKv2ZuLRnYCYr06w4heEjrvXqtBY0 JgmAA4oLpcqE2m5+xJDy/g6oMz8t2FyvVVTLzKVlBf4GGwFQDfx3xvbN/6OgahFlrQGI jYGg== X-Received: by 10.68.251.201 with SMTP id zm9mr33499135pbc.22.1405550446881; Wed, 16 Jul 2014 15:40:46 -0700 (PDT) Received: from [10.100.20.19] ([63.133.199.244]) by mx.google.com with ESMTPSA id wp3sm422946pbc.67.2014.07.16.15.40.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jul 2014 15:40:45 -0700 (PDT) Message-ID: <53C6FF6B.9020605@gmail.com> Date: Thu, 17 Jul 2014 01:40:43 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steve Donovan , Ben Campbell References: <53C6754B.5020600@usdonovans.com> <53C68B45.1020408@usdonovans.com> In-Reply-To: <53C68B45.1020408@usdonovans.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/4CJV_ajh7Q7YfvJHNv1poOsQSUY Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC #54: OC-Report-Type as mandatory AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 22:40:49 -0000 Hi, Lionel declared a rough concensus on #54. This issue should be closed. - Jouni 7/16/2014 5:25 PM, Steve Donovan kirjoitti: > You are correct, that is what lead to the current text in the -03 > draft. There has been an objection raised to the declaration. > > Steve > > On 7/16/14, 4:18 PM, Ben Campbell wrote: >> I thought our chairs had declared a rough consensus on this. Do I have >> that confused with another issue? >> >> On Jul 16, 2014, at 7:51 AM, Steve Donovan >> wrote: >> >>> All, >>> >>> Now that the restructure of the DOIC specification is complete we >>> need to start resolving open issues. Those that entered the issues >>> are encouraged to work to get them closed. >>> >>> I'll start on #54 in this email. >>> >>> The question is whether the OC-Report-Type AVP is required any time >>> that an OC-OLR AVP is sent. >>> >>> The current version of the draft is the same as the -02 version, >>> showing the AVP as being required. This was based on an earlier >>> attempt to close the issue prior to -02 being published. >>> >>> Susan has stated that she does not think it should be required. If I >>> understand correctly this is based on the assumption that an HSS >>> would never send an OLR with report-type of any value but host. >>> >>> Susan, please correct me if I'm mistaken. >>> >>> I don't believe this is a correct assumption. It is reasonable for >>> an HSS to send an OLR with report-type of realm. This might happen >>> in a non agent based deployment or in a deployment where the HSS (or >>> more generically, server) has knowledge of the status of all servers >>> for the application. >>> >>> Based on this, I propose that the text be kept as is and that this >>> issue be closed without changes to the specification. >>> >>> The threshold for changing what is currently in the DOIC >>> specification is rough consensus in the group that it should be >>> changed. Anyone with an opinion is encouraged to state it now. This >>> is not a vote (we don't vote in the IETF...) but an attempt to see if >>> we have consensus to either close the issue without a change in the >>> specification or if we have consensus to change the specification. >>> >>> Regards, >>> >>> Steve >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed Jul 16 15:43:38 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D985D1A038C for ; Wed, 16 Jul 2014 15:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Dl2QZUYcTTVf for ; Wed, 16 Jul 2014 15:43:36 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914BC1A0382 for ; Wed, 16 Jul 2014 15:43:36 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id ey11so2112039pad.38 for ; Wed, 16 Jul 2014 15:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=gE+lWunzXZsoJAys1Dc0iGv3WjiEcDNMWN1AsLO6VPM=; b=Q6CMt6XdcCWLqZCq/EVt4DRD+KndswXALqKs6Pi3MGn7WiV+/C/W8gaAez9BiGigo/ K6uAt5FJyaFa9P/NhowbAQc4qAp7Q/d490cK4DDx6U4PPAwubNh+AzEvb/mB34HMV//3 GN94Ry1z2yvAv6eXeCetLLOev5NfHijN26Q85leB8Q1IsgQEpv3N9LyLtFXSQjO0F/1s gz+d5zJ2labk7hKd8SReMy9KecaUYZjhoeSUQeWmF+LfJn2HjXCmhQ9QNn212GpPUVP/ uQ3YSXMXhom5mNB689U08FBlfNyvwinkbf2MygrFPRYF4PEDszct+Wcip8WIC5y4knR0 js3g== X-Received: by 10.68.245.202 with SMTP id xq10mr24165233pbc.109.1405550616294; Wed, 16 Jul 2014 15:43:36 -0700 (PDT) Received: from [10.100.20.19] ([63.133.199.244]) by mx.google.com with ESMTPSA id y12sm654142pdk.21.2014.07.16.15.43.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Jul 2014 15:43:35 -0700 (PDT) Message-ID: <53C70015.8010208@gmail.com> Date: Thu, 17 Jul 2014 01:43:33 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <53C67728.1040907@usdonovans.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ywWLJCMyYgZEcQUjN3FSwY7_dpI Subject: Re: [Dime] DOIC #62 - Section 3 needs to be made consistent with DIOC solution X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 22:43:38 -0000 Fine by me to close #62. - Jouni 7/16/2014 5:17 PM, Ben Campbell kirjoitti: > On Jul 16, 2014, at 7:59 AM, Steve Donovan wrote: > >> All, >> >> One of the side effects of the restructuring of the DOIC specification was to align section 3 with the normative sections of the document. Based on this, I propose that we close this issue. >> >> Any problems with the text in section 3 of -03 should be dealt with as new problem reports and should propose specific wording changes. >> >> In addition, we need to make sure that any changes to the normative sections get reflected in the informative text in section 3. >> >> If there are no objections then I will close the issue. >> > > No objection here. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Fri Jul 18 02:16:47 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913071A0066 for ; Fri, 18 Jul 2014 02:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 0tW1p1TY2CwE for ; Fri, 18 Jul 2014 02:16:40 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3AE61A0081 for ; Fri, 18 Jul 2014 02:16:39 -0700 (PDT) Received: from localhost ([::1]:47360 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X84HK-0007Ps-I9; Fri, 18 Jul 2014 02:16:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, srdonovan@usdonovans.com X-Trac-Project: dime Date: Fri, 18 Jul 2014 09:16:34 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/62#comment:2 Message-ID: <081.e9d703be6b7f7c3b6e4ff8e26e5c918a@trac.tools.ietf.org> References: <066.eba6aa0bd68b42efe99ac62bc852b2b5@trac.tools.ietf.org> X-Trac-Ticket-ID: 62 In-Reply-To: <066.eba6aa0bd68b42efe99ac62bc852b2b5@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9E3HlX_P5bG1MnqqB5fy4-wZwKs Cc: dime@ietf.org Subject: Re: [Dime] [dime] #62 (draft-ietf-dime-ovli): SEction 3 needs to be made consistent with DIOC solution X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 09:16:44 -0000 #62: SEction 3 needs to be made consistent with DIOC solution Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: Addressed with -03 version. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Fri Jul 18 02:18:17 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502C11B294F for ; Fri, 18 Jul 2014 02:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 EP3I-vBwF3Qy for ; Fri, 18 Jul 2014 02:18:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F39171A0329 for ; Fri, 18 Jul 2014 02:18:06 -0700 (PDT) Received: from localhost ([::1]:47945 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X84Io-0006hP-6R; Fri, 18 Jul 2014 02:18:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com, srdonovan@usdonovans.com X-Trac-Project: dime Date: Fri, 18 Jul 2014 09:18:06 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/54#comment:2 Message-ID: <090.165b54d44a15bb927b78f7b62c55fc1d@trac.tools.ietf.org> References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> X-Trac-Ticket-ID: 54 In-Reply-To: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/T5zSYJLNkq2F42O5tRtzhwnLvPY Cc: dime@ietf.org Subject: Re: [Dime] [dime] #54 (draft-ietf-dime-ovli): OC-Report-Type as mandatory AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 09:18:12 -0000 #54: OC-Report-Type as mandatory AVP Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: Closed based on working group chair declaring rough consensus that the report type is required. This was reflected in the -02 version of the draft. -- -----------------------------------------------+--------------------------- Reporter: maria.cruz.bartolome@ericsson.com | Owner: MCruz Type: defect | Bartolomé Priority: major | Status: closed Component: draft-ietf-dime-ovli | Milestone: Severity: Active WG Document | Version: 1.0 Keywords: | Resolution: fixed -----------------------------------------------+--------------------------- Ticket URL: dime From nobody Fri Jul 18 02:54:31 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8601A019A for ; Fri, 18 Jul 2014 02:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 LC7IlpJzqr5B for ; Fri, 18 Jul 2014 02:54:28 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 177E91A0113 for ; Fri, 18 Jul 2014 02:54:28 -0700 (PDT) Received: from [41.0.204.98] (port=50815 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X84rw-0007lV-Ay for dime@ietf.org; Fri, 18 Jul 2014 02:54:25 -0700 Message-ID: <53C8EEBA.70609@usdonovans.com> Date: Fri, 18 Jul 2014 11:54:02 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/alternative; boundary="------------060606040704080708090204" X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gPXy0U0P32r_ynfOxwzstEgGrYg Subject: [Dime] DOIC #43 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 09:54:30 -0000 This is a multi-part message in MIME format. --------------060606040704080708090204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here is the text from issue 43: ---- In section 3.1.4, under "Intra-Session Requests" indicates that session ending requests should be throttled less aggressively. While I agree that's a good idea in general, I think that's a mater of local policy, and not up to DOIC to specify. It would be better to indicate that prioritization under overload is up to local policy, and list prioritizing of session-ending requests as an example of a potential local policy. ---- And here is the text in the draft that introduces the discussion on potential handling of each type of request: ---- The request classes identified in Section 3.7.3 have implications on decisions about which requests should be throttled first. The following list of request treatment regarding throttling is provided as guidelines for application designers when implementing the Diameter overload control mechanism described in this document. The exact behavior regarding throttling is a matter of local policy, unless specifically defined for the application. ---- I believe that existing text addresses the concern expressed in the problem report and that the issue can be closed with no changes. Regards, Steve --------------060606040704080708090204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Here is the text from issue 43:

----

In section 3.1.4, under "Intra-Session Requests" indicates that session ending requests should be throttled less aggressively. While I agree that's a good idea in general, I think that's a mater of local policy, and not up to DOIC to specify.

It would be better to indicate that prioritization under overload is up to local policy, and list prioritizing of session-ending requests as an example of a potential local policy.

----

And here is the text in the draft that introduces the discussion on potential handling of each type of request:

----

The request classes identified in Section 3.7.3 have implications on
   decisions about which requests should be throttled first.  The
   following list of request treatment regarding throttling is provided
   as guidelines for application designers when implementing the
   Diameter overload control mechanism described in this document.  The
   exact behavior regarding throttling is a matter of local policy,
   unless specifically defined for the application.

----

I believe that existing text addresses the concern expressed in the problem report and that the issue can be closed with no changes.

Regards,

Steve
--------------060606040704080708090204-- From nobody Fri Jul 18 03:08:29 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982B41A019A for ; Fri, 18 Jul 2014 03:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 1HQF0X5zpSJB for ; Fri, 18 Jul 2014 03:08:24 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 E9CF11A0113 for ; Fri, 18 Jul 2014 03:08:24 -0700 (PDT) Received: from [41.0.204.98] (port=50953 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X855T-0003K9-TF for dime@ietf.org; Fri, 18 Jul 2014 03:08:24 -0700 Message-ID: <53C8F215.9040803@usdonovans.com> Date: Fri, 18 Jul 2014 12:08:21 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/alternative; boundary="------------030606040908070001060304" X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Vbwy7skezzQZ9cdHrPiRboRpW3c Subject: [Dime] DOIC #49 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 10:08:27 -0000 This is a multi-part message in MIME format. --------------030606040908070001060304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I propose that we can close issue #49 based on existing text. Here's the wording from issue #49: ---- The capabilities announcement mechanism needs serious rethought. Specifically, the lifetime of the state associated with a capabilities announcement is unclear. It does not make sense to tie that lifetime to Diameter session lifetimes, unless we expect to have different capability sets for different sessions. (and it doesn't help at all for non-session applications or pseudo-sessions.) I think we either need to mandate that the capabilities are stateless, that is, must be included in every request, and any OLR in a response must match the OC-Supported-Features from the corresponding request. Otherwise, we need a way to activate and deactivate the set associated with a capabilities set. (This is a side effect of allowing DOIC to cross non-supporting agents. If we didn't allow that, we could make DOIC support and capabilites negotiation happen as part of the CAR exchange. ) ---- I believe the existing text is pretty clear now (and was in -02) that the lifetime of the capability announcement is a single transaction. Does anyone object to closing this issue? Steve --------------030606040908070001060304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I propose that we can close issue #49 based on existing text.

Here's the wording from issue #49:

----

The capabilities announcement mechanism needs serious rethought. Specifically, the lifetime of the state associated with a capabilities announcement is unclear. It does not make sense to tie that lifetime to Diameter session lifetimes, unless we expect to have different capability sets for different sessions. (and it doesn't help at all for non-session applications or pseudo-sessions.)

I think we either need to mandate that the capabilities are stateless, that is, must be included in every request, and any OLR in a response must match the OC-Supported-Features from the corresponding request. Otherwise, we need a way to activate and deactivate the set associated with a capabilities set.

(This is a side effect of allowing DOIC to cross non-supporting agents. If we didn't allow that, we could make DOIC support and capabilites negotiation happen as part of the CAR exchange. )

----

I believe the existing text is pretty clear now (and was in -02) that the lifetime of the capability announcement is a single transaction. 

Does anyone object to closing this issue?

Steve
--------------030606040908070001060304-- From nobody Fri Jul 18 03:21:32 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16731A0145 for ; Fri, 18 Jul 2014 03:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779] autolearn=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 ydmy1Oier78q for ; Fri, 18 Jul 2014 03:21:29 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 B0BC11A01C8 for ; Fri, 18 Jul 2014 03:21:29 -0700 (PDT) Received: from [41.0.204.98] (port=6901 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X85I7-0004wy-9Y; Fri, 18 Jul 2014 03:21:28 -0700 Message-ID: <53C8F524.1080400@usdonovans.com> Date: Fri, 18 Jul 2014 12:21:24 +0200 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jouni Korhonen , Ben Campbell References: <53C6754B.5020600@usdonovans.com> <53C68B45.1020408@usdonovans.com> <53C6FF6B.9020605@gmail.com> In-Reply-To: <53C6FF6B.9020605@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/rm9voYw3Q7hxbsehkzXOY86zJVo Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC #54: OC-Report-Type as mandatory AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 10:21:30 -0000 Thanks, I have closed the issue. Steve On 7/17/14, 12:40 AM, Jouni Korhonen wrote: > Hi, > > Lionel declared a rough concensus on #54. This issue should be closed. > > - Jouni > > 7/16/2014 5:25 PM, Steve Donovan kirjoitti: >> You are correct, that is what lead to the current text in the -03 >> draft. There has been an objection raised to the declaration. >> >> Steve >> >> On 7/16/14, 4:18 PM, Ben Campbell wrote: >>> I thought our chairs had declared a rough consensus on this. Do I have >>> that confused with another issue? >>> >>> On Jul 16, 2014, at 7:51 AM, Steve Donovan >>> wrote: >>> >>>> All, >>>> >>>> Now that the restructure of the DOIC specification is complete we >>>> need to start resolving open issues. Those that entered the issues >>>> are encouraged to work to get them closed. >>>> >>>> I'll start on #54 in this email. >>>> >>>> The question is whether the OC-Report-Type AVP is required any time >>>> that an OC-OLR AVP is sent. >>>> >>>> The current version of the draft is the same as the -02 version, >>>> showing the AVP as being required. This was based on an earlier >>>> attempt to close the issue prior to -02 being published. >>>> >>>> Susan has stated that she does not think it should be required. If I >>>> understand correctly this is based on the assumption that an HSS >>>> would never send an OLR with report-type of any value but host. >>>> >>>> Susan, please correct me if I'm mistaken. >>>> >>>> I don't believe this is a correct assumption. It is reasonable for >>>> an HSS to send an OLR with report-type of realm. This might happen >>>> in a non agent based deployment or in a deployment where the HSS (or >>>> more generically, server) has knowledge of the status of all servers >>>> for the application. >>>> >>>> Based on this, I propose that the text be kept as is and that this >>>> issue be closed without changes to the specification. >>>> >>>> The threshold for changing what is currently in the DOIC >>>> specification is rough consensus in the group that it should be >>>> changed. Anyone with an opinion is encouraged to state it now. This >>>> is not a vote (we don't vote in the IETF...) but an attempt to see if >>>> we have consensus to either close the issue without a change in the >>>> specification or if we have consensus to change the specification. >>>> >>>> Regards, >>>> >>>> Steve >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > From nobody Fri Jul 18 07:23:50 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A6C1B299B for ; Fri, 18 Jul 2014 07:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 Ra8X_pfkVKD5 for ; Fri, 18 Jul 2014 07:23:34 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 29CDA1B2973 for ; Fri, 18 Jul 2014 07:23:34 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6IENUfh084975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Jul 2014 09:23:33 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53C8F215.9040803@usdonovans.com> Date: Fri, 18 Jul 2014 09:23:30 -0500 X-Mao-Original-Outgoing-Id: 427386210.128045-565ee661baf6aaedf4457cfb50227854 Content-Transfer-Encoding: quoted-printable Message-Id: <51F4B461-08B4-44AB-86C6-3B85A7D7E4E7@nostrum.com> References: <53C8F215.9040803@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/UbU6Uog3z6dl0bIBoEv3yWUOyGw Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC #49 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 14:23:39 -0000 I agree we should close it.=20 On Jul 18, 2014, at 5:08 AM, Steve Donovan = wrote: > I propose that we can close issue #49 based on existing text.=20 >=20 > Here's the wording from issue #49: >=20 > ---- > The capabilities announcement mechanism needs serious rethought. = Specifically, the lifetime of the state associated with a capabilities = announcement is unclear. It does not make sense to tie that lifetime to = Diameter session lifetimes, unless we expect to have different = capability sets for different sessions. (and it doesn't help at all for = non-session applications or pseudo-sessions.) >=20 > I think we either need to mandate that the capabilities are stateless, = that is, must be included in every request, and any OLR in a response = must match the OC-Supported-Features from the corresponding request. = Otherwise, we need a way to activate and deactivate the set associated = with a capabilities set. >=20 > (This is a side effect of allowing DOIC to cross non-supporting = agents. If we didn't allow that, we could make DOIC support and = capabilites negotiation happen as part of the CAR exchange. ) >=20 > ---- >=20 > I believe the existing text is pretty clear now (and was in -02) that = the lifetime of the capability announcement is a single transaction. =20 >=20 > Does anyone object to closing this issue? >=20 > Steve > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Fri Jul 18 07:30:31 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C696D1A0B10 for ; Fri, 18 Jul 2014 07:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 0-R039VCbIW2 for ; Fri, 18 Jul 2014 07:30:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 4E8EC1A0AF3 for ; Fri, 18 Jul 2014 07:30:29 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6IEURsV085542 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Jul 2014 09:30:28 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53C8EEBA.70609@usdonovans.com> Date: Fri, 18 Jul 2014 09:30:26 -0500 X-Mao-Original-Outgoing-Id: 427386626.25059-41c708132a65e67af333405937aab551 Content-Transfer-Encoding: quoted-printable Message-Id: <1FC86899-2008-465A-BC96-0CF29990CBFE@nostrum.com> References: <53C8EEBA.70609@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/DRKCilYHLO4sRTZInLP72D23oF8 Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC #43 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 14:30:31 -0000 I don't agree on this one. The wording of the text at least for intra-session requests is not = consistent with the "these are just guidelines" disclaimer. Like it or = not, people tend to skip over disclaimer text. (This sort of thing = comes up all the time on gen-art reviews. In my personal opinion, If the = disclaimer is for CYA purposes, it makes sense to state it once like we = currently do. But if you want people to actually read it and internalize = it, it needs to be intrinsic to the text.) For example, language of the form of "Session terminating requests = should be throttled less aggressively..." should be more of the form of = "Implementors and operators may wish to throttle ... less agressively." On Jul 18, 2014, at 4:54 AM, Steve Donovan = wrote: > Here is the text from issue 43: >=20 > ---- > In section 3.1.4, under "Intra-Session Requests" indicates that = session ending requests should be throttled less aggressively. While I = agree that's a good idea in general, I think that's a mater of local = policy, and not up to DOIC to specify. >=20 > It would be better to indicate that prioritization under overload is = up to local policy, and list prioritizing of session-ending requests as = an example of a potential local policy. >=20 > ---- >=20 > And here is the text in the draft that introduces the discussion on = potential handling of each type of request: >=20 > ---- >=20 > The request classes identified in Section 3.7.3 have implications on > decisions about which requests should be throttled first. The > following list of request treatment regarding throttling is = provided > as guidelines for application designers when implementing the > Diameter overload control mechanism described in this document. = The > exact behavior regarding throttling is a matter of local policy, > unless specifically defined for the application. >=20 > ---- >=20 > I believe that existing text addresses the concern expressed in the = problem report and that the issue can be closed with no changes. >=20 > Regards, >=20 > Steve > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Fri Jul 18 08:11:55 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A109C1ABB18 for ; Fri, 18 Jul 2014 08:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 7o_A9e4_BJGz for ; Fri, 18 Jul 2014 08:11:49 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A3A1ABB2C for ; Fri, 18 Jul 2014 08:11:46 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id hz1so5519305pad.8 for ; Fri, 18 Jul 2014 08:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ZZygNtdu9PYJxz01dXXETuc+wc0Hb0uzOgKOwR7bg9I=; b=BnsMJbA6K+wFuWa/XGEeMWgu/45ENYsqU0k2gQ1sSPNHClLotiwkaUrYaGQVkt/6sn 53M5TN3wCf6y2/sok8AthrePDvhC6FUHM2PRXTCPankzTzSFzaBLPkK6GjghHWSmmjU/ EcsE0QqhwJoOkshBVHwzuVzmjSnWX06j5DQBPLjl329L1OSOHAnnTg8V8UK5OTOyKt56 ZTQ6gODTXxDtwk0iNFXDHMZjAN+EhWB8k3mAQL1RL5OF/7Y3ceKqWXutZnMUG35t9Q9t xyWOv0Ovvql2vJ/DBPAgXE2AKWkb/7ki9CxkP8smbN99hi5A8KlaayHDKsQUrgnpGPU4 h6Dg== X-Received: by 10.68.227.4 with SMTP id rw4mr5962705pbc.3.1405696305458; Fri, 18 Jul 2014 08:11:45 -0700 (PDT) Received: from [10.199.9.133] ([63.133.197.135]) by mx.google.com with ESMTPSA id by1sm5863868pbb.75.2014.07.18.08.11.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jul 2014 08:11:44 -0700 (PDT) Message-ID: <53C93928.9070406@gmail.com> Date: Fri, 18 Jul 2014 18:11:36 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steve Donovan , "dime@ietf.org" References: <53C8F215.9040803@usdonovans.com> In-Reply-To: <53C8F215.9040803@usdonovans.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/U5q3l5aotWnKUp-D2X6mCBZzU_g Subject: Re: [Dime] DOIC #49 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 15:11:53 -0000 We should close this as fixed. - Jouni 7/18/2014 1:08 PM, Steve Donovan kirjoitti: > I propose that we can close issue #49 based on existing text. > > Here's the wording from issue #49: > > ---- > > The capabilities announcement mechanism needs serious rethought. > Specifically, the lifetime of the state associated with a capabilities > announcement is unclear. It does not make sense to tie that lifetime to > Diameter session lifetimes, unless we expect to have different > capability sets for different sessions. (and it doesn't help at all for > non-session applications or pseudo-sessions.) > > I think we either need to mandate that the capabilities are stateless, > that is, must be included in every request, and any OLR in a response > must match the OC-Supported-Features from the corresponding request. > Otherwise, we need a way to activate and deactivate the set associated > with a capabilities set. > > (This is a side effect of allowing DOIC to cross non-supporting agents. > If we didn't allow that, we could make DOIC support and capabilites > negotiation happen as part of the CAR exchange. ) > > ---- > > I believe the existing text is pretty clear now (and was in -02) that > the lifetime of the capability announcement is a single transaction. > > Does anyone object to closing this issue? > > Steve > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Fri Jul 18 12:26:04 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB2E1B2A45 for ; Fri, 18 Jul 2014 12:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 8gYJzWhz1WLI for ; Fri, 18 Jul 2014 12:25:59 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD5201A008F for ; Fri, 18 Jul 2014 12:25:59 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j17so3969019oag.28 for ; Fri, 18 Jul 2014 12:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EEbbaOp0Y70DqqErIivUt9pN1qmHm884X4Sb+LZl+UQ=; b=tzZ6Vv1kByHv+Uv+g4mKUpZxWHHrIkAibRRsEqQyWJCOcg1sYaLT5rll1/WXrgTWid 73396kaJFKU1M7kHTqvis5zNURbpxhIX0paZxgPSB5suPtDJdMDsthO5w5h0TzYjmWxN 1A/bDv13J7v/tn/Pi8QyDL5URknEk9v0aeu69RBrLyCn4UbDPMWL1M4v5AClxKL70rer B7Ds07QRCuhJ/HEYYrM97yZYrPh/H/lySvi6Hb+AoaG7CerjCrpuTpbqrmwj/ux2DPU+ HB2hdvs93QCU+UbZJkntukkQnar1WAGNvgRI0MkDpnKZBl5ZVZTvYVNJ+/Gmk58l5/d5 LjPA== MIME-Version: 1.0 X-Received: by 10.182.66.130 with SMTP id f2mr10190066obt.84.1405711559166; Fri, 18 Jul 2014 12:25:59 -0700 (PDT) Received: by 10.202.181.70 with HTTP; Fri, 18 Jul 2014 12:25:59 -0700 (PDT) Date: Fri, 18 Jul 2014 21:25:59 +0200 Message-ID: From: Matt Holdrege To: dime@ietf.org Content-Type: multipart/alternative; boundary=001a11c1f61e243a3c04fe7cbabd Archived-At: http://mailarchive.ietf.org/arch/msg/dime/RxYVspShKOTZEt7Al66KjcANpo8 Subject: [Dime] Strange paragraph in http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-21 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 19:26:01 -0000 --001a11c1f61e243a3c04fe7cbabd Content-Type: text/plain; charset=UTF-8 Hi, Sorry to butt in with a minor nit, but I noticed that section 2.2 appears to have mutually exclusive statements. 1. Connections between Diameter peers SHOULD be protected by TLS. 2. The Diameter protocol MUST NOT be used without any security mechanism. I thought the text in RFC 3588 was ok, minus all the NAS bits? Or maybe say that the "Diameter protocol must not be used without inclusive or external transport layer security". Or some such text? -Matt --001a11c1f61e243a3c04fe7cbabd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Sorry to butt in with a minor nit, = but I noticed that section 2.2 appears to have mutually exclusive statement= s.=C2=A0

1.=C2=A0Connections between Diameter peers SHOULD be protected by TLS= .
2.=C2=A0The Di= ameter protocol MUST NOT be used=C2=A0without any security mecha= nism.

I thought the text in RFC 3588 was ok, minus all the NAS bits? O= r maybe say that the "Diameter protocol must not be used without=C2=A0= inclusive=C2=A0or external transport layer=C2=A0security". Or some suc= h text?=C2=A0

-Matt

--001a11c1f61e243a3c04fe7cbabd-- From nobody Fri Jul 18 14:58:00 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD4E1A006C for ; Fri, 18 Jul 2014 14:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 VzLsmodCuGxE for ; Fri, 18 Jul 2014 14:57:56 -0700 (PDT) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6108C1A0064 for ; Fri, 18 Jul 2014 14:57:56 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id eu11so6179214pac.17 for ; Fri, 18 Jul 2014 14:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=nLtr21XwngMsgtt29PytlgpPrAy7Zs6/86/wZ8ObhSc=; b=eOR3kG2wfHVhS3H7y/BEiV/ttY5trtsNOKfETfTJ2VS24EmxHr/XM9ccCdJ+b1P3zs GCXR6sEpBhUwRLCvqV9maC37EBYSFftYuaUWDWiHzUBYSmyIyuEJrFr+xZ90wn1bMctf bYANTHVBs0vneujI5K67VQGhuAGtQh6SUvIVqKGcstzyGt9CEY3SqmgyJVj/RwMKheYX rzk1hEt3reuBhbgc1i1GRXU0b3Vju5r67AIyVklPTRA3wk8Ioi05KEtzlKJkRybbQFJB ndFUmSd4CgLUnJ0d7B05IkGJdg5aXwasX4c+xWSg5242q3tPRhkkaErYFiG9w998/voh yYIA== X-Received: by 10.68.193.164 with SMTP id hp4mr8403177pbc.87.1405720676097; Fri, 18 Jul 2014 14:57:56 -0700 (PDT) Received: from [10.199.10.100] ([63.133.197.135]) by mx.google.com with ESMTPSA id kg1sm6577201pbc.22.2014.07.18.14.57.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jul 2014 14:57:54 -0700 (PDT) Message-ID: <53C9985F.4080908@gmail.com> Date: Sat, 19 Jul 2014 00:57:51 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Matt Holdrege , dime@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KhuFv6vGTxwsHM_gYwOxDef07jc Subject: Re: [Dime] Strange paragraph in http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-21 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 21:57:58 -0000 Matt, RFC3588 has been obsoleted by RFC6733 (i.e. no use to look into 3588bis versions). - Jouni 7/18/2014 10:25 PM, Matt Holdrege kirjoitti: > Hi, > > Sorry to butt in with a minor nit, but I noticed that section 2.2 > appears to have mutually exclusive statements. > > 1. Connections between Diameter peers SHOULD be protected by TLS. > 2. The Diameter protocol MUST NOT be used without any security mechanism. > > I thought the text in RFC 3588 was ok, minus all the NAS bits? Or maybe > say that the "Diameter protocol must not be used without inclusive or > external transport layer security". Or some such text? > > -Matt > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Sat Jul 19 00:29:53 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8642E1B27BF for ; Sat, 19 Jul 2014 00:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 macd9dq9IZD2 for ; Sat, 19 Jul 2014 00:29:43 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A926B1A0331 for ; Sat, 19 Jul 2014 00:29:42 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s6J7Teat016324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 19 Jul 2014 07:29:40 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s6J7TdmZ002044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 19 Jul 2014 09:29:39 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.93]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0181.006; Sat, 19 Jul 2014 09:29:38 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Fwd: New Version Notification for draft-donovan-doic-agent-cases-00.txt Thread-Index: AQHPmIoin2/POQT9m0ympVT5CI4JSZuabRIwgAPlmoCAB9ZGoA== Date: Sat, 19 Jul 2014 07:29:38 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151FE346@DEMUMBX014.nsn-intra.net> References: <20140703161711.24974.27021.idtracker@ietfa.amsl.com> <53B85695.2010208@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151F77ED@DEMUMBX014.nsn-intra.net> <53C2E13F.8070406@usdonovans.com> In-Reply-To: <53C2E13F.8070406@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.122] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 28636 X-purgate-ID: 151667::1405754980-00007A71-7281D488/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/PyU4j9yIupwRzNtjuJndvX6kb7w Subject: Re: [Dime] Fwd: New Version Notification for draft-donovan-doic-agent-cases-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 07:29:47 -0000 U3RldmUsDQoNCnNlZSBteSByZXNwb25zZSBpbmxpbmUuDQoNClVscmljaA0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZXh0IFN0ZXZlIERvbm92YW4gW21haWx0bzpzcmRvbm92 YW5AdXNkb25vdmFucy5jb21dIA0KU2VudDogU3VuZGF5LCBKdWx5IDEzLCAyMDE0IDk6NDMgUE0N ClRvOiBXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpOyBkaW1lQGlldGYub3JnDQpDYzog UmF1c2NoZW5iYWNoLCBVd2UgKE5TTiAtIERFL011bmljaCkNClN1YmplY3Q6IFJlOiBbRGltZV0g RndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRvbm92YW4tZG9pYy1hZ2Vu dC1jYXNlcy0wMC50eHQNCg0KVWxyaWNoLA0KDQpTb21lIGNvbW1lbnRzIGlubGluZS4NCg0KU3Rl dmUNCg0KT24gNy8xMS8xNCwgMjowMyBQTSwgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNo KSB3cm90ZToNCj4gU3RldmUsDQo+DQo+IEhlcmUgYXJlIG15IGNvbW1lbnRzOg0KPg0KPiAxLiBB YnN0cmFjdCAybmQgc2VudGVuY2U6DQo+IFRoZSBzZW50ZW5jZSBzaG91bGQgcmVhZDogIkEgRE9J QyBub2RlIGlzIGEgRGlhbWV0ZXIgbm9kZSB0aGF0IGluIGEgZ2l2ZW4gY29udGV4dCBtYXkgYWN0 IGFzIGEgcmVwb3J0aW5nIG5vZGUgb3IgYSByZWFjdGluZyBub2RlLiINCj4gVGhpcyBpcyB0byBh bGlnbiB5b3VyIGRlZmluaXRpb24gIkFueSBEaWFtZXRlciBub2RlIHRoYXQgc3VwcG9ydHMgRE9J QyBpcyBhIERPSUMgbm9kZSIgKHNlZSAxLiBJbnRyb2R1Y3Rpb24sIGxhc3QgcGFyYWdyYXBoKSB3 aXRoIG91ciBjb21tb24gdW5kZXJzdGFuZGluZyBvZiB0aGUgImVuZC10by1lbmQgY29uY2VwdCIg d2hpY2ggYWxsb3dzIGEgRE9JQyBub2RlIHNpdHRpbmcgYmV0d2VlbiBhIHN1cHBvcnRpbmcgY2xp ZW50IGFuZCBhIHN1cHBvcnRpbmcgc2VydmVyIHRvIGJlIHRyYW5zcGFyZW50Lg0KPg0KPiAyLiBj bGF1c2UgMS4xIFRlcm1pbm9sb2d5IGFuZCBBYmJyZXZpYXRpb25zLCBBYmF0aW5nIG5vZGU6DQo+ IFRoZSBkZWZpbml0aW9uIHNob3VsZCByZWFkOiAiQSByZWFjdGluZyBub2RlIHRoYXQgbG9jYWxs eSBwZXJmb3JtcyBvdmVybG9hZCBhYmF0ZW1lbnQgKGkuZS4gdGhyb3R0bGluZyBvciBkaXZlcnNp b24gYnV0IG5vdCBkZWxlZ2F0aW9uKS4iDQo+DQo+IDMuIGxvdHMgb2YgY29sb25zIG1pc3Npbmcg aW4gY2xhdXNlIDEuMQ0KPg0KPiA0LiBjbGF1c2UgMS4xIFRlcm1pbm9sb2d5IGFuZCBBYmJyZXZp YXRpb25zLCBPdmVybG9hZCBBYmF0ZW1lbnQ6DQo+IFRoZSBkZWZpbml0aW9uIHNob3VsZCByZWFk OiAiLi4uLi4uIE92ZXJsb2FkIGFiYXRlbWVudCBhY3Rpb25zIG1heSBpbnZvbHZlIGxvY2FsIHRy YWZmaWMgcmVkdWN0aW9uLCBvciBkZWxlZ2F0aW9uIG9mIGFjdGlvbnMgdG93YXJkcyB0aGUgY2xp ZW50IChEZWxlZ2F0aW9uKS4gTG9jYWwgdHJhZmZpYyByZWR1Y3Rpb24gY2FuIGJlIGFjaGlldmVk IGJ5IGVpdGhlciByZWplY3RpbmcgYSByZXF1ZXN0IChUaHJvdHRsaW5nKSBvciBieSByb3V0aW5n IGEgcmVxdWVzdCB0byBhIGRpZmZlcmVudCBkZXN0aW5hdGlvbiAoRGl2ZXJzaW9uKS4iDQo+DQo+ IDUuIGNsYXVzZSAxLjEgVGVybWlub2xvZ3kgYW5kIEFiYnJldmlhdGlvbnMsIERpdmVyc2lvbjoN Cj4gSSBwcm9wb3NlIHRvIGFkZCB0aGUgZm9sbG93aW5nIGNsYXJpZmljYXRpb246DQo+IERpdmVy c2lvbiBpcyBzcGVjaWZpYyB0byBhZ2VudHMgdGhhdCBwZXJmb3JtIHNlcnZlciBzZWxlY3Rpb24g Zm9yIHJlYWxtLXJvdXRlZCByZXF1ZXN0cy4NClNSRD4gSSBkaXNhZ3JlZS4gIERpdmVyc2lvbiBp cyBhbHNvIGEgdmFsaWQgYWJhdGVtZW50IGFjdGlvbiB0aGF0IGNhbiBiZSANCnRha2VuIG9uIHJl YWxtLXJvdXRlZCByZXF1ZXN0cyBieSBhIHRyYW5zYWN0aW9uIGNsaWVudCB0aGF0IGhhcyBhIGRp cmVjdCANCnRyYW5zcG9ydCBjb25uZWN0aW9uIHRvIGFuIG92ZXJsb2FkZWQgdHJhbnNhY3Rpb24g c2VydmVyLg0KW1dpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCldIEkgYWdyZWUuIFNvIHRo ZSBjbGFyaWZpY2F0aW9uIHNob3VsZCByZWFkOiAiRGl2ZXJzaW9uIGlzIHNwZWNpZmljIHRvIG5v ZGVzIChhZ2VudHMgYW5kIGNsaWVudHMpIHRoYXQgcGVyZm9ybSBzZXJ2ZXIgc2VsZWN0aW9uIGZv ciByZWFsbS1yb3V0ZWQgcmVxdWVzdHMuIg0KPg0KPiA2LiBjbGF1c2UgMS4xIFRlcm1pbm9sb2d5 IGFuZCBBYmJyZXZpYXRpb25zOg0KPiBJIHByb3Bvc2UgdG8gYWxzbyBkZWZpbmUgd2hhdCBEZWxl Z2F0aW9uIGlzOg0KPiAiRGVsZWdhdGlvbjogT3ZlcmxvYWQgYWJhdGVtZW50IHRocm91Z2ggdGhl IGRlbGVnYXRpb24gb2YgYWN0aW9uIChUaHJvdHRsaW5nKSB0byBhIGZ1cnRoZXIgZG93bnN0cmVh bSByZWFjdGluZyBub2RlLiBEZWxlZ2F0aW9uIGlzIHNwZWNpZmljIHRvIGFnZW50cyB0aGF0IHBl cmZvcm0gc2VydmVyIHNlbGVjdGlvbiBmb3IgcmVhbG0tcm91dGVkIHJlcXVlc3RzLCBhbmQgaXMg dHlwaWNhbGx5IGRvbmUgd2hlbiB0aGUgYWdlbnQgZGV0ZWN0cyB0aGF0IGFsbCBhdmFpbGFibGUg c2VydmVycyBoYXZlIHJlcXVlc3RlZCBsb2FkIHJlZHVjdGlvbiwgaS5lLiB3aGVuIHJlY2Vpdmlu ZyBhbiBhbnN3ZXIgbWVzc2FnZSBpbiByZXNwb25zZSB0byBhIChub3QgdGhyb3R0bGVkKSByZXF1 ZXN0IHRoYXQgd2FzIGZvcndhcmRlZCB0byBhIHNlbGVjdGVkIHNlcnZlciB3aGljaCBpbiB0aGUg YW5zd2VyIHJlcG9ydHMgYW4gdXBkYXRlIG9mIGl0cyBvdmVybG9hZCBpbmZvcm1hdGlvbi4iDQo+ DQo+IDcuIGNsYXVzZSAyIERlcGxveW1lbnQgQXJjaGl0ZWN0dXJlcw0KPiBUaGVyZSBhcmUgbWFu eSBtb3JlIGFyY2hpdGVjdHVyZXMgYW5kIHNjZW5hcmlvcyB3aGljaCBjYW5ub3QgYWxsIGJlIGNv dmVyZWQgc2VwYXJhdGVseS4gSSB0aGVyZWZvcmUgcHJvcG9zZSB0byBmb2N1cyBvbiBnZW5lcmFs IHByaW5jaXBsZXMgdGhhdCBET0lDIGFnZW50cyBtdXN0IGZvbGxvdyBpbmRlcGVuZGVudCBmcm9t IGFyY2hpdGVjdHVyZSBhbmQgc2NlbmFyaW8uIFRoZXNlIHByaW5jaXBsZXMgYXJlOg0KU1JEPiBJ IGFncmVlIHRoYXQgd2UgbmVlZCB0byByZXNvbHZlIHRvIGdlbmVyYWwgcHJpbmNpcGxlcywgYnV0 IHRoZXkgDQpuZWVkIHRvIGFkZHJlc3MgcmVhc29uYWJsZSBkZXBsb3ltZW50IGFyY2hpdGVjdHVy ZXMuICBXZSBjYW5ub3QsIGFuZCBkbyANCm5vdCwga25vdyBpbiBhZHZhbmNlIHRoZSBkZXBsb3lt ZW50IGFyY2hpdGVjdHVyZXMgdGhhdCB3aWxsIGJlIA0KaW1wbGVtZW50ZWQgYnkgdXNlcnMgb2Yg dGhlIERpYW1ldGVyIHByb3RvY29sLiAgSW4gYWRkaXRpb24sIHdlIHNob3VsZCANCm5vdCBrbm93 aW5nbHkgbGltaXQgdGhvc2UgZGVwbG95bWVudCBhcmNoaXRlY3R1cmVzIGluIHRoZSB3YXkgdGhl IA0KcHJvdG9jb2wgaXMgZGVzaWduZWQuDQo+DQo+IEEpIFdoZW4gYW4gYWdlbnQgcmVjZWl2ZXMg YSBob3N0LXJvdXRlZCByZXF1ZXN0IHRoYXQgY29udGFpbnMgYW4gT0MtUy1GIEFWUCwgaXQgdGFr ZXMgbm8gRE9JQy1zcGVjaWZpYyBhY3Rpb24sIGkuZS4gaXQgZm9yd2FyZHMgdGhlIHJlcXVlc3Qg dG8gdGhlIG5leHQgaG9wIHdpdGhvdXQgcmVtb3ZpbmcsIG1vZGlmeWluZyBvciBpbnNlcnRpbmcg T0MgQVZQczsgYWxzbyBubyBET0lDIHNwZWNpZmljIGFjdGlvbiBpcyBwZXJmb3JtZWQgd2hlbiBy ZWNlaXZpbmcgdGhlIGNvcnJlc3BvbmRpbmcgYW5zd2VyLiBUaGUgYWdlbnQgbWF5IGhvd2V2ZXIg c3RvcmUgT0xSIGluZm9ybWF0aW9uIHJlY2VpdmVkIGluIHRoZSBhbnN3ZXIgZm9yIHBvdGVudGlh bCBsYXRlciB1c2UgaWYgaXQgc3VwcG9ydHMgdGhlIGZlYXR1cmVzIGFzc29jaWF0ZWQgd2l0aCB0 aGUgT0xSLg0KU1JEPiBJIGRpc2FncmVlLiAgSSB0aGluayB0aGUgZHJhZnQgc2hvd3MgbXVsdGlw bGUgcmVhc29ucyB3aGVyZSBpdCANCndvdWxkIGJlIHJlYXNvbmFibGUgZm9yIGFuIGFnZW50IHRv IG1vZGlmeSAgT1MtUy1GIEFWUHMgaW4gYSByZXF1ZXN0IA0KbWVzc2FnZS4NCltXaWVoZSwgVWxy aWNoIChOU04gLSBERS9NdW5pY2gpXSBJIGRpc2FncmVlLiBUaGUgc2NlbmFyaW9zIHdoZXJlIGl0 IGlzIHJlYXNvbmFibGUgZm9yIGFuIGFnZW50IHRvIG1vZGlmeSAoYmV0dGVyOiByZXBsYWNlKSB0 aGUgT0MtUy1GIEFWUCBhcmUgbGltaXRlZCB0byBjYXNlIHdoZXJlIHRoZSByZXF1ZXN0IGlzIHJl YWxtLXJvdXRlZCBhbmQgdGhlIGFnZW50IHBlcmZvcm1zIHNlcnZlciBzZWxlY3Rpb24uIFRoaXMg aXMgdGhlIG9ubHkgcmVhc29uYWJsZSBjYXNlIHdoZXJlIGFuIGFnZW50IGluIHRoZSBtaWRkbGUg dGVybWluYXRlcyB0aGUgKGRvd25zdHJlYW0pIERPSUMgYXNzb2NpYXRpb24gYW5kIG9wZW5zIGFu IGluZGVwZW5kZW50ICh1cHN0cmVhbSkgRE9JQyBhc3NvY2lhdGlvbi4NCj4NCj4gQikgV2hlbiBh biBhZ2VudCByZWNlaXZlcyBhIGhvc3Qtcm91dGVkIHJlcXVlc3QgdGhhdCBkb2VzIG5vdCBjb250 YWluIGFuIE9DLVMtRiBBVlAsIGl0IHBlcmZvcm1zIHRocm90dGxpbmcgYWNjb3JkaW5nIHRvIGEg cHJldmlvdXNseSByZWNlaXZlIGhvc3QtdHlwZSBPTFIgKGlmIGFueSkuSWYgdGhlIHJlcXVlc3Qg c3Vydml2ZXMgKG9yIG5vIHRocm90dGxpbmcgd2FzIHBlcmZvcm1lZCBiZWNhdXNlIG5vIGhvc3Qt dHlwZSBPTFIgbWF0Y2hlZCksIHRoZSBhZ2VudCBpbnNlcnRzIGFuIE9DLVMtRiBBVlAgYW5kIHNl bmRzIHRoZSByZXF1ZXN0IHRvIHRoZSBuZXh0IGhvcC4gV2hlbiByZWNlaXZpbmcgdGhlIGNvcnJl c3BvbmRpbmcgYW5zd2VyLCB0aGUgYWdlbnQgY2hlY2tzIHdoZXRoZXIgaXQgY29udGFpbnMgYW4g T0xSIHVwZGF0ZSBhbmQgaWYgc28gcmVwbGFjZXMgdGhlIHN0b3JlZCBpbmZvIChpZiBhbnkpIHdp dGggdGhlIHVwZGF0ZWQgaW5mby4gSW4gYW55IGNhc2UgdGhlIGFnZW50IHJlbW92ZXMgdGhlIE9M UiBmcm9tIHRoZSBhbnN3ZXIgYmVmb3JlIHNlbmRpbmcgaXQgdG8gdGhlIHByZXZpb3VzIGhvcC4N ClNSRD4gVGhlIGFnZW50IG11c3QgaGF2ZSBpbnNlcnRlZCBPQy1TLUYgQVZQcyBpbiBwcmV2aW91 cyByZXF1ZXN0cyBpbiANCm9yZGVyIHRvIHJlY2VpdmUgYW4gT0MtT0xSIGluIGFuIGFuc3dlci4g IEl0IGZlZWxzIGxpa2UgeW91IGFyZSBtYWtpbmcgDQppbiBtdWNoIG1vcmUgY29tcGxleCB0aGFu IG5lZWRlZCBhbmQgYXJlIHRyeWluZyB0byBjb25zdHJhaW4gdXNlcidzIG9mIA0KdGhlIERpYW1l dGVyIHByb3RvY29sIGluIHRoZSB3YXkgb3ZlcmxvYWQgY2FuIGJlIGhhbmRsZWQuDQoNClNSRD4g SXQgY2FuIGJlIGtlcHQgc2ltcGxlIC0tIElmIGFuIGFnZW50IHJlY2VpdmVzIGEgcmVxdWVzdCAt LSANCnJlYWxtLXJvdXRlZCBvciBob3N0LXJvdXRlZCAtLSB0aGF0IGRvZXMgbm90IGNvbnRhaW4g YSBPQy1TLUYgQVZQIHRoZW4gDQppdCBTSE9VTEQvTUFQIChzdHJlbmd0aCBvZiB0aGUgcmVxdWly ZW1lbnQgVEJEKSBpbnNlcnQgYW4gT0MtUy1GIEFWUCBpbiANCnRoZSByZXF1ZXN0IG1lc3NhZ2Uu ICBJZiBsb2NhbCBwb2xpY3kgaW5kaWNhdGVzIHRoYXQgdGhlIGFnZW50IGlzIHRha2luZyANCm9u IHJlc3BvbnNpYmlsaXR5IGZvciBoYW5kbGluZyBvdmVybG9hZCBmb3Igbm9uIHN1cHBvcnRpbmcg dHJhbnNhY3Rpb24gDQpjbGllbnRzIHRoZW4gdGhlIGFnZW50IE1VU1QgaW5zZXJ0IGFuIE9DLVMt RiBBVlAgaW4gdGhlIHJlcXVlc3QgbWVzc2FnZS4NCltXaWVoZSwgVWxyaWNoIChOU04gLSBERS9N dW5pY2gpXSB0aGlzIGlzIHNpbXBsZSBidXQgbWlzbGVhZGluZzogdGhlcmUgYXJlIGFsc28gY2Fz ZXMgd2hlcmUgdGhlIGFnZW50IG5laXRoZXIgaW5zZXJ0cyBhbiBPQy1TLUYgQVZQIG5vciBkb2Vz IG5vdCBpbnNlcnQgYW4gT0MtUy1GIEFWUCwgbmFtZWx5IHdoZW4gdGhlIHJlcXVlc3QgZG9lcyBu b3Qgc3Vydml2ZSB0aHJvdHRsaW5nLiANCj4NCj4gQykgV2hlbiBhbiBhZ2VudCB0aGF0IGlzIG5v dCBjb25maWd1cmVkIHRvIHBlcmZvcm0gc2VydmVyIHNlbGVjdGlvbiBmb3IgcmVhbG0tcm91dGVk IHJlcXVlc3RzIHJlY2VpdmVzIGEgcmVhbG0tcm91dGVkIHJlcXVlc3QgdGhhdCBjb250YWlucyBh biBPQy1TLUYgQVZQLCBpdCB0YWtlcyBubyBET0lDLXNwZWNpZmljIGFjdGlvbiwgaS5lLiBpdCBm b3J3YXJkcyB0aGUgcmVxdWVzdCB0byB0aGUgbmV4dCBob3Agd2l0aG91dCByZW1vdmluZywgbW9k aWZ5aW5nIG9yIGluc2VydGluZyBPQyBBVlBzOyBhbHNvIG5vIERPSUMgc3BlY2lmaWMgYWN0aW9u IGlzIHBlcmZvcm1lZCB3aGVuIHJlY2VpdmluZyB0aGUgY29ycmVzcG9uZGluZyBhbnN3ZXIuIFRo ZSBhZ2VudCBtYXkgaG93ZXZlciBzdG9yZSBPTFIgaW5mb3JtYXRpb24gcmVjZWl2ZWQgaW4gdGhl IGFuc3dlciBmb3IgcG90ZW50aWFsIGxhdGVyIHVzZSBpZiBpdCBzdXBwb3J0cyB0aGUgZmVhdHVy ZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBPTFIuDQpTUkQ+IFRoZXJlIGFyZSBzY2VuYXJpb3Mgd2hl cmUgaXQgc2hvdWxkLCBiYXNlZCBvbiBsb2NhbCBwb2xpY3ksIG1vZGlmeSANCnRoZSBPQy1TLUYg QVZQLCB0aGlzIHdhcyBzaG93biBpbiB0aGUgZHJhZnQuICBXaHkgYXJlIHlvdSBwcm9wb3Npbmcg dG8gDQpsaW1pdCBob3cgYSB1c2VyIG9mIERpYW1ldGVyIGNhbiBtYW5hZ2Ugb3ZlcmxvYWQgaW4g dGhlaXIgbmV0d29ya3M/ICBXaHkgDQpkbyB5b3UgcHJvcG9zZSB0aGF0IHRoZSByYXRlIGFsZ29y aXRobSBjYW5ub3QgYmUgdHVybmVkIG9uIHdoZW4gDQp0cmFuc2FjdGlvbiBjbGllbnRzIG9ubHkg c3VwcG9ydCB0aGUgbG9zcyBhbGdvcml0aG0/DQpbV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVu aWNoKV0gVGhlcmUgYXJlIHNldmVyYWwgcmVhc29ucy4gQnV0IG1haW5seSB0byBrZWVwIHRoaW5n cyBzaW1wbGUgYW5kIGF2b2lkIHByb2JsZW1zIHdlIGhhdm4ndCBzb2x2ZWQgc28gZmFyLiBFLmcu IHdoZW4gdGhlIGNsaWVudCBzZW5kcyBzb21lIHJlcXVlc3RzIHRvIHRoZSBzZXJ2ZXIgdmlhIEEx IGFuZCBvdGhlciByZXF1ZXN0cyB2aWEgQTIsIE9MUnMgc2VjZWl2ZWQgYnkgdGhlIGNsaWVudCB3 aWxsIHNvb24gYmUgb3V0IG9mIHN5bmMuIA0KPg0KPiBEKSBXaGVuIGFuIGFnZW50IHRoYXQgaXMg bm90IGNvbmZpZ3VyZWQgdG8gcGVyZm9ybSBzZXJ2ZXIgc2VsZWN0aW9uIGZvciByZWFsbS1yb3V0 ZWQgcmVxdWVzdHMgcmVjZWl2ZXMgYSByZWFsbS1yb3V0ZWQgcmVxdWVzdCB0aGF0IGRvZXMgbm90 IGNvbnRhaW4gYW4gT0MtUy1GIEFWUCwgaXQgcGVyZm9ybXMgdGhyb3R0bGluZyBhY2NvcmRpbmcg dG8gYSBwcmV2aW91c2x5IHJlY2VpdmUgcmVhbG0tdHlwZSBPTFIgKGlmIGFueSkuSWYgdGhlIHJl cXVlc3Qgc3Vydml2ZXMgKG9yIG5vIHRocm90dGxpbmcgd2FzIHBlcmZvcm1lZCBiZWNhdXNlIG5v IHJlYWxtLXR5cGUgT0xSIG1hdGNoZWQpLCB0aGUgYWdlbnQgaW5zZXJ0cyBhbiBPQy1TLUYgQVZQ IGFuZCBzZW5kcyB0aGUgcmVxdWVzdCB0byB0aGUgbmV4dCBob3AuIFdoZW4gcmVjZWl2aW5nIHRo ZSBjb3JyZXNwb25kaW5nIGFuc3dlciwgdGhlIGFnZW50IGNoZWNrcyB3aGV0aGVyIGl0IGNvbnRh aW5zIGFuIE9MUiB1cGRhdGUgYW5kIGlmIHNvIHJlcGxhY2VzIHRoZSBzdG9yZWQgaW5mbyAoaWYg YW55KSB3aXRoIHRoZSB1cGRhdGVkIGluZm8uIEluIGFueSBjYXNlIHRoZSBhZ2VudCByZW1vdmVz IHRoZSBPTFIgZnJvbSB0aGUgYW5zd2VyIGJlZm9yZSBzZW5kaW5nIGl0IHRvIHRoZSBwcmV2aW91 cyBob3AuDQpTUkQ+IEknbSBub3Qgc3VyZSB0aGlzIGlzIGEgdmFsaWQgc2NlbmFyaW8uICBBbiBh Z2VudCB0aGF0IHJlY2VpdmVzIGEgDQpyZWFsbS1yb3V0ZWQgcmVxdWVzdCBtdXN0IGJlIGNvbmZp Z3VyZWQgdG8gcGVyZm9ybSBzZXJ2ZXIgc2VsZWN0aW9uLiAgDQpJdCdzIHByZXR0eSB1c2VsZXNz IG90aGVyd2lzZS4NCltXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpXSBJIGRvIG5vdCBh Z3JlZS4gQW4gYWdlbnQgdGhhdCByZWNlaXZlcyBhIHJlYWxtLXJvdXRlZCByZXF1ZXN0IG1heSBi ZSBjb25maWd1cmVkIHRvIGp1c3Qgc2VsZWN0IHRoZSBuZXh0IGhvcCAoaS5lLiByb3V0ZSB0byBh bm90aGVyIGFnZW50IHdoaWNoIG1heSBiZSBjb25maWd1cmVkIHRvIHBlcmZvcm0gc2VydmVyIHNl bGVjdGlvbikNCj4NCj4gRSkgV2hlbiBhbiBhZ2VudCB0aGF0IGlzIGNvbmZpZ3VyZWQgdG8gcGVy Zm9ybSBzZXJ2ZXIgc2VsZWN0aW9uIGZvciByZWFsbS1yb3V0ZWQgcmVxdWVzdHMgcmVjZWl2ZXMg YSByZWFsbS1yb3V0ZWQgcmVxdWVzdCB0aGF0IGNvbnRhaW5zIGFuIE9DLVMtRiBBVlAsIGl0IHBl cmZvcm1zIHNlcnZlciBzZWxlY3Rpb24sIGFkZHMgdGhlIERlc3RpbmF0aW9uLUhvc3QgQVZQIHdp dGggdGhlIHZhbHVlIGlkZW50aWZ5aW5nIHRoZSBzZWxlY3RlZCBzZXJ2ZXIgdG8gdGhlIHJlcXVl c3QgKHRoaXMgbmVlZCBub3QgYmUgZG9uZSB3aGVuIHRoZSBzZWxlY3RlZCBzZXJ2ZXIgaXMgYW4g aW1tZWRpYXRlIHBlZXIpLCByZXBsYWNlcyB0aGUgcmVjZWl2ZWQgT0MtUy1GIEFWUCB3aXRoIGl0 cyBvd24gT0MtUy1GIEFWUCBpbiB0aGUgcmVxdWVzdCBhbmQgZm9yd2FyZHMgdGhlIHJlcXVlc3Qg dG8gdGhlIG5leHQgaG9wLiBXaGVuIHJlY2VpdmluZyB0aGUgY29ycmVzcG9uZGluZyBhbnN3ZXIg dGhlIGFnZW50IGNoZWNrcyB3aGV0aGVyIGl0IGNvbnRhaW5zIGFuIE9MUiB1cGRhdGUgYW5kIGlm IHNvIHJlcGxhY2VzIHRoZSBzdG9yZWQgaW5mbyAoaWYgYW55KSB3aXRoIHRoZSB1cGRhdGVkIGlu Zm8sIGNhbGN1bGF0ZXMgYW4gKGFnZ3JlZ2F0ZWQpIHJlYWxtLXR5cGUgT0xSIHRoYXQgZml0cyB0 byB0aGUgc3VwcG9ydGVkIGZlYXR1cmVzIGFzIHJlY2VpdmVkIGluIHRoZSByZXF1ZXN0LiBJbiBh bnkgY2FzZSB0aGUgYWdlbnQgcmVwbGFjZXMgdGhlIE9DLVMtRiBpbiB0aGUgYW5zd2VyIHdpdGgg aXRzIG93biBPQy1TLUYgKGluZGljYXRpbmcgdGhlIHNlbGVjdGVkIGFsZ29yaXRobSksIHJlbW92 ZXMgdGhlIE9DLU9MUiBmcm9tIHRoZSBhbnN3ZXIgYW5kIGFkZHMgaXRzIG93biBjYWxjdWxhdGVk IGFnZ3JlZ2F0ZWQgcmVhbG0tdHlwZSBPTFIgKGlmIGFueSkgdG8gdGhlIGFuc3dlciBiZWZvcmUg c2VuZGluZyBpdCB0byB0aGUgcHJldmlvdXMgaG9wLg0KU1JEPiBPbiB0aGUgc2VydmljZSwgdGhp cyBsb29rcyBsaWtlIHRoZSBwcm9jZXNzaW5nIHRoYXQgc2hvdWxkIGFwcGx5IHRvIA0KYWxsIHJl YWxtLXJvdXRlZCByZXF1ZXN0cywgaW5kZXBlbmRlbnQgb2YgdGhlIHByZXNlbmNlIG9yIGFic2Vu Y2Ugb2YgDQpPQy1TLUYgaW4gdGhlIHJlcXVlc3QuDQpbV2llaGUsIFVscmljaCAoTlNOIC0gREUv TXVuaWNoKV0gbm8uIElmIG5vIE9DLVMtRiBBVlAgaXMgaW4gdGhlIHJlcXVlc3QgdGhlbiB0aGUg cmVxdWVzdCBtYXkgYmUgc3ViamVjdCB0byB0aHJvdHRsaW5nIGF0IHRoZSBhZ2VudC4NCj4NCj4g RikgV2hlbiBhbiBhZ2VudCB0aGF0IGlzIGNvbmZpZ3VyZWQgdG8gcGVyZm9ybSBzZXJ2ZXIgc2Vs ZWN0aW9uIGZvciByZWFsbS1yb3V0ZWQgcmVxdWVzdHMgcmVjZWl2ZXMgYSByZWFsbS1yb3V0ZWQg cmVxdWVzdCB0aGF0IGRvZXMgbm90IGNvbnRhaW4gYW4gT0MtUy1GIEFWUCwgbG9naWNhbGx5IGEg Y29tYmluYXRpb24gb2YgY2FzZSBEKSBmb2xsb3dlZCBieSBjYXNlIEUpIGlzIHBlcmZvcm1lZC4N ClNSRD4gTWludXMgRCkuDQpbV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKV0gbm8uDQo+ DQo+IDguIGNsYXVzZSAzLiBEaWFtZXRlciBSb3V0aW5nLCAzcmQgcGFyYWdyYXBoOg0KPiBTaG91 bGQgcmVhZDogIkluIGdlbmVyYWwsIHRocm90dGxpbmcgKFNlY3Rpb24gNCkgaXMgdGhlIG9ubHkg bG9jYWwgYWJhdGVtZW50IHRlY2huaXF1ZSB0aGF0IHdvcmtzIGZvciBob3N0LXJvdXRlZCByZXF1 ZXN0cy4gRGl2ZXJzaW9uIChTZWN0aW9uIDQpIGlzIHR5cGljYWxseSBub3QgcG9zc2libGUsIHNp bmNlIG9ubHkgYSBzaW5nbGUgVFMgY2FuIGhhbmRsZSBhbnkgZ2l2ZW4gaG9zdC1yb3V0ZWQgcmVx dWVzdC4iDQpTUkQ+IE9rLg0KPg0KPiA5LiBjbGF1c2UgMy4gRGlhbWV0ZXIgUm91dGluZywgbGFz dCBzZW50ZW5jZToNCj4gU2hvdWxkIHJlYWQ6ICJTaW5jZSByZWFsbS1yb3V0ZWQgcmVxdWVzdHMg YXJlIG5vdCBib3VuZCB0byBhIHBhcnRpY3VsYXIgVFMsIGl0IGlzIG9mdGVuIHBvc3NpYmxlIGZv ciB0aGUgbm9kZSB0aGF0IHNlbGVjdHMgdGhlIHNlcnZlciB0byBkaXZlcnQgYSBudW1iZXIgb2Yg dGhlbSB0byBvdGhlciBzZXJ2ZXJzIHRoYXQgYXJlIGxlc3Mgb3ZlcmxvYWRlZC4iDQpTUkQ+IE9r Lg0KPg0KPiAxMC4gY2xhdXNlIDQuIE92ZXJsb2FkIEFiYXRlbWVudCBNZXRob2RzLCA0dGggd29y ZDoNCj4gU2hvdWxkIHJlYWQgInNlcnZlciIuIEFnZW50IG92ZXJsb2FkIGlzIG91dCBvZiBzY29w ZS4NClNSRD4gSSBhZ3JlZSB3aXRoIEJlbidzIHJlc3BvbnNlIGhlcmUuICBBZ2VudCBvdmVybG9h ZCBuZWVkcyB0byBiZSANCmFkZHJlc3NlZCBhbmQgd2UgbmVlZCB0byBtYWtlIHN1cmUgdGhhdCB0 aGUgYmFzZSBET0lDIHNwZWMgZG9lc24ndCBtYWtlIA0KaXQgaW1wb3NzaWJsZSB0byBhZGQgaXQg aW4gdGhlIGZ1dHVyZS4NCj4NCj4gMTEuIGNsYXVzZSA0LiBPdmVybG9hZCBBYmF0ZW1lbnQgTWV0 aG9kLCA3dGggcGFyYWdyYXBoOg0KPiBEaXZlcnNpb24gKHdoaWNoIGlzIGxpbWl0ZWQgdG8gcmVh bG0tcm91dGVkIHJlcXVlc3RzKSBjYW4gb25seSBvY2N1ciBhdCB0aGUgRGlhbWV0ZXIgTm9kZSB0 aGF0IHBlcmZvcm1zIHRoZSBzZXJ2ZXIgc2VsZWN0aW9uLiBUb3BvbG9neSBrbm93bGVkZ2UgaXMg bm90IG5lZWRlZC4gT3ZlcmxvYWQgc3RhdGUga25vd2xlZGdlIGFjdHVhbGx5IGlzIHB1c2hlZCBm dXJ0aGVyIGRvd24gdGhlIGNoYWluLiBUaGUgbm9kZSBjYW4gY29udHJvbCBob3cgdGhlIHJlY2Vp dmVkIHJlYWxtLXJvdXRlZCByZXF1ZXN0IGlzIHJvdXRlZCB1cHN0cmVhbSBieSBpbnNlcnRpbmcg YSBEZXN0aW5hdGlvbi1Ib3N0IEFWUC4NClNSRD4gSSBoYXZlIG5vdGhpbmcgdG8gYWRkIHRvIEJl bidzIHJlc3BvbnNlLg0KW1dpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCldIHNlZSBteSBy ZXNwb25zZSB0byBCZW4gKGFjdHVhbGx5IHRoZXJlIHdhcyBhIHR5cG8gaW4gbXkgcmVzcG9uc2Ug LSBzaG91bGQgcmVhZCAiLi4uYnV0IGlzIG5vdCBhd2FyZSBvZiAuLi4iKQ0KDQo+DQo+IDEyLiBj bGF1c2UgNC4gT3ZlcmxvYWQgQWJhdGVtZW50IE1ldGhvZHMsIGxhc3QgcGFyYWdyYXBoOg0KPiAi bGVhc2UiIHNob3VsZCByZWFkICJsZWFzdCINCj4NCj4gMTMuIGNsYXVzZSA1LiBET0lDIFVzZSBD YXNlczoNCj4gSSBoYXZlIGxvdHMgb2YgZGV0YWlsZWQgY29tbWVudHMgd2hpY2ggSSBjYW4gc2hh cmUgaW4gYSBzZXBhcmF0ZSBtYWlsLiBUaGUgZXNzZW5jZSBpcyB0aGF0IGFsbCB0aGUgdXNlIGNh c2VzIGRlc2NyaWJlZCBzaG91bGQgZm9sbG93IHRoZSBnZW5lcmFsIHByaW5jaXBsZXMgQSB0byBG IG91dGxpbmVkIGFib3ZlLiBJdCBtYXkgYmUgd29ydGggdG8gdG90YWxseSByZXdyaXRlIHRoaXMg Y2xhdXNlIHRvIGlsbHVzdHJhdGUgdGhlIGdlbmVyYWwgcHJpbmNpcGxlcyBBIHRvIEYuDQpTUkQ+ IEkgZG9uJ3QgYWdyZWUgd2l0aCB0aGUgZ2VuZXJhbCBwcmluY2lwbGVzIEEgdG8gRiBzbyBJIGRv bid0IGFncmVlIA0Kd2l0aCB0aGlzIHNlY3Rpb24uICBJIGFsc28gYWdyZWUgd2l0aCBCZW4ncyBy ZXNwb25zZS4gIFRoZSB1c2UgY2FzZXMgDQpwcmVzZW50ZWQgYXJlIGFsbCByZWFzb25hYmxlIGFu ZCB0aGUgcHJvdG9jb2wgbmVlZHMgdG8gc3VwcG9ydCB0aGVtLiAgV2UgDQpzaG91bGQgbm90IGJl IGNvbnN0cmFpbmluZyBob3cgRGlhbWV0ZXIgaXMgdXNlZCBieSBsaW1pdGluZyB0aGUgDQpyZWFz b25hYmxlIGRlcGxveW1lbnQgc2NlbmFyaW9zLg0KW1dpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011 bmljaCldIHNlZSBteSByZXNwb25zZSB0byBCZW4uDQo+DQo+IDE0LiBjbGF1c2UgNi4xLiBHZW5l cmFsIFJlY29tbWVuZGF0aW9uLCBsYXN0IHBhcmFncmFwaDoNCj4gVGhpcyBpcyBub3Qgc3RyaWN0 bHkgcmVxdWlyZWQuIE11bHRpcGxlIG9jY3VycmVuY2VzIG9mIE9DLU9MUiBjb3VsZCBiZSByZWdh cmRlZCBhbiBhbiBvcHRpbWl6YXRpb24uIEJ1dCB0aGVuIHRoZXJlIGFyZSBpc3N1ZXM6IHdoZW4g dGhlcmUgYXJlIHR3byBPTFJzIGluIG9uZSBhbnN3ZXIsIGUuZy4gb25lIHJlYWxtLXR5cGUgT0xS IGZvciBsb3NzIGFuZCBvbmUgaG9zdC10eXBlIE9MUiBmb3IgcmF0ZSwgd2Ugd291bGQgYWxzbyBu ZWVkIHR3byBPQy1TLUYgQVZQczogb25lIGluZGljYXRpbmcgdGhhdCBsb3NzIGlzIHNlbGVjdGVk LCBhbmQgb25lIGluZGljYXRpbmcgdGhhdCByYXRlIGlzIHNlbGVjdGVkLiBCdXQgdGhpcyBzZWVt cyB0byBiZSBjb250cmFkaWN0aW5nIGluZm9ybWF0aW9uLg0KU1JEPiBJIGFncmVlIHRoYXQgdGhl cmUgaXMgYSBjb25zdHJhaW50IGluIHRoZSBjdXJyZW50IERPSUMgc3BlYyB0aGF0IA0Kd291bGQg Zm9yY2UgYWxsIG92ZXJsb2FkIHJlcG9ydHMgdG8gYXBwbHkgdG8gdGhlIHNhbWUgYWxnb3JpdGht LiAgV2UgDQpuZWVkIHRvIG1ha2Ugc3VyZSB0aGlzIGlzIGEgcmVhc29uYWJsZSBjb25zdHJhaW50 LiAgSSBkbyBub3QgYWdyZWUgdGhhdCANCndlIGNhbiBhc3N1bWUgYSBzaW5nbGUgb3ZlcmxvYWQg cmVwb3J0IGluIGFuIGFuc3dlciBtZXNzYWdlIGFuZCB0aGUgdXNlIA0KY2FzZXMgcHJlc2VudGVk IGNsZWFybHkgc2hvdyB0aGlzIHRvIGJlIHRoZSBjYXNlLg0KPg0KPiAxNS4gY2xhdXNlIDYuMi4x IENhcGFiaWxpdGllcyBFeGNoYW5nZSBCZWhhdmlvdXJzLCAzcmQgcGFyYWdyYXBoOg0KPiBTaG91 bGQgcmVhZDogIkFuIGFnZW50IG1heSBhY3QgYXMgYSByZXBvcnRpbmcgbm9kZSBvbiBiZWhhbGYg b2YgYSBub24tc3VwcG9ydGluZyBUUywgb3IgYXMgcmVhY3Rpbmcgbm9kZSBvbiBiZWhhbGYgb2Yg YSBub24tc3VwcG9ydGluZyBUQy5bU2VjdGlvbiA1LjNdIi4gSSdtIG5vdCBzdXJlIHdoZXRoZXIg d2Ugc2hvdWxkIGNvdmVyIHRoZSBmaXJzdCBjYXNlLiBBdCBsZWFzdCBpdCBzaG91bGQgYmUgbGlt aXRlZCB0byBhcmNoaXRlY3R1cmVzIHdoZXJlIHRoZSBhZ2VudCAoYWN0aW5nIGFzIHJlcG9ydGlu ZyBub2RlIG9uIGJlaGFsZiBvZiB0aGUgbm9uIHN1cHBvcnRpbmcgc2VydmVyKSBhbmQgdGhlIChu b24gc3VwcG9ydGluZykgc2VydmVyIGFyZSBpbW1lZGlhdGUgcGVlcnMgYW5kIHRoZSBzZXJ2ZXIg aGFzIG5vIG90aGVyIGltbWVkaWF0ZSBwZWVycywgc28gdGhhdCB0aGUgdHdvIG5vZGVzIGNhbiBi ZSByZWdhcmRlZCBhIHNpbmdsZSBzdXBwb3J0aW5nIHNlcnZlci4NClNSRD4gSSBkb24ndCBzZWUg dGhlIG5lZWQgZm9yIHN1Y2ggYSBsaW1pdGF0aW9uLiAgSW4gdGhlIGVuZCwgaXQgc2hvdWxkIA0K YmUgdXAgdG8gdGhlIG9wZXJhdG9yIG9mIHRoZSBEaWFtZXRlciBuZXR3b3JrIHRvIGRldGVybWlu ZSBob3cgdG8gbWFuYWdlIA0Kb3ZlcmxvYWQgd2hpY2ggaW5jbHVkZXMgd2hpY2ggb2YgdGhvc2Ug bm9kZXMgYXJlIHJlcG9ydGluZyBub2RlcyBhbmQgDQp3aGljaCBvZiB0aG9zZSBub2RlcyBhcmUg cmVhY3Rpbmcgbm9kZXMuDQpbV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKV0gd2UgYXJl IHJ1bm5pbmcgaW50byBwcm9ibGVtcyB3aGVuIHRoaXMgbGltaXRhdGlvbiBpcyBub3QgaW4gcGxh Y2UuIFRoZXNlIHByb2JsZW1zIHNob3VsZCBiZSBhdm9pZGVkIChieSB0aGUgbGltaXRhdGlvbikg b3Igc2hvdWxkIGJlIHNvbHZlZCBpbiB0aGUgZHJhZnQgKGN1cnJlbnRseSB0aGV5IGFyZSBub3Qp OyANCj4NCj4gMTYuIGNsYXVzZSA2LjIuMSBDYXBhYmlsaXRpZXMgRXhjaGFuZ2UgQmVoYXZpb3Vy cywgNHRoIHBhcmFncmFwaDoNCj4gVG8gYWRkIHNvbWUgY2xhcmlmaWNhdGlvcyB0aGlzIHNob3Vs ZCByZWFkOg0KPiAiQW4gYWdlbnQgdGhhdCBhY3RzIGFzIGEgcmVhY3Rpbmcgbm9kZSBtdXN0IGlu Y2x1ZGUgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmVzIGluIGVhY2ggRGlhbWV0ZXIgcmVxdWVzdCB0 aGF0IGl0IGZvcndhcmRzIGluIHRoYXQgcm9sZS4gSWYgdGhlIGluYm91bmQgcmVxdWVzdCBpbmNs dWRlZCBhbiBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQLCB0aGUgYWdlbnQgbWF5IGNvcHkgaXRz IGNvbnRlbnQgdG8gdGhlIG9uZSBpbiB0aGUgb3V0Ym91bmQgcmVxdWVzdCAodGhpcyBpcyB0aGUg Y2FzZSB3aGVyZSB0aGUgcmVxdWVzdCBpcyBhKSBob3N0LXJvdXRlZCBvciBiKSByZWFsbS1yb3V0 ZWQgYW5kIHRoZSBhZ2VudCBpcyBub3QgY29uZmlndXJlZCB0byBwZXJmb3JtIHNlcnZlciBzZWxl Y3Rpb24pLCBvciBtYXkgcmVwbGFjZSB0aGUgY29udGVudHMgaW5kaWNhdGluZyB0aGUgRE9JQyBj YXBhYmlsaXRpZXMgb2YgdGhlIGFnZW50IGl0c2VsZiAodGhpcyBpcyB0aGUgY2FzZSB3aGVyZSB0 aGUgcmVxdWVzdCBpcyByZWFsbSByb3V0ZWQgYW5kIHRoZSBhZ2VudCBpcyBjb25maWd1cmVkIHRv IHBlcmZvcm0gc2VydmVyIHNlbGVjdGlvbikuIElmIGFuIGluYm91bmQgcmVxdWVzdCBkb2VzIG5v dCBjb250YWluIGFuIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBBVlAsIHRoZSBhZ2VudCBtdXN0IGlu c2VydCBvbmUgaW50byB0aGUgb3V0Ym91bmQgcmVxdWVzdCwgaW5kaWNhdGluZyB0aGUgRE9JQyBj YXBhYmlsaXRpZXMgb2YgdGhlIGFnZW50IGl0c2VsZi4iDQpTUkQ+IEkgYWdyZWUgd2l0aCBCZW4n cyByZXNwb25zZS4NCltXaWVoZSwgVWxyaWNoIChOU04gLSBERS9NdW5pY2gpXSBzZWUgbXkgcmVz cG9uc2UgdG8gQmVuICh0eXBvcyBhZ2Fpbiwgc29ycnksIHNob3VsZCByZWFkOiAiSXRzIHRoZSBv dGhlciB3YXkgcm91bmQ6IEFuIGFnZW50IHRoYXQgc2VsZWN0cyB0aGUgc2VydmVyIGNoYW5nZXMg dGhlIHR5cGUgb2YgcmVwb3J0IC4uLiAiDQo+DQo+IDE3LiBjbGF1c2UgNi4yLjEgQ2FwYWJpbGl0 aWVzIEV4Y2hhbmdlIEJlaGF2aW91cnMsIGxhc3QgcGFyYWdyYXBoOg0KPiBTaG91bGQgcmVhZDog IkFuIGFnZW50IHRoYXQgZG9lcyBub3Qgc3VwcG9ydCB0aGUgRE9JQyBtZWNoYW5pc20gaXMgbGlr ZWx5IHRvIGZvcndhcmQgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFWUCB3aXRob3V0IG1vZGlm aWNhdGlvbi4gQSBET0lDIG5vZGUgbXVzdCBiZSBhYmxlIHRvIHRlbGwgYmV0d2VlbiBhbiBPQy1T dXBwb3J0ZWQtRmVhdHVyZXMgQVZQIHRoYXQgd2FzIGluc2VydGVkIGJ5IGEgbm9kZSB3aXRoaW4g YSB0cnVzdGVkIGRvbWFpbiwgYW5kIG9uZSBpbnNlcnRlZCBieSBhIG5vZGUgd2l0aGluIGEgbm9u LXRydXN0ZWQgZG9tYWluLltTZWN0aW9uIDUuNF0iLiBUaGlzIGlzIGJlY2F1c2UgdGhlIHJlcG9y dGluZyBub2RlIChpZiBpdCBzZW5kcyBhbiBPTFIgd2l0aGluIGFuIGFuc3dlcikgc2VuZHMgaXQn cyBPTFIgdG8gdGhlIG5vZGUgdGhhdCBoYXMgaW5zZXJ0ZWQgdGhlIE9DLVMtRiBBVlAgdG8gdGhl IHJlcXVlc3QuDQo+DQo+IDE4LiBjbGF1c2UgNi4yLjIgT3ZlcmxvYWQgUmVwb3J0IEJlaGF2aW91 cnMsIDFzdCBzZW50ZW5jZSwgdGhlIHBhcnQgaW4gYnJhY2tldHM6DQo+IEkgZG8gbm90IGFncmVl OyB3aGVuIHBhc3NpbmcgdGhyb3VnaCwgdGhlIHJlc3BvbnNpYmlsaXR5IGlzIGF0IHRoZSBzb3Vy Y2UsIG5vdCBhdCB0aGUgcmVsYXkuIFRoZSBzZW50ZW5jZSBzaG91bGQgcmVhZDogIldoZW4gYSBE T0lDLXN1cHBvcnRpbmcgcmVsYXkgaW5zZXJ0cyBvciByZXBsYWNlcyBhbiBPQy1TdXBwb3J0ZWQt RmVhdHVyZXMgQVZQLCBpdCBiZWNvbWVzIHJlc3BvbnNpYmxlIGZvciBlbnN1cmluZyB0aGF0IGFu eSBPTFJzIGl0IHJlY2VpdmVzIGZyb20gdXBzdHJlYW0gbm9kZXMgYXJlIGhvbm9yZWQuIg0KPg0K PiAxOS4gY2xhdXNlIDYuMi4yIE92ZXJsb2FkIFJlcG9ydCBCZWhhdmlvdXJzLCAybmQgc2VudGVu Y2U6DQo+IElmIHRoZSBhYmF0ZW1lbnQgaXMgbm90ICJEaXZlcnNpb24iIGFuZCAiRGVsZWdhdGlv biIgaXMgcG9zc2libGUsICJEZWxlZ2F0aW9uIiByYXRoZXIgdGhhbiAiVGhyb3R0bGluZyIgbXVz dCBiZSBkb25lLg0KPg0KPiAyMC4gY2xhdXNlIDYuMi4yIE92ZXJsb2FkIFJlcG9ydCBCZWhhdmlv dXJzLCAybmQgcGFyYWdyYXBoLCBsYXN0IHNlbnRlbmNlOg0KPiBJIGRvIG5vdCBhZ3JlZS4gU2Vl IGFsc28gY29tbWVudCAxMS4gRGl2ZXJzaW9uIGlzIGxpbWl0ZWQgdG8gcmVhbG0tcm91dGVkIHJl cXVlc3RzIGFuZCBjYW4gb25seSBiZSBwZXJmb3JtZWQgYnkgbm9kZXMgdGhhdCBkbyB0aGUgc2Vy dmVyIHNlbGVjdGlvbi4gVGhlc2Ugbm9kZXMgY2FuIGNvbnZlcnQgdGhlIHJlYWxtLXJvdXRlZCBy ZXF1ZXN0IHRvIGEgaG9zdC1yb3V0ZWQgcmVxdWVzdC4NCj4NCj4gMjEuIGNsYXVzZSA2LjIuMiBP dmVybG9hZCBSZXBvcnQgQmVoYXZpb3VycywgM3JkIHBhcmFncmFwaCwgbGFzdCBzZW50ZW5jZToN Cj4gTW9kaWZ5aW5nIE9MUnMgbXVzdCBmb2xsb3cgc3RyaWN0IHJ1bGVzLiBXZSBlaXRoZXIgaGF2 ZQ0KPiBhKSBvbmUgRE9JQyBhc3NvY2lhdGlvbiBiZXR3ZWUgcmVhY3Rpbmcgbm9kZSBhbmQgcmVw b3J0aW5nIG5vZGUgd2hlcmUgYWxsIGFnZW50cyBpbiBiZXR3ZWVuIGFyZSB0cmFuc3BhcmVudCBh bmQgZG8gbm90IG1vZGlmeSBPQy14eHggQVZQcywgb3INCj4gYikgdHdvIGluZGVwZW5kZW50IERP SUMgYXNzb2NpYXRpb25zLCBvbmUgYmV0d2VlbiByZWFjdGluZyBub2RlIGFuZCBhZ2VudCAoYWN0 aW5nIGFzIHJlcG9ydGluZyBub2RlKSBhbmQgb25lIGJldHdlZW4gdGhlIHNhbWUgYWdlbnQgKG5v dyBhY3RpbmcgYXMgcmVhY3Rpbmcgbm9kZSkgYW5kIHJlcG9ydGluZyBub2RlLiBIZXJlIHRoZSBh Z2VudCByZW1vdmVzIHRoZSByZWNlaXZlZCBob3N0LXR5cGUgT0xSIGFuZCBpbnNlcnRzIGl0cyBv d24gYWdncmVnYXRlZCByZWFsbS10eXBlIE9MUi4gSSB3b3VsZCBub3QgY2FsbCB0aGlzIGEgbW9k aWZpY2F0aW9uIGJ1dCBhIHJlcGxhY2VtZW50LiBNb2RpZmljYXRpb25zIG90aGVyIHRoYW4gdGhp cyBtYXkgbm90IGJlIGEgZ29vZCBpZGVhLg0KPg0KPiAyMi4gY2xhdXNlIDYuMi4yIE92ZXJsb2Fk IFJlcG9ydCBCZWhhdmlvdXJzLCBsYXN0IGJ1dCBvbmUgcGFyYWdyYXBoOg0KPiBJdCBpcyB0aGUg b3RoZXIgd2F5IHJvdW5kOg0KPiBBbiBhZ2VudCBzaGFsbCBub3QgdGhyb3R0bGUgdHJhZmZpYyBs b2NhbGx5IHdoZW4gaXQgaGFzIGFscmVhZHkgc2VudCAob3Igd2lsbCBzb29uIHNlbmQpIGFuIE9M UiBkb3duc3RyZWFtIChpLmUuIHdoZW4gaXQgY2FuIG9yIGFscmVhZHkgaGFzIGRlbGVnYXRlZCB0 aGUgYWJhdGVtZW50KS4gV2hlbiByZWNlaXZpbmcgYSB4eFIgdGhhdCBjb250YWlucyBhbiBPQy1T LUYgQVZQIChhbmQgdGhlIHh4UiBtYXRjaGVzIGFuIE9MUikgdGhlIGFnZW50IGNhbiBhbG1vc3Qg c2FmZWx5IGFzc3VtZSB0aGF0IHRoaXMgcmVxdWVzdCBzdXJ2aXZlZCBhbiBvbmdvaW5nIHRocm90 dGxpbmcgZG93bnN0cmVhbS4gVGhlIHByaW5jaXBsZSBpcyB0aGF0IHRocm90dGxpbmcgc2hvdWxk IGJlIGRvbmUgYXMgY2xvc2UgYXMgcG9zc2libGUgdG8gdGhlIGNsaWVudC4NClNSRD4gSSBoYXZl IG5vdGhpbmcgdG8gYWRkIHRvIEJlbidzIGNvbW1lbnRzIG9uIHRoZSBhYm92ZSB3aXRoIHRoZSAN CmV4Y2VwdGlvbiB0aGF0IEkgYWxzbyBzZWUgbGl0dGxlIHZhbHVlIHRvIGNhcnJ5aW5nIHRoZSBj b25jZXB0IG9mIGEgRE9JQyANCkVuZHBvaW50IGZvcndhcmQuICBNdWx0aXBsZSBEaWFtZXRlciBu b2RlcyBhbmQgYW5kIHdpbGwgbmVlZCB0byBwZXJmb3JtIA0KYWJhdGVtZW50IG9uIGEgc2luZ2xl IG92ZXJsb2FkIHJlcG9ydC4gIEl0IHdvbid0IG9ubHkgYmUgYW4gZW5kcG9pbnQgYXMgDQpwcmV2 aW91c2x5IGNvbmNlaXZlZCB0aGF0IGRvZXMgc28uDQpbV2llaGUsIFVscmljaCAoTlNOIC0gREUv TXVuaWNoKV0gDQpUaGUgY29uY2VwdCBvZiBET0lDIEVuZHBvaW50cyBhbmQgRE9JQyBhc3NvY2lh dGlvbiBiZXR3ZWVuIGVuZHBvaW50cyBpcyBmdW5kYW1lbnRhbCBhbmQgSSB0aGluayB3YXMgYWdy ZWVkIGJ5IHRoZSBncm91cC4gSXQgd2FzIHRoZSBiYXNpcyBmb3Igc2VsZWN0aW5nIHRoZSBwcmlu Y2lwbGUgb2YgZW5kIHRvIGVuZCBwaWdneWJhY2tpbmcgT0MteHh4IEFWUHMgb24gYXBwbGljYXRp b24gbWVzc2FnZXMuIEl0IHNlZW1zIHRoYXQgeW91IGFyZSBub3cgZ29pbmcgYmFjayB0byB0aGUg aG9wLWJ5LWhvcCBhcHByb2NoIG9mIHRoZSByb2FjaCBkcmFmdC4NCj4NCj4gUmVnYXJkcywNCj4g VWxyaWNoDQo+DQo+DQo+IEZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBleHQgU3RldmUgRG9ub3Zhbg0KPiBTZW50OiBTYXR1cmRheSwgSnVseSAw NSwgMjAxNCA5OjQ5IFBNDQo+IFRvOiBkaW1lQGlldGYub3JnDQo+IFN1YmplY3Q6IFtEaW1lXSBG d2Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZG9ub3Zhbi1kb2ljLWFnZW50 LWNhc2VzLTAwLnR4dA0KPg0KPiBBbGwsDQo+DQo+IFRoZSBiZWxvdyByZWZlcmVuY2VkIGRyYWZ0 IGZvY3VzZXMgb24gYSBudW1iZXIgb2YgRE9JQyBkZXBsb3ltZW50IHNjZW5hcmlvcyBpbnZvbHZp bmcgYWdlbnRzLiAgVGhlIGdvYWwgb2YgdGhpcyBkcmFmdCBpcyB0byBpZGVudGlmeSBhbnkgbmV3 IERPSUMgYmVoYXZpb3JzIHJlcXVpcmVkIHRvIGFkZHJlc3MgdGhlc2UgZGVwbG95bWVudCBzY2Vu YXJpb3MuDQo+DQo+IFRoaXMgZGlyZWN0bHkgYWRkcmVzc2VzIG9wZW4gaXNzdWVzICMyNSwgIzI3 LCAjNjAgYW5kICM2MSB3aGlsZSBpbmRpcmVjdGx5IGFkZHJlc3Npbmcgb3RoZXIgb3BlbiBpc3N1 ZXMuDQo+DQo+IFJlZ2FyZHMsDQo+DQo+IFN0ZXZlDQo+DQo+IC0tLS0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0tLS0NCj4gU3ViamVjdDoNCj4gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1kb25vdmFuLWRvaWMtYWdlbnQtY2FzZXMtMDAudHh0DQo+IERhdGU6DQo+IFRodSwg MDMgSnVsIDIwMTQgMDk6MTc6MTEgLTA3MDANCj4gRnJvbToNCj4gaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnDQo+IFRvOg0KPiBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbT4sICJTdGV2ZSBE b25vdmFuIiA8c3Jkb25vdmFuQHVzZG9ub3ZhbnMuY29tPiwgU3RldmUgRG9ub3ZhbiA8c3Jkb25v dmFuQHVzZG9ub3ZhbnMuY29tPiwgIkJlbiBDYW1wYmVsbCIgPGJlbkBub3N0cnVtLmNvbT4NCj4N Cj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWRvbm92YW4tZG9pYy1hZ2VudC1jYXNlcy0w MC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTdGV2ZSBEb25vdmFu IGFuZCBwb3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4NCj4gTmFtZToJCWRyYWZ0 LWRvbm92YW4tZG9pYy1hZ2VudC1jYXNlcw0KPiBSZXZpc2lvbjoJMDANCj4gVGl0bGU6CQlBbmFs eXNpcyBvZiBBZ2VudCBVc2UgQ2FzZXMgZm9yIERpYW1ldGVyIE92ZXJsb2FkIEluZm9ybWF0aW9u IENvbnZleWFuY2UgKERPSUMpDQo+IERvY3VtZW50IGRhdGU6CTIwMTQtMDctMDMNCj4gR3JvdXA6 CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6CQkzNA0KPiBVUkw6ICAgICAgICAgICAg aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZG9ub3Zhbi1kb2ljLWFn ZW50LWNhc2VzLTAwLnR4dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtZG9ub3Zhbi1kb2ljLWFnZW50LWNhc2VzLw0KPiBIdG1saXplZDog ICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZG9ub3Zhbi1kb2ljLWFnZW50 LWNhc2VzLTAwDQo+DQo+DQo+IEFic3RyYWN0Og0KPiAgICAgVGhlIERpYW1ldGVyIE92ZXJsb2Fk IEluZm9ybWF0aW9uIENvbnZleWFuY2UgKERPSUMpIHNvbHV0aW9uDQo+ICAgICBkZXNjcmliZXMg YSBtZWNoYW5pc20gZm9yIGV4Y2hhbmdpbmcgaW5mb3JtYXRpb24gYWJvdXQgRGlhbWV0ZXINCj4g ICAgIE92ZXJsb2FkIGFtb25nIERpYW1ldGVyIG5vZGVzLiAgQSBET0lDIG5vZGUgaXMgYSBEaWFt ZXRlciBub2RlIHRoYXQNCj4gICAgIGFjdHMgYXMgZWl0aGVyIGEgcmVwb3J0aW5nIG5vZGUgYXJl IGEgcmVhY3Rpbmcgbm9kZS4gIEEgcmVwb3J0aW5nDQo+ICAgICBub2RlIG9yaWdpbmF0ZXMgb3Zl cmxvYWQgcmVwb3J0cywgcmVxdWVzdGluZyByZWFjdGluZyBub2RlcyB0byByZWR1Y2UNCj4gICAg IHRoZSBhbW91bnQgb2YgdHJhZmZpYyBzZW50LiAgRE9JQyBhbGxvd3MgRGlhbWV0ZXIgYWdlbnRz IHRvIGFjdCBhcw0KPiAgICAgcmVwb3J0aW5nIG5vZGVzLCByZWFjdGluZyBub2Rlcywgb3IgYm90 aCwgYnV0IGRvZXMgbm90IGRlc2NyaWJlIGFnZW50DQo+ICAgICBiZWhhdmlvci4gIFRoaXMgZG9j dW1lbnQgZXhwbG9yZXMgc2V2ZXJhbCB1c2UgY2FzZXMgZm9yIGFnZW50cyB0bw0KPiAgICAgcGFy dGljaXBhdGUgaW4gb3ZlcmxvYWQgY29udHJvbCwgYW5kIG1ha2VzIHJlY29tbWVuZGF0aW9ucyBm b3INCj4gICAgIGNlcnRhaW4gYWdlbnQgYmVoYXZpb3JzIHRvIGJlIGFkZGVkIHRvIERPSUMuDQo+ DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQo+DQo+DQo+IFBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCj4NCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4NCj4NCj4NCj4N Cg0KDQo= From nobody Sat Jul 19 00:29:56 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696C51A0331 for ; Sat, 19 Jul 2014 00:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 3LUMKX1QRE6w for ; Sat, 19 Jul 2014 00:29:45 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61001B27BE for ; Sat, 19 Jul 2014 00:29:44 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s6J7TgnJ026623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 19 Jul 2014 07:29:42 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s6J7Tg41021185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 19 Jul 2014 09:29:42 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.93]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0181.006; Sat, 19 Jul 2014 09:29:41 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt Thread-Index: AQHPlvVsB56hVVSy3UODi6hlfxzXKpuRwvIAgA42/kCAAR7CAIAFNWbQ Date: Sat, 19 Jul 2014 07:29:40 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> In-Reply-To: <53C53234.9090007@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.122] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 14223 X-purgate-ID: 151667::1405754982-000005B1-2511CF6D/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ERee5VGJnHJebPIpTuR4yM_9Ass Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 07:29:49 -0000 Steve, please see my response inline. Regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Tuesday, July 15, 2014 3:53 PM To: dime@ietf.org Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt Ulrich, Thanks for the comments. Please see my responses inline. Regards, Steve On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Hi Steve, > here are my comments. > They focus on new text you introduced. I agree that restructuring may req= uire new text, however, I believe that with the new text a new concepts is = introduced which macerates the agreed end-to-end concept and allows all DOI= C agents on the path to do what they wants, so that we end up in a hop-by-h= op concept. SRD> We have never had an agreement on end-to-end versus hop-by-hop and=20 I believe that we will end up with a hybrid of the two. We have open=20 issues on agent behavior that Ben and I are attempting to address with=20 the agent cases draft. [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop approach of= the roach draft was reason not to proceed with that draft. SRD> That said, this type of restructuring of the document is likely to=20 put agreed to behavior in a new light. If there are cases where I have=20 implied changes to agreed to normative behavior, or if the informative=20 text is not accurate, then these things need to be corrected. > > 1. clause 2.3, second paragraph: > Should read: "Reacting nodes indicate support for DOIC by including the O= C-Supported-Features AVP into all request messages originated or relayed by= the Reacting node." SRD> You mean clause 3.2. [Wiehe, Ulrich (NSN - DE/Munich)] yes I agree with the change. > > 2. clause 2.3, 3rd paragraph, 1st sentence: > OC-xxx AVPs must not be included in an answer message when the correspond= ing request did not contain an OC-S-F AVP. SRD> Agreed. > > 3. clause 3.3, 7th paragraph: > Should read "The reporting node only includes an indication of support fo= r one overload abatement algorithm. This is the algorithm that the reporti= ng node intends to use should it enter an overload condition or requests to= use while it actually is in an overload condition. Reacting nodes can use = the indicated overload abatement algorithm to prepare for possible overload= reports and must use the indicated overload abatement algorithm if traffic= reduction is actually requested." SRD. OK. > > 4. clause 3.3, 10th paragraph: > The 1st sentence is misleading. In the general case, agents on the path b= etween reacting node and reporting node are transparent. I agree that there= are exceptions to the general case where an agent on the path is not trans= parent, but then the agent IS the reporting node (reporting to the sender o= f the request) and it also IS the reacting node (reacting on reports receiv= ed from the upstream reporting node). > The first 3 words of the second sentence "in this case" need clarificatio= n: "In the case where an agent takes the role of a reporting node (reportin= g to the downstream reacting node) and at the same time takes the role of a= reacting node (reacting on reports received from an upstream reporting nod= e)". > Last sentence: Its not an update but a replacement. The two DOIC associat= ions are handled independently. SRD> I don't know what you mean when you say an agent is transparent. =20 Agents must take an active role in even the most basic case for overload=20 handling to work, so they cannot be transparent. [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not suppor= t DOIC are transparent. Agents that support DOIC in most cases behave like = non supporting agents. > > 5. clause 3.3, last paragraph: > General rules shall be followed for each of the two associations separate= ly. The content of the OC-S-F AVP sent by the agent upstream should reflect= what the agent is able and willing to support (as always). SRD> What two associations? Is there one association (end-to-end) or is=20 the an association on both sides of the agent (hop-by-hop)? Or is there=20 an association that involves three entities, the reporting node, an=20 agent reacting node for realm-routed requests and a transaction-client=20 reporting node for handling host-routed requests? [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, There is one association between C and A, and one association between A and= S. Both associations are "end-to-end" as there may be transparent (support= ing or non-supporting) agents in the middle.=20 > > 6. clause 3.4, 2nd paragraph: > Should read: "The OC-OLR AVP is referred to as an overload report. The O= C-OLR AVP includes the type of report, a sequence number, the length of tim= e that the report is valid and abatement algorithm specific AVPs." SRD> The sequence number is being used as an overload report ID. I can=20 make the change but I don't see it as necessary. [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. > > 7. clause 3.4, 4th paragraph, 2nd sentence: > I cannot understand this sentence. Probably only simple typos but I don't= know. SRD> Yes, a typo (this instead of the) and awkward wording. How about=20 "This applies to requests that contain the Destination-Host AVP with a=20 DiameterIdentity that matches the overload report. [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that contain a= DiameterIdentity in the Destination-Host AVP that matches the reporting ho= st's DiameterIdentity" > > 8. clause 3.4, 4th paragraph last 2 sentences: > I don't understand and probably do not agree. SRD> See above. > > 9. clause 3.5, 3rd paragraph, last word: > Should read "communicated" SRD> Agreed. > > 10. clause 3.5, 4th paragraph, 1st sentence: > I don't understand. I can understand: "Reporting nodes use the OC-OLR AVP= to communicate overload occurances towards reacting nodes." SRD> Who else would reports be sent to? [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement algorithm = but the reporting node that uses the OC-OLR AVP to communicate overload occ= urances. > > 11. clause 4.1, 3rd paragraph, last 4 words: > may be misleading. A DOIC supporting agent sitting between DOIC supportin= g client and DOIC supporting Server is transparent with regard to DOIC. Thi= s agent does not indicate DOIC support. SRD> I disagree. [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Should be= : ...This agent does not indicate its DOIC support, rather it transparently= forwards the client's DOIC support. > > 12. clause 4.1, 4th paragraph, 2nd sentence: > Should read:"If a request message handled by the DOIC agent does not incl= ude the OC-Supported-Features AVP then the DOIC agent inserts the AVP." SRD> That is what it already says. [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... > > 13. clause 4.1, last sentence: > Should read "If the message already has the AVP then the agent either lea= ves it unchanged in the relayed message or replaces it to reflect the featu= res the agent is able and willing to support." Clarification is needed to s= ay that strict rules must be followed by the agent to select the correct op= tion. These rules take into account whether the request is host-routed or r= elam-routed and whether the agent is configured to select the server for re= alm-routed requests. SRD> This is a topic on agent behavior that is addressed in the agent=20 cases draft. I'll leave the discussion for what the wording should be=20 to the discussion on that draft. > > 14. clause 4.1.2, 2nd paragraph: > Should read: "Based on the content of the OC-Supported-Features AVP in th= e request message, the reporting node knows what overload control functiona= lity is supported by the reacting node. The reporting node then acts accor= dingly for the subsequent answer messages it initiates for the transaction.= " SRD> It would be easier if you didn't make it difficult to understand=20 the change you are proposing. I think you are proposing changing=20 node(s) to node. I don't agree but that will be addressed as part of=20 the agent cases discussion. [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing two sent= ences? The proposal is to insert "is" between "functionality" and "supporte= d", to add "the" between "by" and "reacting", to replace "node(s)" with "no= de", and to insert "for the transaction" after "initiates". =20 > =20 > 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: > Should read: "message's" SRD> I'm assuming you mean section 4.1.2. [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, and 19= . I agree to the change. > > 16. clause 4.1, 6th paragraph: > This should be left to the (future) specification that introduces other D= OIC features. > > 17. clause 4.1, 7th paragraph, last 6 words: > should be based on requiements set by the (future) specification that int= roduces other DOIC features SRD> Again, clause 4.1.2 -- I don't understand the issue when these two=20 paragraphs are taken together. > > 18. clause 4.1, 8th paragraph, last sentence: > Should read: "Lack of the OC-Supported-Features AVP in the request messag= e indicates that there is no downstream reacting node for the transaction." SRD> I think you mean clause 4.1.2. I don't see the need for the change. [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not correct.= It should either read: "Lack of the OC-Supported-Feature AVP in the reques= t message indicates to the reporting node that there is no reacting node fo= r the transaction" or as proposed above. > > 19. clause 4.1, last sentence: > Should read: "An agent MAY replace the OC-Supported-Features AVP carried = in answer messages." This replacement must follow general rules. Its not so= that the agent may do what ever it wants to. The decision must be based on= whether or not the agent has replaced the OC-S-F in the corresponding requ= est. SRD> What is the difference between modify and replace? I am ok with=20 removing this statement until we have the agent behavior discussion. I=20 thought I had taken the agent specific statements out of this version. [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with identical va= lues. You remove what has been received in and insert your own stuff. > > 20. clause 5.2, 1st sentence: > Should read: "A reporting node using the loss algorithm must use the OC-R= eduction-Percentage AVP (Section 6.7) to indicated the desired percentage o= f traffic reduction." SRD> Agreed. > > 21. clause 5.2, last sentence: > Should read: "Editor's note: The above duplicates what is in the OC-Reduc= tion-Percentage AVP section and can probably be removed." SRD> Yes, bad wording. The note will be removed, bad wording and all,=20 once there is a discussion on if this is redundant. > > 22. clause 5.4, 6th paragraph: > Should read: "If the reacting node does not receive a an OLR in the answe= r that corresponds to the probe request messages sent to the formally overl= oaded node then the reacting node should slowly increase the rate of traffi= c sent to the overloaded node." SRD Agreed, this is more clear. > > > Best regards > Ulrich > > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan > Sent: Saturday, July 05, 2014 9:42 PM > To: dime@ietf.org > Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt > > All, > > This version of the DOIC draft is a restructuring of previously agreed > to content. > > The master plan for the restructuring is in Appendix C. This outlines > where material from -02 was moved in -03. > > For those interested, the work was done in steps, with a snapshot for > each step available here: > > https://github.com/jounikor/draft-docdt-dime-ovli > > Each step has the name draft-ietf-dime-ovli-03-nn-text.txt > > where nn indicates the subversion and "text" indicates the focus for > that subversion. > > The next step will be to resolve open issues already identified and > those yet those yet to be identified. > > Regards, > > Steve > > > On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Diameter Maintenance and Extensions = Working Group of the IETF. >> >> Title : Diameter Overload Indication Conveyance >> Authors : Jouni Korhonen >> Steve Donovan >> Ben Campbell >> Lionel Morand >> Filename : draft-ietf-dime-ovli-03.txt >> Pages : 48 >> Date : 2014-07-03 >> >> Abstract: >> This specification documents a Diameter Overload Control (DOC) base >> solution and the dissemination of the overload report information. >> >> Requirements >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-ovli-03 >> >> >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Sat Jul 19 01:19:38 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C05F1B27D5 for ; Sat, 19 Jul 2014 01:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 vT2tnvFqtDSa for ; Sat, 19 Jul 2014 01:19:35 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC3B1B27F2 for ; Sat, 19 Jul 2014 01:19:29 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s6J8JRio021281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 19 Jul 2014 08:19:27 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s6J8JRdx004816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 19 Jul 2014 10:19:27 +0200 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sat, 19 Jul 2014 10:19:27 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.93]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0181.006; Sat, 19 Jul 2014 10:19:27 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] DOIC #54: OC-Report-Type as mandatory AVP Thread-Index: AQHPoPSxIgC83ZHZCE+YBFS0xo8a4ZunCeZg Date: Sat, 19 Jul 2014 08:19:26 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151FE382@DEMUMBX014.nsn-intra.net> References: <53C6754B.5020600@usdonovans.com> In-Reply-To: <53C6754B.5020600@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.122] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3015 X-purgate-ID: 151667::1405757967-00007A71-4936938F/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/hMFETZVSGVt1M_pfjvtE47keW_4 Subject: Re: [Dime] DOIC #54: OC-Report-Type as mandatory AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 08:19:37 -0000 Steve, please see inline. Regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Wednesday, July 16, 2014 2:51 PM To: dime@ietf.org Subject: [Dime] DOIC #54: OC-Report-Type as mandatory AVP All, Now that the restructure of the DOIC specification is complete [Wiehe, Ulrich (NSN - DE/Munich)] I don't think the restructuring is comple= te. I did send comments and identified issues which in my understanding ar= e not resolved yet. we need=20 to start resolving open issues. Those that entered the issues are=20 encouraged to work to get them closed. I'll start on #54 in this email. The question is whether the OC-Report-Type AVP is required any time that=20 an OC-OLR AVP is sent. The current version of the draft is the same as the -02 version, showing=20 the AVP as being required. This was based on an earlier attempt to=20 close the issue prior to -02 being published. Susan has stated that she does not think it should be required. If I=20 understand correctly this is based on the assumption that an HSS would=20 never send an OLR with report-type of any value but host. Susan, please correct me if I'm mistaken. I don't believe this is a correct assumption. It is reasonable for an=20 HSS to send an OLR with report-type of realm. [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree This might happen in a=20 non agent based deployment or in a deployment where the HSS (or more=20 generically, server) has knowledge of the status of all servers for the=20 application.[Wiehe, Ulrich (NSN - DE/Munich)] How would the HSS get that k= nowledge? It is the task of the node that selects the server to aggregate a= nd to convert received host-reports into a realm-report. If we want the ser= ver to do that we need to describe how overload information is exchanged fr= om one reporting node to another reporting node (ensuring exact synchroniza= tion). The agreed concept of DOIC associations between reacting node and re= porting node does not cover this. Based on this, I propose that the text be kept as is and that this issue=20 be closed without changes to the specification. The threshold for changing what is currently in the DOIC specification=20 is rough consensus in the group that it should be changed. Anyone with=20 an opinion is encouraged to state it now.=20 [Wiehe, Ulrich (NSN - DE/Munich)] I can accept to keep text as it is (altho= ugh my preference is in favour of Susan's approach), as it allows the HSS t= o send host-reports and does not force it to send realm-reports. This is not a vote (we don't=20 vote in the IETF...) but an attempt to see if we have consensus to=20 either close the issue without a change in the specification or if we=20 have consensus to change the specification. Regards, Steve _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Sat Jul 19 01:49:06 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8C51A0167 for ; Sat, 19 Jul 2014 01:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 nDUhIYADsXtg for ; Sat, 19 Jul 2014 01:49:03 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96C451A00D2 for ; Sat, 19 Jul 2014 01:49:03 -0700 (PDT) Received: by mail-oi0-f41.google.com with SMTP id a141so2324561oig.28 for ; Sat, 19 Jul 2014 01:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FyRofPSZdn/4pxJwLPxLyk1fOhu6/mGNk1YyGBn1NHQ=; b=WzoRiqh9GXUU7f4on3bXnPDio96Uq6si2nFVzlU7w2pCSxwAFhj4O65zN/dTIoAAKx E7yV9VSMmgRV4AU3530htVi8ZPe9bcKSM9jgyzyQwMlDrjKH/agiMWJrWxKtzMpU16gk PpcFfCYoEQwEmzRdVv+UrCIsL0tORTWso3ywp3Vh3W77bNtlKGHDg497ONkpVgt/Ftzz jWhCvdHPpULtKAnqdCtbkEreFvzK67WyBcEBMsjFhzF6cgoYAgBiPATvfRuFVN4yg5E6 z94URb+qGF6PRCwqSLnDG5elw9GolGJdy9kfvkySmJmw4cZ7m16GJRKaPTptuUkH7cld ePuA== MIME-Version: 1.0 X-Received: by 10.60.174.3 with SMTP id bo3mr14459734oec.31.1405759743050; Sat, 19 Jul 2014 01:49:03 -0700 (PDT) Received: by 10.202.181.70 with HTTP; Sat, 19 Jul 2014 01:49:03 -0700 (PDT) In-Reply-To: <53C9985F.4080908@gmail.com> References: <53C9985F.4080908@gmail.com> Date: Sat, 19 Jul 2014 10:49:03 +0200 Message-ID: From: Matt Holdrege To: Jouni Korhonen Content-Type: multipart/alternative; boundary=089e011844ce1fcefe04fe87f295 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/CzIMS4bA1PkDJEa45GujYDffO5I Cc: dime@ietf.org Subject: Re: [Dime] Strange paragraph in http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-21 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 08:49:05 -0000 --089e011844ce1fcefe04fe87f295 Content-Type: text/plain; charset=UTF-8 Ouch! Sorry. I guess I wasn't looking in the right place. I see that the paragraph was fixed anyways. Thanks, -Matt On Fri, Jul 18, 2014 at 11:57 PM, Jouni Korhonen wrote: > Matt, > > RFC3588 has been obsoleted by RFC6733 (i.e. no use to look into 3588bis > versions). > > - Jouni > > 7/18/2014 10:25 PM, Matt Holdrege kirjoitti: > >> Hi, >> >> Sorry to butt in with a minor nit, but I noticed that section 2.2 >> appears to have mutually exclusive statements. >> >> 1. Connections between Diameter peers SHOULD be protected by TLS. >> 2. The Diameter protocol MUST NOT be used without any security mechanism. >> >> I thought the text in RFC 3588 was ok, minus all the NAS bits? Or maybe >> say that the "Diameter protocol must not be used without inclusive or >> external transport layer security". Or some such text? >> >> -Matt >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> --089e011844ce1fcefe04fe87f295 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ouch! Sorry. I guess I wasn't looking in the right pla= ce. I see that the paragraph was fixed anyways.=C2=A0

Th= anks,
-Matt


On Fri, Jul 18, 2014 at 11:57 PM, Jouni Korhonen <jouni.nospam@gmail.= com> wrote:
Matt,

RFC3588 has been obsoleted by RFC6733 (i.e. no use to look into 3588bis ver= sions).

- Jouni

7/18/2014 10:25 PM, Matt Holdrege kirjoitti:
Hi,

Sorry to butt in with a minor nit, but I noticed that section 2.2
appears to have mutually exclusive statements.

1. Connections between Diameter peers SHOULD be protected by TLS.
2. The Diameter protocol MUST NOT be used without any security mechanism.
I thought the text in RFC 3588 was ok, minus all the NAS bits? Or maybe
say that the "Diameter protocol must not be used without inclusive or<= br> external transport layer security". Or some such text?

-Matt



_______________________________________________
DiME mailing list
DiME@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dime


--089e011844ce1fcefe04fe87f295-- From nobody Sat Jul 19 07:29:05 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CCE1B2835; Sat, 19 Jul 2014 07:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham 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 DIMoPaIeykaE; Sat, 19 Jul 2014 07:28:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9411B2847; Sat, 19 Jul 2014 07:28:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140719142857.947.68841.idtracker@ietfa.amsl.com> Date: Sat, 19 Jul 2014 07:28:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/1Zf8921Ouq7556fwxgN4UaxyOXM Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-app-design-guide-25.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 14:28:59 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Applications Design Guidelines Author(s) : L. Morand, et al Filename : draft-ietf-dime-app-design-guide Pages : 26 Date : 2014-07-19 The Diameter base protocol provides facilities for protocol extensibility enabling to define new Diameter applications or modify existing applications. This document is a companion document to the Diameter Base protocol that further explains and clarifies the rules to extend Diameter. Furthermore, this document provides guidelines to Diameter application designers reusing/defining Diameter applications or creating generic Diameter extensions. A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-dime-app-design-guide-25.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-dime-app-design-guide"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-07-19072857.I-D@ietf.org> --NextPart-- From nobody Sun Jul 20 10:46:23 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADB11B2908 for ; Sun, 20 Jul 2014 10:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 Y-R1OS_jnp_d for ; Sun, 20 Jul 2014 10:46:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBC6F1B2907 for ; Sun, 20 Jul 2014 10:46:19 -0700 (PDT) Received: from localhost ([::1]:38162 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X8vBe-0001yW-Kz; Sun, 20 Jul 2014 10:46:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, srdonovan@usdonovans.com X-Trac-Project: dime Date: Sun, 20 Jul 2014 17:46:14 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/49#comment:2 Message-ID: <072.630e7b4effc39ca857b8d37b864adbdf@trac.tools.ietf.org> References: <057.08dd5ea0343928355a0b92f85a22d2ac@trac.tools.ietf.org> X-Trac-Ticket-ID: 49 In-Reply-To: <057.08dd5ea0343928355a0b92f85a22d2ac@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Zd2krhx9RCp_gEx1Y6C6sR76-b4 Cc: dime@ietf.org Subject: Re: [Dime] [dime] #49 (draft-ietf-dime-ovli): capabilities announcement mechanism needs to be rethought X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 17:46:21 -0000 #49: capabilities announcement mechanism needs to be rethought Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: Agreed that the lifetime of capabilities announcement is a single transaction. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: critical | Milestone: Component: draft-ietf- | Version: 1.0 dime-ovli | Resolution: fixed Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: dime From nobody Sun Jul 20 11:55:43 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0471B2959 for ; Sun, 20 Jul 2014 11:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 xul0NtOWyZpM for ; Sun, 20 Jul 2014 11:55:39 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75391B27F0 for ; Sun, 20 Jul 2014 11:55:38 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id p10so6635314wes.30 for ; Sun, 20 Jul 2014 11:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=uRz/MbOITepxbhX43rNaaS6huUEDA/RrZZhU65+ez3U=; b=E5SgaY29jROkL9U4mSnfrzb3XcD7PiCnq8Vmx4VrCqF0+2IV/b9f4HAWT315N6XI2d hNFefhTikBz+7ogE2kidxsMyMKWn6xwuEmCd96wSDNZVVDK85gqRT41X1UD2B6TsfFER cFpEB8IfwQGvdEeD+riuV0PKotW9sX4Uz+FekFScyGKeExYfeBrO+SLTWYZiOpVs8Kwq Eo1r/tOKYJvdE0SHTjT2VPwhK4ofOnm4JtpxwJLE94CcbvQ9d3ME3JhtAfN4CYIHGYn2 Ea++JEWa1mb8HmIUcDqukfHSKWcDOuKFKT3u4NuHb2CoVaQG0bLIWXqG9zimkQKI1aVh a72A== X-Received: by 10.180.211.134 with SMTP id nc6mr13665655wic.44.1405882537360; Sun, 20 Jul 2014 11:55:37 -0700 (PDT) Received: from ?IPv6:2001:67c:370:144:e1c9:76dc:cfed:3d91? ([2001:67c:370:144:e1c9:76dc:cfed:3d91]) by mx.google.com with ESMTPSA id wd7sm31626205wjc.36.2014.07.20.11.55.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Jul 2014 11:55:36 -0700 (PDT) Message-ID: <53CC10A4.4070200@gmail.com> Date: Sun, 20 Jul 2014 21:55:32 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , ext Steve Donovan , "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xx6DOuzofTNgYC_viPADA7pVmDI Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 18:55:42 -0000 Some comments inline.. 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: > Steve, > please see my response inline. > > Regards > Ulrich > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan > Sent: Tuesday, July 15, 2014 3:53 PM > To: dime@ietf.org > Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt > > Ulrich, > > Thanks for the comments. Please see my responses inline. > > Regards, > > Steve > On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Hi Steve, >> here are my comments. >> They focus on new text you introduced. I agree that restructuring may require new text, however, I believe that with the new text a new concepts is introduced which macerates the agreed end-to-end concept and allows all DOIC agents on the path to do what they wants, so that we end up in a hop-by-hop concept. > SRD> We have never had an agreement on end-to-end versus hop-by-hop and > I believe that we will end up with a hybrid of the two. We have open > issues on agent behavior that Ben and I are attempting to address with > the agent cases draft. > [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop approach of the roach draft was reason not to proceed with that draft. > > SRD> That said, this type of restructuring of the document is likely to > put agreed to behavior in a new light. If there are cases where I have > implied changes to agreed to normative behavior, or if the informative > text is not accurate, then these things need to be corrected. >> >> 1. clause 2.3, second paragraph: >> Should read: "Reacting nodes indicate support for DOIC by including the OC-Supported-Features AVP into all request messages originated or relayed by the Reacting node." > SRD> You mean clause 3.2. > [Wiehe, Ulrich (NSN - DE/Munich)] yes > I agree with the change. >> >> 2. clause 2.3, 3rd paragraph, 1st sentence: >> OC-xxx AVPs must not be included in an answer message when the corresponding request did not contain an OC-S-F AVP. > SRD> Agreed. >> >> 3. clause 3.3, 7th paragraph: >> Should read "The reporting node only includes an indication of support for one overload abatement algorithm. This is the algorithm that the reporting node intends to use should it enter an overload condition or requests to use while it actually is in an overload condition. Reacting nodes can use the indicated overload abatement algorithm to prepare for possible overload reports and must use the indicated overload abatement algorithm if traffic reduction is actually requested." > SRD. OK. >> >> 4. clause 3.3, 10th paragraph: >> The 1st sentence is misleading. In the general case, agents on the path between reacting node and reporting node are transparent. I agree that there are exceptions to the general case where an agent on the path is not transparent, but then the agent IS the reporting node (reporting to the sender of the request) and it also IS the reacting node (reacting on reports received from the upstream reporting node). >> The first 3 words of the second sentence "in this case" need clarification: "In the case where an agent takes the role of a reporting node (reporting to the downstream reacting node) and at the same time takes the role of a reacting node (reacting on reports received from an upstream reporting node)". >> Last sentence: Its not an update but a replacement. The two DOIC associations are handled independently. > SRD> I don't know what you mean when you say an agent is transparent. > Agents must take an active role in even the most basic case for overload > handling to work, so they cannot be transparent. > [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not support DOIC are transparent. Agents that support DOIC in most cases behave like non supporting agents. I am towards Ulrich's view here. Even for an agent that understands DOIC it is up to the local policy whether it is transparent or takes an active role. >> 5. clause 3.3, last paragraph: >> General rules shall be followed for each of the two associations separately. The content of the OC-S-F AVP sent by the agent upstream should reflect what the agent is able and willing to support (as always). > SRD> What two associations? Is there one association (end-to-end) or is > the an association on both sides of the agent (hop-by-hop)? Or is there > an association that involves three entities, the reporting node, an > agent reacting node for realm-routed requests and a transaction-client > reporting node for handling host-routed requests? > [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, > There is one association between C and A, and one association between A and S. Both associations are "end-to-end" as there may be transparent (supporting or non-supporting) agents in the middle. >> >> 6. clause 3.4, 2nd paragraph: >> Should read: "The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP includes the type of report, a sequence number, the length of time that the report is valid and abatement algorithm specific AVPs." > SRD> The sequence number is being used as an overload report ID. I can > make the change but I don't see it as necessary. > [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. OK to do the change. >> 7. clause 3.4, 4th paragraph, 2nd sentence: >> I cannot understand this sentence. Probably only simple typos but I don't know. > SRD> Yes, a typo (this instead of the) and awkward wording. How about > "This applies to requests that contain the Destination-Host AVP with a > DiameterIdentity that matches the overload report. > [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that contain a DiameterIdentity in the Destination-Host AVP that matches the reporting host's DiameterIdentity" I would be inclined to keep the text Steve proposed. But both are ok actually. >> >> 8. clause 3.4, 4th paragraph last 2 sentences: >> I don't understand and probably do not agree. > SRD> See above. >> >> 9. clause 3.5, 3rd paragraph, last word: >> Should read "communicated" > SRD> Agreed. >> >> 10. clause 3.5, 4th paragraph, 1st sentence: >> I don't understand. I can understand: "Reporting nodes use the OC-OLR AVP to communicate overload occurances towards reacting nodes." > SRD> Who else would reports be sent to? > [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement algorithm but the reporting node that uses the OC-OLR AVP to communicate overload occurances. Agree. >> 11. clause 4.1, 3rd paragraph, last 4 words: >> may be misleading. A DOIC supporting agent sitting between DOIC supporting client and DOIC supporting Server is transparent with regard to DOIC. This agent does not indicate DOIC support. > SRD> I disagree. > [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Should be: ...This agent does not indicate its DOIC support, rather it transparently forwards the client's DOIC support. Agree with Ulrich on the intent of agent behavior but not with the proposed text change. >> 12. clause 4.1, 4th paragraph, 2nd sentence: >> Should read:"If a request message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent inserts the AVP." > SRD> That is what it already says. > [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... OC-Supported-Features can be in both request and answer, thus "If a message" in that sense is correct. >> 13. clause 4.1, last sentence: >> Should read "If the message already has the AVP then the agent either leaves it unchanged in the relayed message or replaces it to reflect the features the agent is able and willing to support." Clarification is needed to say that strict rules must be followed by the agent to select the correct option. These rules take into account whether the request is host-routed or relam-routed and whether the agent is configured to select the server for realm-routed requests. > SRD> This is a topic on agent behavior that is addressed in the agent > cases draft. I'll leave the discussion for what the wording should be > to the discussion on that draft. >> >> 14. clause 4.1.2, 2nd paragraph: >> Should read: "Based on the content of the OC-Supported-Features AVP in the request message, the reporting node knows what overload control functionality is supported by the reacting node. The reporting node then acts accordingly for the subsequent answer messages it initiates for the transaction." > SRD> It would be easier if you didn't make it difficult to understand > the change you are proposing. I think you are proposing changing > node(s) to node. I don't agree but that will be addressed as part of > the agent cases discussion. > [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing two sentences? The proposal is to insert "is" between "functionality" and "supported", to add "the" between "by" and "reacting", to replace "node(s)" with "node", and to insert "for the transaction" after "initiates". Agree with the proposed change. >> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >> Should read: "message's" > SRD> I'm assuming you mean section 4.1.2. > [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, and 19. > I agree to the change. >> >> 16. clause 4.1, 6th paragraph: >> This should be left to the (future) specification that introduces other DOIC features. >> >> 17. clause 4.1, 7th paragraph, last 6 words: >> should be based on requiements set by the (future) specification that introduces other DOIC features > SRD> Again, clause 4.1.2 -- I don't understand the issue when these two > paragraphs are taken together. >> >> 18. clause 4.1, 8th paragraph, last sentence: >> Should read: "Lack of the OC-Supported-Features AVP in the request message indicates that there is no downstream reacting node for the transaction." > SRD> I think you mean clause 4.1.2. I don't see the need for the change. > [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not correct. It should either read: "Lack of the OC-Supported-Feature AVP in the request message indicates to the reporting node that there is no reacting node for the transaction" or as proposed above. I don't see a reason for the change. Original text seem correct to me. >> 19. clause 4.1, last sentence: >> Should read: "An agent MAY replace the OC-Supported-Features AVP carried in answer messages." This replacement must follow general rules. Its not so that the agent may do what ever it wants to. The decision must be based on whether or not the agent has replaced the OC-S-F in the corresponding request. > SRD> What is the difference between modify and replace? I am ok with > removing this statement until we have the agent behavior discussion. I > thought I had taken the agent specific statements out of this version. > [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with identical values. You remove what has been received in and insert your own stuff. Agent (proxy) can always do that i.e. modify the APV contents. Obviously if an agent tampers the OC-Supported-Features AVP it needs to know what it is doing. In general agree with the clarification but not with the proposed text. - Jouni >> 20. clause 5.2, 1st sentence: >> Should read: "A reporting node using the loss algorithm must use the OC-Reduction-Percentage AVP (Section 6.7) to indicated the desired percentage of traffic reduction." > SRD> Agreed. >> >> 21. clause 5.2, last sentence: >> Should read: "Editor's note: The above duplicates what is in the OC-Reduction-Percentage AVP section and can probably be removed." > SRD> Yes, bad wording. The note will be removed, bad wording and all, > once there is a discussion on if this is redundant. >> >> 22. clause 5.4, 6th paragraph: >> Should read: "If the reacting node does not receive a an OLR in the answer that corresponds to the probe request messages sent to the formally overloaded node then the reacting node should slowly increase the rate of traffic sent to the overloaded node." > SRD Agreed, this is more clear. >> >> >> Best regards >> Ulrich >> >> >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan >> Sent: Saturday, July 05, 2014 9:42 PM >> To: dime@ietf.org >> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >> >> All, >> >> This version of the DOIC draft is a restructuring of previously agreed >> to content. >> >> The master plan for the restructuring is in Appendix C. This outlines >> where material from -02 was moved in -03. >> >> For those interested, the work was done in steps, with a snapshot for >> each step available here: >> >> https://github.com/jounikor/draft-docdt-dime-ovli >> >> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >> >> where nn indicates the subversion and "text" indicates the focus for >> that subversion. >> >> The next step will be to resolve open issues already identified and >> those yet those yet to be identified. >> >> Regards, >> >> Steve >> >> >> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. >>> >>> Title : Diameter Overload Indication Conveyance >>> Authors : Jouni Korhonen >>> Steve Donovan >>> Ben Campbell >>> Lionel Morand >>> Filename : draft-ietf-dime-ovli-03.txt >>> Pages : 48 >>> Date : 2014-07-03 >>> >>> Abstract: >>> This specification documents a Diameter Overload Control (DOC) base >>> solution and the dissemination of the overload report information. >>> >>> Requirements >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-03 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Sun Jul 20 13:25:06 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71321B2CB6 for ; Sun, 20 Jul 2014 13:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=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 Q_ttxWenebxR for ; Sun, 20 Jul 2014 13:25:03 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 37F351B2CDF for ; Sun, 20 Jul 2014 13:25:03 -0700 (PDT) Received: from [64.31.33.52] (port=55649 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X8xfD-0007f0-2d for dime@ietf.org; Sun, 20 Jul 2014 13:24:58 -0700 Message-ID: <53CC2596.9000801@usdonovans.com> Date: Sun, 20 Jul 2014 16:24:54 -0400 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gVO2YmC9XwEexEu1dYBBoc3AsMM Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 20:25:05 -0000 >> 14. clause 4.1.2, 2nd paragraph: >> Should read: "Based on the content of the OC-Supported-Features AVP in the request message, the reporting node knows what overload control functionality is supported by the reacting node. The reporting node then acts accordingly for the subsequent answer messages it initiates for the transaction." > SRD> It would be easier if you didn't make it difficult to understand > the change you are proposing. I think you are proposing changing > node(s) to node. I don't agree but that will be addressed as part of > the agent cases discussion. > [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing two sentences? The proposal is to insert "is" between "functionality" and "supported", to add "the" between "by" and "reacting", to replace "node(s)" with "node", and to insert "for the transaction" after "initiates". > It would be much easier if you included both the original text and the proposed change. It can sometimes be difficult to find the original text, especially when the incorrect section number is given. Some changes are also subtle when having to switch between the document and email. Having both in the email makes it easier to understand the proposed changes. From nobody Sun Jul 20 13:38:40 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F8C1B2CEF for ; Sun, 20 Jul 2014 13:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779] autolearn=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 bIji_BblFCIE for ; Sun, 20 Jul 2014 13:38:38 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 566101B2CED for ; Sun, 20 Jul 2014 13:38:38 -0700 (PDT) Received: from [64.31.33.52] (port=55754 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X8xsI-0000NN-S9; Sun, 20 Jul 2014 13:38:33 -0700 Message-ID: <53CC28C1.50102@usdonovans.com> Date: Sun, 20 Jul 2014 16:38:25 -0400 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jouni Korhonen , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> In-Reply-To: <53CC10A4.4070200@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/AqkQcZlm3gI7YGeU1BH_xTbGYgM Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 20:38:39 -0000 I've removed most of the message to focus on one of Ulrich's comments. >>> 4. clause 3.3, 10th paragraph: >>> The 1st sentence is misleading. In the general case, agents on the >>> path between reacting node and reporting node are transparent. I >>> agree that there are exceptions to the general case where an agent >>> on the path is not transparent, but then the agent IS the reporting >>> node (reporting to the sender of the request) and it also IS the >>> reacting node (reacting on reports received from the upstream >>> reporting node). >>> The first 3 words of the second sentence "in this case" need >>> clarification: "In the case where an agent takes the role of a >>> reporting node (reporting to the downstream reacting node) and at >>> the same time takes the role of a reacting node (reacting on reports >>> received from an upstream reporting node)". >>> Last sentence: Its not an update but a replacement. The two DOIC >>> associations are handled independently. >> SRD> I don't know what you mean when you say an agent is transparent. >> Agents must take an active role in even the most basic case for overload >> handling to work, so they cannot be transparent. >> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not >> support DOIC are transparent. Agents that support DOIC in most cases >> behave like non supporting agents. > > I am towards Ulrich's view here. Even for an agent that understands > DOIC it is up to the local policy whether it is transparent or takes > an active role. > I think I agree with Jouni's statement that whether a DOIC agent is "transparent" is up to local policy. I need someone to formally define transparent before I can fully agree. If transparent means equivalent in behavior to a non DOIC agent, which I think Ulrich is implying, then I do not agree. I would assert that a DOIC agent's behavior is never the same as a non DOIC agent. A DOIC agent must always check for presence of the OC-Supported-Features AVP in request messages, and if it is not present, it should insert one. This is clearly governed by local policy but the requirement that an agent be able to handle abatement for a non supporting transaction client makes this behavior necessary. From nobody Sun Jul 20 13:47:38 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A741B2976 for ; Sun, 20 Jul 2014 13:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779] autolearn=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 lbQq65kClyU1 for ; Sun, 20 Jul 2014 13:47:35 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 964B61B295B for ; Sun, 20 Jul 2014 13:47:35 -0700 (PDT) Received: from [64.31.33.52] (port=55774 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X8y13-0005zr-MA; Sun, 20 Jul 2014 13:47:33 -0700 Message-ID: <53CC2AE0.80700@usdonovans.com> Date: Sun, 20 Jul 2014 16:47:28 -0400 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jouni Korhonen , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> In-Reply-To: <53CC10A4.4070200@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ASvf-Tr0KBbdqs6Bl1ouHhbCslk Subject: [Dime] What is a DOIC Association (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jul 2014 20:47:37 -0000 Original email trimmed to focus on one point. >>> 5. clause 3.3, last paragraph: >>> General rules shall be followed for each of the two associations >>> separately. The content of the OC-S-F AVP sent by the agent upstream >>> should reflect what the agent is able and willing to support (as >>> always). >> SRD> What two associations? Is there one association (end-to-end) or is >> the an association on both sides of the agent (hop-by-hop)? Or is there >> an association that involves three entities, the reporting node, an >> agent reacting node for realm-routed requests and a transaction-client >> reporting node for handling host-routed requests? >> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, >> There is one association between C and A, and one association between >> A and S. Both associations are "end-to-end" as there may be >> transparent (supporting or non-supporting) agents in the middle. While I thought I understood what a DOIC association was, I am now confused by the concept. My interpretation originally was that there were associations between any two DOIC nodes and that it was a way of addressing the need for DOIC signalling to cross non supporting nodes. I think Ulrich's interpretation is that an association is between a reporting and a reacting node. Either way, I don't see the concept as adding value. There is no behavior associated with an association. Behavior is instead associated capability advertisement and with overload reports. I'm inclined to say we should remove the concept entirely. From nobody Sun Jul 20 17:24:43 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4F61B2A60 for ; Sun, 20 Jul 2014 17:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 z-DDJOvoFMhH for ; Sun, 20 Jul 2014 17:24:41 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5BCD1B2A5B for ; Sun, 20 Jul 2014 17:24:40 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so3280266wiv.11 for ; Sun, 20 Jul 2014 17:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ixWWJSCcIAODnV0MHZtnbr4UgEjoPO+SITt/pToxz70=; b=TSQlwO/Q0yoPvyXzzqp4JAzrLsnqJgeAkwuaZEAQbis6g9AC+wiiLR6cKxmv/Ma4Kw R6e9AtvTwugsf4oGFaBvsYEpw3SCoxsgyJ99mkry6OSLsmu2E9nGpr42kaqZux6F1Xvz 6yi0g8U2kdXGI9CLMF2j2QW48wmhx0CMsqECn/1s/pA5nu7yE+EtYOww3V64rQaKUODy htQPB76HhFNZjm+7CCoAdjY2A2siDp/6XTU8Ndsl3RhHJZsTEzaHwVALPyGrMmmf9OtX KNgMJrY4h5qclzSCDL+41wO0rq3QTcuwdjxv5CR6ALgS6VfWfmRtAZ/D8yNapgKI/JGc 2IZw== X-Received: by 10.194.123.105 with SMTP id lz9mr17737432wjb.122.1405902279158; Sun, 20 Jul 2014 17:24:39 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:a137:da86:4198:3b? ([2001:67c:370:136:a137:da86:4198:3b]) by mx.google.com with ESMTPSA id h13sm33411691wjs.2.2014.07.20.17.24.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Jul 2014 17:24:38 -0700 (PDT) Message-ID: <53CC5DC3.4050507@gmail.com> Date: Mon, 21 Jul 2014 03:24:35 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steve Donovan , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CC28C1.50102@usdonovans.com> In-Reply-To: <53CC28C1.50102@usdonovans.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/uRj_JFMdfpq_JXsUb9pI5C5XiM8 Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 00:24:42 -0000 Steve, 7/20/2014 11:38 PM, Steve Donovan kirjoitti: > I've removed most of the message to focus on one of Ulrich's comments. > >>>> 4. clause 3.3, 10th paragraph: >>>> The 1st sentence is misleading. In the general case, agents on the >>>> path between reacting node and reporting node are transparent. I >>>> agree that there are exceptions to the general case where an agent >>>> on the path is not transparent, but then the agent IS the reporting >>>> node (reporting to the sender of the request) and it also IS the >>>> reacting node (reacting on reports received from the upstream >>>> reporting node). >>>> The first 3 words of the second sentence "in this case" need >>>> clarification: "In the case where an agent takes the role of a >>>> reporting node (reporting to the downstream reacting node) and at >>>> the same time takes the role of a reacting node (reacting on reports >>>> received from an upstream reporting node)". >>>> Last sentence: Its not an update but a replacement. The two DOIC >>>> associations are handled independently. >>> SRD> I don't know what you mean when you say an agent is transparent. >>> Agents must take an active role in even the most basic case for overload >>> handling to work, so they cannot be transparent. >>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not >>> support DOIC are transparent. Agents that support DOIC in most cases >>> behave like non supporting agents. >> >> I am towards Ulrich's view here. Even for an agent that understands >> DOIC it is up to the local policy whether it is transparent or takes >> an active role. >> > I think I agree with Jouni's statement that whether a DOIC agent is > "transparent" is up to local policy. I need someone to formally define > transparent before I can fully agree. If transparent means equivalent > in behavior to a non DOIC agent, which I think Ulrich is implying, then > I do not agree. Agree that "transparent" is a bit bad wording here, because for me at least "transparent proxies" have a strong existing behavioral model (from HTTP proxies that is..). For me the DOIC agent behaviour should be the following (by local configuration etc): 1) the DOIC feature is turned off. The agent behaves like non-DOIC enabled agent. 2) the DOIC feature is on and the local policy says the agent check every message to apply the DOIC thing. This could be e.g. behaving as an endpoint for non-supporting nodes. 3) the DOIC feature is on but the local policy selectively picks up the messages it needs to apply the DOIC thing (this could be handled e.g. based on ACLs on both IP and Diameter level). Otherwise the same as 2) For cases 2) and 3) whether the agent inserts e.g. a missing OC-Supported-Feature for a message that otherwise falls into those that need DOIC to be applied is again a local policy. - Jouni > I would assert that a DOIC agent's behavior is never the same as a non > DOIC agent. A DOIC agent must always check for presence of the > OC-Supported-Features AVP in request messages, and if it is not present, > it should insert one. This is clearly governed by local policy but the > requirement that an agent be able to handle abatement for a non > supporting transaction client makes this behavior necessary. Anyway, could we say (and agree) that a DOIC enabled agent > From nobody Sun Jul 20 21:08:27 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EA81A033E for ; Sun, 20 Jul 2014 21:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 pWK-6ppZ5rwB for ; Sun, 20 Jul 2014 21:08:23 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D61FC1A0338 for ; Sun, 20 Jul 2014 21:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16577; q=dns/txt; s=iport; t=1405915703; x=1407125303; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RJ+Lazyfn+SMWI05/svHyYhfuSD0Da23wfUjfLVE3TI=; b=XpHstvFZgjPJiep0XbpOBWQhXsWsRzjsm0imNlLmwNJXveFZeBRcm5Qq H/GFctkY2Ect4+vsdskR8RgfLl9ZHbMuRRX7xxW1fL3mq+73wpcj/RMcP Nk2Z9Bbl1zRbkRhtqNgPzT8n/Oq4GHFNPLjbhTOgUJ3MS4eX4xuSnZd71 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigGAH2RzFOtJA2G/2dsb2JhbABZgw5SUwQExRMKh0QBgQ4WdoQDAQEBAwEBAQE3LQcXBAIBCBEEAQEBCgsJCQcnCxQJCAIEARIIARKIHwgIBb8HF4cjhw5pOAYEgySBGAWOQ44vkmKDRGyBRQ X-IronPort-AV: E=Sophos;i="5.01,698,1400025600"; d="scan'208";a="62545762" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP; 21 Jul 2014 04:08:22 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s6L48Lx3002959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jul 2014 04:08:21 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Sun, 20 Jul 2014 23:08:21 -0500 From: "Nirav Salot (nsalot)" To: Jouni Korhonen , "Wiehe, Ulrich (NSN - DE/Munich)" , ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt Thread-Index: AQHPlvYBG7pdMU8lTkq6F2nWhP/TapuSOEoAgA4zSQCAASJ2AIAF3kMAgAJR9gCAAEZTgA== Date: Mon, 21 Jul 2014 04:08:20 +0000 Message-ID: References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> In-Reply-To: <53CC10A4.4070200@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.59.25.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/8eopsHaZ2TltFUCEujJlAiw_rVA Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 04:08:26 -0000 +1 for the following aspect. >>> Agents must take an active role in even the most basic case for=20 >>> overload handling to work, so they cannot be transparent. >> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not sup= port DOIC are transparent. Agents that support DOIC in most cases behave li= ke non supporting agents. >I am towards Ulrich's view here. Even for an agent that understands DOIC i= t is up to the local policy whether it is transparent or takes an active ro= le. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Monday, July 21, 2014 12:26 AM To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt Some comments inline.. 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: > Steve, > please see my response inline. > > Regards > Ulrich > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve=20 > Donovan > Sent: Tuesday, July 15, 2014 3:53 PM > To: dime@ietf.org > Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt > > Ulrich, > > Thanks for the comments. Please see my responses inline. > > Regards, > > Steve > On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Hi Steve, >> here are my comments. >> They focus on new text you introduced. I agree that restructuring may re= quire new text, however, I believe that with the new text a new concepts is= introduced which macerates the agreed end-to-end concept and allows all DO= IC agents on the path to do what they wants, so that we end up in a hop-by-= hop concept. > SRD> We have never had an agreement on end-to-end versus hop-by-hop=20 > SRD> and > I believe that we will end up with a hybrid of the two. We have open=20 > issues on agent behavior that Ben and I are attempting to address with=20 > the agent cases draft. > [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop approach = of the roach draft was reason not to proceed with that draft. > > SRD> That said, this type of restructuring of the document is likely=20 > SRD> to > put agreed to behavior in a new light. If there are cases where I=20 > have implied changes to agreed to normative behavior, or if the=20 > informative text is not accurate, then these things need to be corrected. >> >> 1. clause 2.3, second paragraph: >> Should read: "Reacting nodes indicate support for DOIC by including the = OC-Supported-Features AVP into all request messages originated or relayed b= y the Reacting node." > SRD> You mean clause 3.2. > [Wiehe, Ulrich (NSN - DE/Munich)] yes > I agree with the change. >> >> 2. clause 2.3, 3rd paragraph, 1st sentence: >> OC-xxx AVPs must not be included in an answer message when the correspon= ding request did not contain an OC-S-F AVP. > SRD> Agreed. >> >> 3. clause 3.3, 7th paragraph: >> Should read "The reporting node only includes an indication of support f= or one overload abatement algorithm. This is the algorithm that the report= ing node intends to use should it enter an overload condition or requests t= o use while it actually is in an overload condition. Reacting nodes can use= the indicated overload abatement algorithm to prepare for possible overloa= d reports and must use the indicated overload abatement algorithm if traffi= c reduction is actually requested." > SRD. OK. >> >> 4. clause 3.3, 10th paragraph: >> The 1st sentence is misleading. In the general case, agents on the path = between reacting node and reporting node are transparent. I agree that ther= e are exceptions to the general case where an agent on the path is not tran= sparent, but then the agent IS the reporting node (reporting to the sender = of the request) and it also IS the reacting node (reacting on reports recei= ved from the upstream reporting node). >> The first 3 words of the second sentence "in this case" need clarificati= on: "In the case where an agent takes the role of a reporting node (reporti= ng to the downstream reacting node) and at the same time takes the role of = a reacting node (reacting on reports received from an upstream reporting no= de)". >> Last sentence: Its not an update but a replacement. The two DOIC associa= tions are handled independently. > SRD> I don't know what you mean when you say an agent is transparent. > Agents must take an active role in even the most basic case for=20 > overload handling to work, so they cannot be transparent. > [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not supp= ort DOIC are transparent. Agents that support DOIC in most cases behave lik= e non supporting agents. I am towards Ulrich's view here. Even for an agent that understands DOIC it= is up to the local policy whether it is transparent or takes an active rol= e. >> 5. clause 3.3, last paragraph: >> General rules shall be followed for each of the two associations separat= ely. The content of the OC-S-F AVP sent by the agent upstream should reflec= t what the agent is able and willing to support (as always). > SRD> What two associations? Is there one association (end-to-end) or=20 > SRD> is > the an association on both sides of the agent (hop-by-hop)? Or is=20 > there an association that involves three entities, the reporting node,=20 > an agent reacting node for realm-routed requests and a=20 > transaction-client reporting node for handling host-routed requests? > [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, There is=20 > one association between C and A, and one association between A and S. Bot= h associations are "end-to-end" as there may be transparent (supporting or = non-supporting) agents in the middle. >> >> 6. clause 3.4, 2nd paragraph: >> Should read: "The OC-OLR AVP is referred to as an overload report. The = OC-OLR AVP includes the type of report, a sequence number, the length of ti= me that the report is valid and abatement algorithm specific AVPs." > SRD> The sequence number is being used as an overload report ID. I can > make the change but I don't see it as necessary. > [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. OK to do the change. >> 7. clause 3.4, 4th paragraph, 2nd sentence: >> I cannot understand this sentence. Probably only simple typos but I don'= t know. > SRD> Yes, a typo (this instead of the) and awkward wording. How about > "This applies to requests that contain the Destination-Host AVP with a=20 > DiameterIdentity that matches the overload report. > [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that contain= a DiameterIdentity in the Destination-Host AVP that matches the reporting = host's DiameterIdentity" I would be inclined to keep the text Steve proposed. But both are ok actual= ly. >> >> 8. clause 3.4, 4th paragraph last 2 sentences: >> I don't understand and probably do not agree. > SRD> See above. >> >> 9. clause 3.5, 3rd paragraph, last word: >> Should read "communicated" > SRD> Agreed. >> >> 10. clause 3.5, 4th paragraph, 1st sentence: >> I don't understand. I can understand: "Reporting nodes use the OC-OLR AV= P to communicate overload occurances towards reacting nodes." > SRD> Who else would reports be sent to? > [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement algorith= m but the reporting node that uses the OC-OLR AVP to communicate overload o= ccurances. Agree. >> 11. clause 4.1, 3rd paragraph, last 4 words: >> may be misleading. A DOIC supporting agent sitting between DOIC supporti= ng client and DOIC supporting Server is transparent with regard to DOIC. Th= is agent does not indicate DOIC support. > SRD> I disagree. > [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Should = be: ...This agent does not indicate its DOIC support, rather it transparent= ly forwards the client's DOIC support. Agree with Ulrich on the intent of agent behavior but not with the proposed= text change. >> 12. clause 4.1, 4th paragraph, 2nd sentence: >> Should read:"If a request message handled by the DOIC agent does not inc= lude the OC-Supported-Features AVP then the DOIC agent inserts the AVP." > SRD> That is what it already says. > [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... OC-Supported-Features can be in both request and answer, thus "If a message= " in that sense is correct. >> 13. clause 4.1, last sentence: >> Should read "If the message already has the AVP then the agent either le= aves it unchanged in the relayed message or replaces it to reflect the feat= ures the agent is able and willing to support." Clarification is needed to = say that strict rules must be followed by the agent to select the correct o= ption. These rules take into account whether the request is host-routed or = relam-routed and whether the agent is configured to select the server for r= ealm-routed requests. > SRD> This is a topic on agent behavior that is addressed in the agent > cases draft. I'll leave the discussion for what the wording should be=20 > to the discussion on that draft. >> >> 14. clause 4.1.2, 2nd paragraph: >> Should read: "Based on the content of the OC-Supported-Features AVP in t= he request message, the reporting node knows what overload control function= ality is supported by the reacting node. The reporting node then acts acco= rdingly for the subsequent answer messages it initiates for the transaction= ." > SRD> It would be easier if you didn't make it difficult to understand > the change you are proposing. I think you are proposing changing > node(s) to node. I don't agree but that will be addressed as part of=20 > the agent cases discussion. > [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing two se= ntences? The proposal is to insert "is" between "functionality" and "suppor= ted", to add "the" between "by" and "reacting", to replace "node(s)" with "= node", and to insert "for the transaction" after "initiates". Agree with the proposed change. >> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >> Should read: "message's" > SRD> I'm assuming you mean section 4.1.2. > [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, and = 19. > I agree to the change. >> >> 16. clause 4.1, 6th paragraph: >> This should be left to the (future) specification that introduces other = DOIC features. >> >> 17. clause 4.1, 7th paragraph, last 6 words: >> should be based on requiements set by the (future) specification that=20 >> introduces other DOIC features > SRD> Again, clause 4.1.2 -- I don't understand the issue when these=20 > SRD> two > paragraphs are taken together. >> >> 18. clause 4.1, 8th paragraph, last sentence: >> Should read: "Lack of the OC-Supported-Features AVP in the request messa= ge indicates that there is no downstream reacting node for the transaction.= " > SRD> I think you mean clause 4.1.2. I don't see the need for the change. > [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not correc= t. It should either read: "Lack of the OC-Supported-Feature AVP in the requ= est message indicates to the reporting node that there is no reacting node = for the transaction" or as proposed above. I don't see a reason for the change. Original text seem correct to me. >> 19. clause 4.1, last sentence: >> Should read: "An agent MAY replace the OC-Supported-Features AVP carried= in answer messages." This replacement must follow general rules. Its not s= o that the agent may do what ever it wants to. The decision must be based o= n whether or not the agent has replaced the OC-S-F in the corresponding req= uest. > SRD> What is the difference between modify and replace? I am ok with > removing this statement until we have the agent behavior discussion. =20 > I thought I had taken the agent specific statements out of this version. > [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with identical = values. You remove what has been received in and insert your own stuff. Agent (proxy) can always do that i.e. modify the APV contents. Obviously if= an agent tampers the OC-Supported-Features AVP it needs to know what it is= doing. In general agree with the clarification but not with the proposed t= ext. - Jouni >> 20. clause 5.2, 1st sentence: >> Should read: "A reporting node using the loss algorithm must use the OC-= Reduction-Percentage AVP (Section 6.7) to indicated the desired percentage = of traffic reduction." > SRD> Agreed. >> >> 21. clause 5.2, last sentence: >> Should read: "Editor's note: The above duplicates what is in the OC-Redu= ction-Percentage AVP section and can probably be removed." > SRD> Yes, bad wording. The note will be removed, bad wording and all, > once there is a discussion on if this is redundant. >> >> 22. clause 5.4, 6th paragraph: >> Should read: "If the reacting node does not receive a an OLR in the answ= er that corresponds to the probe request messages sent to the formally over= loaded node then the reacting node should slowly increase the rate of traff= ic sent to the overloaded node." > SRD Agreed, this is more clear. >> >> >> Best regards >> Ulrich >> >> >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve=20 >> Donovan >> Sent: Saturday, July 05, 2014 9:42 PM >> To: dime@ietf.org >> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >> >> All, >> >> This version of the DOIC draft is a restructuring of previously=20 >> agreed to content. >> >> The master plan for the restructuring is in Appendix C. This=20 >> outlines where material from -02 was moved in -03. >> >> For those interested, the work was done in steps, with a snapshot for=20 >> each step available here: >> >> https://github.com/jounikor/draft-docdt-dime-ovli >> >> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >> >> where nn indicates the subversion and "text" indicates the focus for=20 >> that subversion. >> >> The next step will be to resolve open issues already identified and=20 >> those yet those yet to be identified. >> >> Regards, >> >> Steve >> >> >> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >>> This draft is a work item of the Diameter Maintenance and Extension= s Working Group of the IETF. >>> >>> Title : Diameter Overload Indication Conveyance >>> Authors : Jouni Korhonen >>> Steve Donovan >>> Ben Campbell >>> Lionel Morand >>> Filename : draft-ietf-dime-ovli-03.txt >>> Pages : 48 >>> Date : 2014-07-03 >>> >>> Abstract: >>> This specification documents a Diameter Overload Control (DOC) ba= se >>> solution and the dissemination of the overload report information= . >>> >>> Requirements >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-ovli-03 >>> >>> >>> Please note that it may take a couple of minutes from the time of=20 >>> submission until the htmlized version and diff are available at tools.i= etf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Mon Jul 21 03:21:47 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66A91B2CBF for ; Mon, 21 Jul 2014 03:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Bn7LnweB6DiG for ; Mon, 21 Jul 2014 03:21:44 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F59A1A0278 for ; Mon, 21 Jul 2014 03:21:44 -0700 (PDT) Received: by mail-ig0-f173.google.com with SMTP id h18so2634008igc.6 for ; Mon, 21 Jul 2014 03:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=28dLLZCHtHM54c4fQIni4anfsoYlzW8Ctyjm5kPtjNo=; b=gS3uURQt2hC9OK66EOQePaU0nUaSoTz0ltm4tylOj1D175YAe9lX1NluzObhyglCQ6 UYFXxJiCyk3Lhc0hPAI73mkyJROkvkHiOjz+hJBLMKZAVTdw2pv/4wb1njBhkJDp9Gl0 U65bPuBQVs0gJ9kdsZI6F59dCpLOKF9A8ZPkTqUYoy2uxqrAcaMzem7LLmRtrdiY8aj2 Wn503XFRLWfmVJ0JUEZsaOTTWvQPMh3cT6hFyReZdIuxQc2WUECuVz9+pljMCyuJHEZC OmBITd0YvTQpD1C9nRwIVdgPQcTzx37KGnc7FerCULyr/++J7RVui6bNaA1sF1BGLTww BqMA== X-Received: by 10.43.129.74 with SMTP id hh10mr11552936icc.48.1405938103225; Mon, 21 Jul 2014 03:21:43 -0700 (PDT) Received: from [10.0.2.163] ([173.243.43.10]) by mx.google.com with ESMTPSA id kw1sm37463434igb.2.2014.07.21.03.21.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 03:21:42 -0700 (PDT) Message-ID: <53CCE9B5.1030509@gmail.com> Date: Mon, 21 Jul 2014 06:21:41 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" References: <20140721101834.30270.50771.idtracker@ietfa.amsl.com> In-Reply-To: <20140721101834.30270.50771.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140721101834.30270.50771.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/h5QD4jY4pb4CO5OlkNxnxoLOcws Subject: [Dime] Fwd: New Version Notification for draft-zhou-dime-4over6-provisioning-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 10:21:45 -0000 I forgot to post this before deadline. It is the initial use case for the AddressOrPrefix derived AVP data format to be discussed in the meeting. Comments on the document itself would be appreciated. Tom Taylor -------- Original Message -------- Subject: New Version Notification for draft-zhou-dime-4over6-provisioning-03.txt Date: Mon, 21 Jul 2014 03:18:34 -0700 From: internet-drafts@ietf.org To: M. Boucadair , "Qiong Sun" , "Tom Taylor" , Cathy Zhou , Qiong Sun , T. Taylor , "Cathy Zhou" , "Mohamed Boucadair" A new version of I-D, draft-zhou-dime-4over6-provisioning-03.txt has been successfully submitted by T. Taylor and posted to the IETF repository. Name: draft-zhou-dime-4over6-provisioning Revision: 03 Title: Attribute-Value Pairs For Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions Document date: 2014-07-21 Group: Individual Submission Pages: 14 URL: http://www.ietf.org/internet-drafts/draft-zhou-dime-4over6-provisioning-03.txt Status: https://datatracker.ietf.org/doc/draft-zhou-dime-4over6-provisioning/ Htmlized: http://tools.ietf.org/html/draft-zhou-dime-4over6-provisioning-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-zhou-dime-4over6-provisioning-03 Abstract: During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been or are currently being defined for carrying IPv4 packets over IPv6. Work is currently in progress to enumerate the information that needs to be provisioned on a customer edge router to support a list of transition techniques based on tunneling IPv4 in IPv6, with a view to defining reusable components for a reasonable transition path between these techniques. To the extent that the provisioning is done dynamically, AAA support is needed to provide the information to the network server responsible for passing the information to the customer equipment. This document specifies Diameter attribute-value pairs to be used for that purpose. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Jul 21 06:17:13 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CA31B2BEA for ; Mon, 21 Jul 2014 06:17:01 -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, SPF_NEUTRAL=0.779] autolearn=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 t6JsgPauFSMH for ; Mon, 21 Jul 2014 06:16:58 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 BA5DD1B2DFE for ; Mon, 21 Jul 2014 06:15:45 -0700 (PDT) Received: from dhcp-a698.meeting.ietf.org ([31.133.166.152]:51025) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X9DRH-0002SU-5L; Mon, 21 Jul 2014 06:15:40 -0700 Message-ID: <53CD1274.40405@usdonovans.com> Date: Mon, 21 Jul 2014 09:15:32 -0400 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Nirav Salot (nsalot)" , Jouni Korhonen , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kMmAWuk5shH6KM6PlLt10MsXqhQ Subject: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 13:17:01 -0000 Ok, let's see if it's possible to completely turn off all DOIC behavior in agents and still be able to reduce traffic to a server that sends a host overload report. Assume the following agent based deployment: +--+ /--|s1| +-+ +-+ / +--+ |c|--|a|== ... +-+ +-+ \ +--+ \--|sn| +--+ Assume that there is a large number of servers, say 50. Now, assume that the Diameter application in question exclusively uses realm-routed requests - 100% of requests sent by the client do NOT have a destination-host AVP. Now assume that server s1 sends an host type overload report requesting a reduction of 20% using the loss algorithm. Also assume that the unused capacity in servers s2 through s50 is sufficient to handle the traffic that would have been sent to s1. As such, there is no reason to throttle any requests. There are no host routed requests for this application and the client does not have a direct transport connection to server s1. The only option a client has is to hand the request off to the agent for routing. The proposal in the agent cases draft is that the agent diverts 20% of the realm routed requests that would have been sent to server s1 to servers s2 through s50. If DOIC behavior is turned off in the agent then how will the traffic routed to s1 be reduced? Steve On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote: > +1 for the following aspect. > >>>> Agents must take an active role in even the most basic case for >>>> overload handling to work, so they cannot be transparent. >>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not support DOIC are transparent. Agents that support DOIC in most cases behave like non supporting agents. >> I am towards Ulrich's view here. Even for an agent that understands DOIC it is up to the local policy whether it is transparent or takes an active role. > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Monday, July 21, 2014 12:26 AM > To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org > Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt > > Some comments inline.. > > 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >> Steve, >> please see my response inline. >> >> Regards >> Ulrich >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >> Donovan >> Sent: Tuesday, July 15, 2014 3:53 PM >> To: dime@ietf.org >> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >> >> Ulrich, >> >> Thanks for the comments. Please see my responses inline. >> >> Regards, >> >> Steve >> On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>> Hi Steve, >>> here are my comments. >>> They focus on new text you introduced. I agree that restructuring may require new text, however, I believe that with the new text a new concepts is introduced which macerates the agreed end-to-end concept and allows all DOIC agents on the path to do what they wants, so that we end up in a hop-by-hop concept. >> SRD> We have never had an agreement on end-to-end versus hop-by-hop >> SRD> and >> I believe that we will end up with a hybrid of the two. We have open >> issues on agent behavior that Ben and I are attempting to address with >> the agent cases draft. >> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop approach of the roach draft was reason not to proceed with that draft. >> >> SRD> That said, this type of restructuring of the document is likely >> SRD> to >> put agreed to behavior in a new light. If there are cases where I >> have implied changes to agreed to normative behavior, or if the >> informative text is not accurate, then these things need to be corrected. >>> 1. clause 2.3, second paragraph: >>> Should read: "Reacting nodes indicate support for DOIC by including the OC-Supported-Features AVP into all request messages originated or relayed by the Reacting node." >> SRD> You mean clause 3.2. >> [Wiehe, Ulrich (NSN - DE/Munich)] yes >> I agree with the change. >>> 2. clause 2.3, 3rd paragraph, 1st sentence: >>> OC-xxx AVPs must not be included in an answer message when the corresponding request did not contain an OC-S-F AVP. >> SRD> Agreed. >>> 3. clause 3.3, 7th paragraph: >>> Should read "The reporting node only includes an indication of support for one overload abatement algorithm. This is the algorithm that the reporting node intends to use should it enter an overload condition or requests to use while it actually is in an overload condition. Reacting nodes can use the indicated overload abatement algorithm to prepare for possible overload reports and must use the indicated overload abatement algorithm if traffic reduction is actually requested." >> SRD. OK. >>> 4. clause 3.3, 10th paragraph: >>> The 1st sentence is misleading. In the general case, agents on the path between reacting node and reporting node are transparent. I agree that there are exceptions to the general case where an agent on the path is not transparent, but then the agent IS the reporting node (reporting to the sender of the request) and it also IS the reacting node (reacting on reports received from the upstream reporting node). >>> The first 3 words of the second sentence "in this case" need clarification: "In the case where an agent takes the role of a reporting node (reporting to the downstream reacting node) and at the same time takes the role of a reacting node (reacting on reports received from an upstream reporting node)". >>> Last sentence: Its not an update but a replacement. The two DOIC associations are handled independently. >> SRD> I don't know what you mean when you say an agent is transparent. >> Agents must take an active role in even the most basic case for >> overload handling to work, so they cannot be transparent. >> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not support DOIC are transparent. Agents that support DOIC in most cases behave like non supporting agents. > I am towards Ulrich's view here. Even for an agent that understands DOIC it is up to the local policy whether it is transparent or takes an active role. > >>> 5. clause 3.3, last paragraph: >>> General rules shall be followed for each of the two associations separately. The content of the OC-S-F AVP sent by the agent upstream should reflect what the agent is able and willing to support (as always). >> SRD> What two associations? Is there one association (end-to-end) or >> SRD> is >> the an association on both sides of the agent (hop-by-hop)? Or is >> there an association that involves three entities, the reporting node, >> an agent reacting node for realm-routed requests and a >> transaction-client reporting node for handling host-routed requests? >> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, There is >> one association between C and A, and one association between A and S. Both associations are "end-to-end" as there may be transparent (supporting or non-supporting) agents in the middle. >>> 6. clause 3.4, 2nd paragraph: >>> Should read: "The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP includes the type of report, a sequence number, the length of time that the report is valid and abatement algorithm specific AVPs." >> SRD> The sequence number is being used as an overload report ID. I can >> make the change but I don't see it as necessary. >> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. > OK to do the change. > >>> 7. clause 3.4, 4th paragraph, 2nd sentence: >>> I cannot understand this sentence. Probably only simple typos but I don't know. >> SRD> Yes, a typo (this instead of the) and awkward wording. How about >> "This applies to requests that contain the Destination-Host AVP with a >> DiameterIdentity that matches the overload report. >> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that contain a DiameterIdentity in the Destination-Host AVP that matches the reporting host's DiameterIdentity" > I would be inclined to keep the text Steve proposed. But both are ok actually. > >>> 8. clause 3.4, 4th paragraph last 2 sentences: >>> I don't understand and probably do not agree. >> SRD> See above. >>> 9. clause 3.5, 3rd paragraph, last word: >>> Should read "communicated" >> SRD> Agreed. >>> 10. clause 3.5, 4th paragraph, 1st sentence: >>> I don't understand. I can understand: "Reporting nodes use the OC-OLR AVP to communicate overload occurances towards reacting nodes." >> SRD> Who else would reports be sent to? >> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement algorithm but the reporting node that uses the OC-OLR AVP to communicate overload occurances. > Agree. > >>> 11. clause 4.1, 3rd paragraph, last 4 words: >>> may be misleading. A DOIC supporting agent sitting between DOIC supporting client and DOIC supporting Server is transparent with regard to DOIC. This agent does not indicate DOIC support. >> SRD> I disagree. >> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Should be: ...This agent does not indicate its DOIC support, rather it transparently forwards the client's DOIC support. > Agree with Ulrich on the intent of agent behavior but not with the proposed text change. > >>> 12. clause 4.1, 4th paragraph, 2nd sentence: >>> Should read:"If a request message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent inserts the AVP." >> SRD> That is what it already says. >> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... > OC-Supported-Features can be in both request and answer, thus "If a message" in that sense is correct. > >>> 13. clause 4.1, last sentence: >>> Should read "If the message already has the AVP then the agent either leaves it unchanged in the relayed message or replaces it to reflect the features the agent is able and willing to support." Clarification is needed to say that strict rules must be followed by the agent to select the correct option. These rules take into account whether the request is host-routed or relam-routed and whether the agent is configured to select the server for realm-routed requests. >> SRD> This is a topic on agent behavior that is addressed in the agent >> cases draft. I'll leave the discussion for what the wording should be >> to the discussion on that draft. >>> 14. clause 4.1.2, 2nd paragraph: >>> Should read: "Based on the content of the OC-Supported-Features AVP in the request message, the reporting node knows what overload control functionality is supported by the reacting node. The reporting node then acts accordingly for the subsequent answer messages it initiates for the transaction." >> SRD> It would be easier if you didn't make it difficult to understand >> the change you are proposing. I think you are proposing changing >> node(s) to node. I don't agree but that will be addressed as part of >> the agent cases discussion. >> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing two sentences? The proposal is to insert "is" between "functionality" and "supported", to add "the" between "by" and "reacting", to replace "node(s)" with "node", and to insert "for the transaction" after "initiates". > Agree with the proposed change. > >>> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >>> Should read: "message's" >> SRD> I'm assuming you mean section 4.1.2. >> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, and 19. >> I agree to the change. >>> 16. clause 4.1, 6th paragraph: >>> This should be left to the (future) specification that introduces other DOIC features. >>> >>> 17. clause 4.1, 7th paragraph, last 6 words: >>> should be based on requiements set by the (future) specification that >>> introduces other DOIC features >> SRD> Again, clause 4.1.2 -- I don't understand the issue when these >> SRD> two >> paragraphs are taken together. >>> 18. clause 4.1, 8th paragraph, last sentence: >>> Should read: "Lack of the OC-Supported-Features AVP in the request message indicates that there is no downstream reacting node for the transaction." >> SRD> I think you mean clause 4.1.2. I don't see the need for the change. >> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not correct. It should either read: "Lack of the OC-Supported-Feature AVP in the request message indicates to the reporting node that there is no reacting node for the transaction" or as proposed above. > I don't see a reason for the change. Original text seem correct to me. > >>> 19. clause 4.1, last sentence: >>> Should read: "An agent MAY replace the OC-Supported-Features AVP carried in answer messages." This replacement must follow general rules. Its not so that the agent may do what ever it wants to. The decision must be based on whether or not the agent has replaced the OC-S-F in the corresponding request. >> SRD> What is the difference between modify and replace? I am ok with >> removing this statement until we have the agent behavior discussion. >> I thought I had taken the agent specific statements out of this version. >> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with identical values. You remove what has been received in and insert your own stuff. > Agent (proxy) can always do that i.e. modify the APV contents. Obviously if an agent tampers the OC-Supported-Features AVP it needs to know what it is doing. In general agree with the clarification but not with the proposed text. > > - Jouni > >>> 20. clause 5.2, 1st sentence: >>> Should read: "A reporting node using the loss algorithm must use the OC-Reduction-Percentage AVP (Section 6.7) to indicated the desired percentage of traffic reduction." >> SRD> Agreed. >>> 21. clause 5.2, last sentence: >>> Should read: "Editor's note: The above duplicates what is in the OC-Reduction-Percentage AVP section and can probably be removed." >> SRD> Yes, bad wording. The note will be removed, bad wording and all, >> once there is a discussion on if this is redundant. >>> 22. clause 5.4, 6th paragraph: >>> Should read: "If the reacting node does not receive a an OLR in the answer that corresponds to the probe request messages sent to the formally overloaded node then the reacting node should slowly increase the rate of traffic sent to the overloaded node." >> SRD Agreed, this is more clear. >>> >>> Best regards >>> Ulrich >>> >>> >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>> Donovan >>> Sent: Saturday, July 05, 2014 9:42 PM >>> To: dime@ietf.org >>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>> >>> All, >>> >>> This version of the DOIC draft is a restructuring of previously >>> agreed to content. >>> >>> The master plan for the restructuring is in Appendix C. This >>> outlines where material from -02 was moved in -03. >>> >>> For those interested, the work was done in steps, with a snapshot for >>> each step available here: >>> >>> https://github.com/jounikor/draft-docdt-dime-ovli >>> >>> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >>> >>> where nn indicates the subversion and "text" indicates the focus for >>> that subversion. >>> >>> The next step will be to resolve open issues already identified and >>> those yet those yet to be identified. >>> >>> Regards, >>> >>> Steve >>> >>> >>> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. >>>> >>>> Title : Diameter Overload Indication Conveyance >>>> Authors : Jouni Korhonen >>>> Steve Donovan >>>> Ben Campbell >>>> Lionel Morand >>>> Filename : draft-ietf-dime-ovli-03.txt >>>> Pages : 48 >>>> Date : 2014-07-03 >>>> >>>> Abstract: >>>> This specification documents a Diameter Overload Control (DOC) base >>>> solution and the dissemination of the overload report information. >>>> >>>> Requirements >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-03 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Mon Jul 21 06:40:08 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 067F51B2DD1 for ; Mon, 21 Jul 2014 06:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 CIoQQKrUpZu0 for ; Mon, 21 Jul 2014 06:39:56 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09231B2BEE for ; Mon, 21 Jul 2014 06:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19092; q=dns/txt; s=iport; t=1405949765; x=1407159365; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=nPRO8sl7oruPGRywJlPmL8QHfZQQV4alq1lt7EnWMMM=; b=AjN6mXB0lJ8vZ6seXNfG/4FElsHV/rDZLIhp794amIYBuq+YsC+j7TC6 1/mDo7Fx+VdtFELgwS2K7EnsCurKf87OVR4hgA+jMG1fxDf2VSjvr0wYK qqFpDFifzKAp7XgOYRLwAQC3nq2ySrwkMTgigk9avyUOBaJu5noGSJGhb c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAGEWzVOtJA2E/2dsb2JhbABZgw5SUwjFOAqHRQGBFRZ2hAMBAQEEAQEBNy0HFwQCAQgOAwQBAQEKCwkJBycLFAkIAgQBEggBEognCAW+aBeHI4cOaTgGBIMkgRgFnHKSYoNEbIFF X-IronPort-AV: E=Sophos;i="5.01,701,1400025600"; d="scan'208";a="338543293" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP; 21 Jul 2014 13:36:03 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s6LDa2ka002988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jul 2014 13:36:02 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 21 Jul 2014 08:36:02 -0500 From: "Nirav Salot (nsalot)" To: Steve Donovan , Jouni Korhonen , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" Thread-Topic: Transparent agents (was Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt) Thread-Index: AQHPpOXkqc17USN1sEWmJtfvuRKMb5uqhp3w Date: Mon, 21 Jul 2014 13:36:01 +0000 Message-ID: References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> In-Reply-To: <53CD1274.40405@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.93.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/29G07XdqAHvI70Gfw5aZPFMakdE Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 13:40:00 -0000 Steve, In the example below, you are assuming that "any server can serve any subsc= riber session". However, if that is not the case then the agent has no choice but to route = the request to the appropriate server, irrespective of its used/unused capa= city. The point being, "the DOIC supporting agent must take an active role" is no= t accurate/correct. It is based on other factors and finally on local policy. Regards, Nirav. -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Monday, July 21, 2014 6:46 PM To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); = dime@ietf.org Subject: Transparent agents (was Re: [Dime] I-D Action: draft-ietf-dime-ovl= i-03.txt) Ok, let's see if it's possible to completely turn off all DOIC behavior in = agents and still be able to reduce traffic to a server that sends a host ov= erload report. Assume the following agent based deployment: +--+ /--|s1| +-+ +-+ / +--+ |c|--|a|=3D=3D ... +-+ +-+ \ +--+ \--|sn| +--+ Assume that there is a large number of servers, say 50. Now, assume that the Diameter application in question exclusively uses real= m-routed requests - 100% of requests sent by the client do NOT have a desti= nation-host AVP. Now assume that server s1 sends an host type overload report requesting a r= eduction of 20% using the loss algorithm. Also assume that the unused capacity in servers s2 through s50 is sufficien= t to handle the traffic that would have been sent to s1. As such, there is = no reason to throttle any requests. There are no host routed requests for this application and the client does = not have a direct transport connection to server s1. The only option a clie= nt has is to hand the request off to the agent for routing. The proposal in the agent cases draft is that the agent diverts 20% of the = realm routed requests that would have been sent to server s1 to servers s2 = through s50. If DOIC behavior is turned off in the agent then how will the traffic route= d to s1 be reduced? Steve On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote: > +1 for the following aspect. > >>>> Agents must take an active role in even the most basic case for=20 >>>> overload handling to work, so they cannot be transparent. >>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not su= pport DOIC are transparent. Agents that support DOIC in most cases behave l= ike non supporting agents. >> I am towards Ulrich's view here. Even for an agent that understands DOIC= it is up to the local policy whether it is transparent or takes an active = role. > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Monday, July 21, 2014 12:26 AM > To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org > Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt > > Some comments inline.. > > 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >> Steve, >> please see my response inline. >> >> Regards >> Ulrich >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve=20 >> Donovan >> Sent: Tuesday, July 15, 2014 3:53 PM >> To: dime@ietf.org >> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >> >> Ulrich, >> >> Thanks for the comments. Please see my responses inline. >> >> Regards, >> >> Steve >> On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>> Hi Steve, >>> here are my comments. >>> They focus on new text you introduced. I agree that restructuring may r= equire new text, however, I believe that with the new text a new concepts i= s introduced which macerates the agreed end-to-end concept and allows all D= OIC agents on the path to do what they wants, so that we end up in a hop-by= -hop concept. >> SRD> We have never had an agreement on end-to-end versus hop-by-hop=20 >> SRD> and >> I believe that we will end up with a hybrid of the two. We have open=20 >> issues on agent behavior that Ben and I are attempting to address=20 >> with the agent cases draft. >> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop approach= of the roach draft was reason not to proceed with that draft. >> >> SRD> That said, this type of restructuring of the document is likely=20 >> SRD> to >> put agreed to behavior in a new light. If there are cases where I=20 >> have implied changes to agreed to normative behavior, or if the=20 >> informative text is not accurate, then these things need to be corrected= . >>> 1. clause 2.3, second paragraph: >>> Should read: "Reacting nodes indicate support for DOIC by including the= OC-Supported-Features AVP into all request messages originated or relayed = by the Reacting node." >> SRD> You mean clause 3.2. >> [Wiehe, Ulrich (NSN - DE/Munich)] yes >> I agree with the change. >>> 2. clause 2.3, 3rd paragraph, 1st sentence: >>> OC-xxx AVPs must not be included in an answer message when the correspo= nding request did not contain an OC-S-F AVP. >> SRD> Agreed. >>> 3. clause 3.3, 7th paragraph: >>> Should read "The reporting node only includes an indication of support = for one overload abatement algorithm. This is the algorithm that the repor= ting node intends to use should it enter an overload condition or requests = to use while it actually is in an overload condition. Reacting nodes can us= e the indicated overload abatement algorithm to prepare for possible overlo= ad reports and must use the indicated overload abatement algorithm if traff= ic reduction is actually requested." >> SRD. OK. >>> 4. clause 3.3, 10th paragraph: >>> The 1st sentence is misleading. In the general case, agents on the path= between reacting node and reporting node are transparent. I agree that the= re are exceptions to the general case where an agent on the path is not tra= nsparent, but then the agent IS the reporting node (reporting to the sender= of the request) and it also IS the reacting node (reacting on reports rece= ived from the upstream reporting node). >>> The first 3 words of the second sentence "in this case" need clarificat= ion: "In the case where an agent takes the role of a reporting node (report= ing to the downstream reacting node) and at the same time takes the role of= a reacting node (reacting on reports received from an upstream reporting n= ode)". >>> Last sentence: Its not an update but a replacement. The two DOIC associ= ations are handled independently. >> SRD> I don't know what you mean when you say an agent is transparent. >> Agents must take an active role in even the most basic case for=20 >> overload handling to work, so they cannot be transparent. >> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not sup= port DOIC are transparent. Agents that support DOIC in most cases behave li= ke non supporting agents. > I am towards Ulrich's view here. Even for an agent that understands DOIC = it is up to the local policy whether it is transparent or takes an active r= ole. > >>> 5. clause 3.3, last paragraph: >>> General rules shall be followed for each of the two associations separa= tely. The content of the OC-S-F AVP sent by the agent upstream should refle= ct what the agent is able and willing to support (as always). >> SRD> What two associations? Is there one association (end-to-end) or=20 >> SRD> is >> the an association on both sides of the agent (hop-by-hop)? Or is=20 >> there an association that involves three entities, the reporting=20 >> node, an agent reacting node for realm-routed requests and a=20 >> transaction-client reporting node for handling host-routed requests? >> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, There=20 >> is one association between C and A, and one association between A and S.= Both associations are "end-to-end" as there may be transparent (supporting= or non-supporting) agents in the middle. >>> 6. clause 3.4, 2nd paragraph: >>> Should read: "The OC-OLR AVP is referred to as an overload report. The= OC-OLR AVP includes the type of report, a sequence number, the length of t= ime that the report is valid and abatement algorithm specific AVPs." >> SRD> The sequence number is being used as an overload report ID. I=20 >> SRD> can >> make the change but I don't see it as necessary. >> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. > OK to do the change. > >>> 7. clause 3.4, 4th paragraph, 2nd sentence: >>> I cannot understand this sentence. Probably only simple typos but I don= 't know. >> SRD> Yes, a typo (this instead of the) and awkward wording. How=20 >> SRD> about >> "This applies to requests that contain the Destination-Host AVP with=20 >> a DiameterIdentity that matches the overload report. >> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that contai= n a DiameterIdentity in the Destination-Host AVP that matches the reporting= host's DiameterIdentity" > I would be inclined to keep the text Steve proposed. But both are ok actu= ally. > >>> 8. clause 3.4, 4th paragraph last 2 sentences: >>> I don't understand and probably do not agree. >> SRD> See above. >>> 9. clause 3.5, 3rd paragraph, last word: >>> Should read "communicated" >> SRD> Agreed. >>> 10. clause 3.5, 4th paragraph, 1st sentence: >>> I don't understand. I can understand: "Reporting nodes use the OC-OLR A= VP to communicate overload occurances towards reacting nodes." >> SRD> Who else would reports be sent to? >> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement algorit= hm but the reporting node that uses the OC-OLR AVP to communicate overload = occurances. > Agree. > >>> 11. clause 4.1, 3rd paragraph, last 4 words: >>> may be misleading. A DOIC supporting agent sitting between DOIC support= ing client and DOIC supporting Server is transparent with regard to DOIC. T= his agent does not indicate DOIC support. >> SRD> I disagree. >> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Should= be: ...This agent does not indicate its DOIC support, rather it transparen= tly forwards the client's DOIC support. > Agree with Ulrich on the intent of agent behavior but not with the propos= ed text change. > >>> 12. clause 4.1, 4th paragraph, 2nd sentence: >>> Should read:"If a request message handled by the DOIC agent does not in= clude the OC-Supported-Features AVP then the DOIC agent inserts the AVP." >> SRD> That is what it already says. >> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... > OC-Supported-Features can be in both request and answer, thus "If a messa= ge" in that sense is correct. > >>> 13. clause 4.1, last sentence: >>> Should read "If the message already has the AVP then the agent either l= eaves it unchanged in the relayed message or replaces it to reflect the fea= tures the agent is able and willing to support." Clarification is needed to= say that strict rules must be followed by the agent to select the correct = option. These rules take into account whether the request is host-routed or= relam-routed and whether the agent is configured to select the server for = realm-routed requests. >> SRD> This is a topic on agent behavior that is addressed in the agent >> cases draft. I'll leave the discussion for what the wording should=20 >> be to the discussion on that draft. >>> 14. clause 4.1.2, 2nd paragraph: >>> Should read: "Based on the content of the OC-Supported-Features AVP in = the request message, the reporting node knows what overload control functio= nality is supported by the reacting node. The reporting node then acts acc= ordingly for the subsequent answer messages it initiates for the transactio= n." >> SRD> It would be easier if you didn't make it difficult to understand >> the change you are proposing. I think you are proposing changing >> node(s) to node. I don't agree but that will be addressed as part of=20 >> the agent cases discussion. >> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing two s= entences? The proposal is to insert "is" between "functionality" and "suppo= rted", to add "the" between "by" and "reacting", to replace "node(s)" with = "node", and to insert "for the transaction" after "initiates". > Agree with the proposed change. > >>> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >>> Should read: "message's" >> SRD> I'm assuming you mean section 4.1.2. >> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, and= 19. >> I agree to the change. >>> 16. clause 4.1, 6th paragraph: >>> This should be left to the (future) specification that introduces other= DOIC features. >>> >>> 17. clause 4.1, 7th paragraph, last 6 words: >>> should be based on requiements set by the (future) specification=20 >>> that introduces other DOIC features >> SRD> Again, clause 4.1.2 -- I don't understand the issue when these=20 >> SRD> two >> paragraphs are taken together. >>> 18. clause 4.1, 8th paragraph, last sentence: >>> Should read: "Lack of the OC-Supported-Features AVP in the request mess= age indicates that there is no downstream reacting node for the transaction= ." >> SRD> I think you mean clause 4.1.2. I don't see the need for the change= . >> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not corre= ct. It should either read: "Lack of the OC-Supported-Feature AVP in the req= uest message indicates to the reporting node that there is no reacting node= for the transaction" or as proposed above. > I don't see a reason for the change. Original text seem correct to me. > >>> 19. clause 4.1, last sentence: >>> Should read: "An agent MAY replace the OC-Supported-Features AVP carrie= d in answer messages." This replacement must follow general rules. Its not = so that the agent may do what ever it wants to. The decision must be based = on whether or not the agent has replaced the OC-S-F in the corresponding re= quest. >> SRD> What is the difference between modify and replace? I am ok with >> removing this statement until we have the agent behavior discussion. >> I thought I had taken the agent specific statements out of this version. >> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with identical= values. You remove what has been received in and insert your own stuff. > Agent (proxy) can always do that i.e. modify the APV contents. Obviously = if an agent tampers the OC-Supported-Features AVP it needs to know what it = is doing. In general agree with the clarification but not with the proposed= text. > > - Jouni > >>> 20. clause 5.2, 1st sentence: >>> Should read: "A reporting node using the loss algorithm must use the OC= -Reduction-Percentage AVP (Section 6.7) to indicated the desired percentage= of traffic reduction." >> SRD> Agreed. >>> 21. clause 5.2, last sentence: >>> Should read: "Editor's note: The above duplicates what is in the OC-Red= uction-Percentage AVP section and can probably be removed." >> SRD> Yes, bad wording. The note will be removed, bad wording and=20 >> SRD> all, >> once there is a discussion on if this is redundant. >>> 22. clause 5.4, 6th paragraph: >>> Should read: "If the reacting node does not receive a an OLR in the ans= wer that corresponds to the probe request messages sent to the formally ove= rloaded node then the reacting node should slowly increase the rate of traf= fic sent to the overloaded node." >> SRD Agreed, this is more clear. >>> >>> Best regards >>> Ulrich >>> >>> >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve=20 >>> Donovan >>> Sent: Saturday, July 05, 2014 9:42 PM >>> To: dime@ietf.org >>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>> >>> All, >>> >>> This version of the DOIC draft is a restructuring of previously=20 >>> agreed to content. >>> >>> The master plan for the restructuring is in Appendix C. This=20 >>> outlines where material from -02 was moved in -03. >>> >>> For those interested, the work was done in steps, with a snapshot=20 >>> for each step available here: >>> >>> https://github.com/jounikor/draft-docdt-dime-ovli >>> >>> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >>> >>> where nn indicates the subversion and "text" indicates the focus for=20 >>> that subversion. >>> >>> The next step will be to resolve open issues already identified and=20 >>> those yet those yet to be identified. >>> >>> Regards, >>> >>> Steve >>> >>> >>> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>>> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >>>> This draft is a work item of the Diameter Maintenance and Extensi= ons Working Group of the IETF. >>>> >>>> Title : Diameter Overload Indication Conveyance >>>> Authors : Jouni Korhonen >>>> Steve Donovan >>>> Ben Campbell >>>> Lionel Morand >>>> Filename : draft-ietf-dime-ovli-03.txt >>>> Pages : 48 >>>> Date : 2014-07-03 >>>> >>>> Abstract: >>>> This specification documents a Diameter Overload Control (DOC) = base >>>> solution and the dissemination of the overload report informati= on. >>>> >>>> Requirements >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-ovli-03 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of=20 >>>> submission until the htmlized version and diff are available at tools.= ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Mon Jul 21 06:51:02 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4CF1A00D6 for ; Mon, 21 Jul 2014 06:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 N6onbdIVUTFW for ; Mon, 21 Jul 2014 06:50:48 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C77641A0031 for ; Mon, 21 Jul 2014 06:48:01 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s6LDluIe002558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 21 Jul 2014 13:47:57 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s6LDlupv002274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jul 2014 15:47:56 +0200 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 21 Jul 2014 15:47:56 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.93]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0181.006; Mon, 21 Jul 2014 15:47:56 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "Nirav Salot (nsalot)" , Jouni Korhonen , "dime@ietf.org" Thread-Topic: Transparent agents (was Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt) Thread-Index: AQHPpOXkMwn2dCkD7UaldZdRer7Z5JuqhwsQ Date: Mon, 21 Jul 2014 13:47:55 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> In-Reply-To: <53CD1274.40405@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.119] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 19213 X-purgate-ID: 151667::1405950477-000005B1-4C6149F4/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/pJaO9fUClxm12iudV6VH9bXExas Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 13:50:54 -0000 Steve, The example you show is absolutely valid and 100% inline with A) to F) - (a= ssuming that all servers can serve any request). However, there are other scenarios like: =20 +--+ /--|s1| +-+ +--+ +--+ / +--+ |c|--- |a1|--|a2|=3D=3D ... +-+ +--+ +--+ \ +--+ \--|sn| +--+ Here I think a1 should be transparent even when DOICable. a1 does not take the role of a reacting node since c supports DOIC. a1 does not perform server selection and therefore does not take the role o= f a reporting node (for realm-reports). Ulrich -----Original Message----- From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Monday, July 21, 2014 3:16 PM To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); = dime@ietf.org Subject: Transparent agents (was Re: [Dime] I-D Action: draft-ietf-dime-ovl= i-03.txt) Ok, let's see if it's possible to completely turn off all DOIC behavior=20 in agents and still be able to reduce traffic to a server that sends a=20 host overload report. Assume the following agent based deployment: +--+ /--|s1| +-+ +-+ / +--+ |c|--|a|=3D=3D ... +-+ +-+ \ +--+ \--|sn| +--+ Assume that there is a large number of servers, say 50. Now, assume that the Diameter application in question exclusively uses=20 realm-routed requests - 100% of requests sent by the client do NOT have=20 a destination-host AVP. Now assume that server s1 sends an host type overload report requesting=20 a reduction of 20% using the loss algorithm. Also assume that the unused capacity in servers s2 through s50 is=20 sufficient to handle the traffic that would have been sent to s1. As=20 such, there is no reason to throttle any requests. There are no host routed requests for this application and the client=20 does not have a direct transport connection to server s1. The only=20 option a client has is to hand the request off to the agent for routing. The proposal in the agent cases draft is that the agent diverts 20% of=20 the realm routed requests that would have been sent to server s1 to=20 servers s2 through s50. If DOIC behavior is turned off in the agent then how will the traffic=20 routed to s1 be reduced? Steve On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote: > +1 for the following aspect. > >>>> Agents must take an active role in even the most basic case for >>>> overload handling to work, so they cannot be transparent. >>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not su= pport DOIC are transparent. Agents that support DOIC in most cases behave l= ike non supporting agents. >> I am towards Ulrich's view here. Even for an agent that understands DOIC= it is up to the local policy whether it is transparent or takes an active = role. > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Monday, July 21, 2014 12:26 AM > To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org > Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt > > Some comments inline.. > > 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >> Steve, >> please see my response inline. >> >> Regards >> Ulrich >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >> Donovan >> Sent: Tuesday, July 15, 2014 3:53 PM >> To: dime@ietf.org >> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >> >> Ulrich, >> >> Thanks for the comments. Please see my responses inline. >> >> Regards, >> >> Steve >> On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>> Hi Steve, >>> here are my comments. >>> They focus on new text you introduced. I agree that restructuring may r= equire new text, however, I believe that with the new text a new concepts i= s introduced which macerates the agreed end-to-end concept and allows all D= OIC agents on the path to do what they wants, so that we end up in a hop-by= -hop concept. >> SRD> We have never had an agreement on end-to-end versus hop-by-hop >> SRD> and >> I believe that we will end up with a hybrid of the two. We have open >> issues on agent behavior that Ben and I are attempting to address with >> the agent cases draft. >> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop approach= of the roach draft was reason not to proceed with that draft. >> >> SRD> That said, this type of restructuring of the document is likely >> SRD> to >> put agreed to behavior in a new light. If there are cases where I >> have implied changes to agreed to normative behavior, or if the >> informative text is not accurate, then these things need to be corrected= . >>> 1. clause 2.3, second paragraph: >>> Should read: "Reacting nodes indicate support for DOIC by including the= OC-Supported-Features AVP into all request messages originated or relayed = by the Reacting node." >> SRD> You mean clause 3.2. >> [Wiehe, Ulrich (NSN - DE/Munich)] yes >> I agree with the change. >>> 2. clause 2.3, 3rd paragraph, 1st sentence: >>> OC-xxx AVPs must not be included in an answer message when the correspo= nding request did not contain an OC-S-F AVP. >> SRD> Agreed. >>> 3. clause 3.3, 7th paragraph: >>> Should read "The reporting node only includes an indication of support = for one overload abatement algorithm. This is the algorithm that the repor= ting node intends to use should it enter an overload condition or requests = to use while it actually is in an overload condition. Reacting nodes can us= e the indicated overload abatement algorithm to prepare for possible overlo= ad reports and must use the indicated overload abatement algorithm if traff= ic reduction is actually requested." >> SRD. OK. >>> 4. clause 3.3, 10th paragraph: >>> The 1st sentence is misleading. In the general case, agents on the path= between reacting node and reporting node are transparent. I agree that the= re are exceptions to the general case where an agent on the path is not tra= nsparent, but then the agent IS the reporting node (reporting to the sender= of the request) and it also IS the reacting node (reacting on reports rece= ived from the upstream reporting node). >>> The first 3 words of the second sentence "in this case" need clarificat= ion: "In the case where an agent takes the role of a reporting node (report= ing to the downstream reacting node) and at the same time takes the role of= a reacting node (reacting on reports received from an upstream reporting n= ode)". >>> Last sentence: Its not an update but a replacement. The two DOIC associ= ations are handled independently. >> SRD> I don't know what you mean when you say an agent is transparent. >> Agents must take an active role in even the most basic case for >> overload handling to work, so they cannot be transparent. >> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not sup= port DOIC are transparent. Agents that support DOIC in most cases behave li= ke non supporting agents. > I am towards Ulrich's view here. Even for an agent that understands DOIC = it is up to the local policy whether it is transparent or takes an active r= ole. > >>> 5. clause 3.3, last paragraph: >>> General rules shall be followed for each of the two associations separa= tely. The content of the OC-S-F AVP sent by the agent upstream should refle= ct what the agent is able and willing to support (as always). >> SRD> What two associations? Is there one association (end-to-end) or >> SRD> is >> the an association on both sides of the agent (hop-by-hop)? Or is >> there an association that involves three entities, the reporting node, >> an agent reacting node for realm-routed requests and a >> transaction-client reporting node for handling host-routed requests? >> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, There is >> one association between C and A, and one association between A and S. Bo= th associations are "end-to-end" as there may be transparent (supporting or= non-supporting) agents in the middle. >>> 6. clause 3.4, 2nd paragraph: >>> Should read: "The OC-OLR AVP is referred to as an overload report. The= OC-OLR AVP includes the type of report, a sequence number, the length of t= ime that the report is valid and abatement algorithm specific AVPs." >> SRD> The sequence number is being used as an overload report ID. I can >> make the change but I don't see it as necessary. >> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. > OK to do the change. > >>> 7. clause 3.4, 4th paragraph, 2nd sentence: >>> I cannot understand this sentence. Probably only simple typos but I don= 't know. >> SRD> Yes, a typo (this instead of the) and awkward wording. How about >> "This applies to requests that contain the Destination-Host AVP with a >> DiameterIdentity that matches the overload report. >> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that contai= n a DiameterIdentity in the Destination-Host AVP that matches the reporting= host's DiameterIdentity" > I would be inclined to keep the text Steve proposed. But both are ok actu= ally. > >>> 8. clause 3.4, 4th paragraph last 2 sentences: >>> I don't understand and probably do not agree. >> SRD> See above. >>> 9. clause 3.5, 3rd paragraph, last word: >>> Should read "communicated" >> SRD> Agreed. >>> 10. clause 3.5, 4th paragraph, 1st sentence: >>> I don't understand. I can understand: "Reporting nodes use the OC-OLR A= VP to communicate overload occurances towards reacting nodes." >> SRD> Who else would reports be sent to? >> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement algorit= hm but the reporting node that uses the OC-OLR AVP to communicate overload = occurances. > Agree. > >>> 11. clause 4.1, 3rd paragraph, last 4 words: >>> may be misleading. A DOIC supporting agent sitting between DOIC support= ing client and DOIC supporting Server is transparent with regard to DOIC. T= his agent does not indicate DOIC support. >> SRD> I disagree. >> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Should= be: ...This agent does not indicate its DOIC support, rather it transparen= tly forwards the client's DOIC support. > Agree with Ulrich on the intent of agent behavior but not with the propos= ed text change. > >>> 12. clause 4.1, 4th paragraph, 2nd sentence: >>> Should read:"If a request message handled by the DOIC agent does not in= clude the OC-Supported-Features AVP then the DOIC agent inserts the AVP." >> SRD> That is what it already says. >> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... > OC-Supported-Features can be in both request and answer, thus "If a messa= ge" in that sense is correct. > >>> 13. clause 4.1, last sentence: >>> Should read "If the message already has the AVP then the agent either l= eaves it unchanged in the relayed message or replaces it to reflect the fea= tures the agent is able and willing to support." Clarification is needed to= say that strict rules must be followed by the agent to select the correct = option. These rules take into account whether the request is host-routed or= relam-routed and whether the agent is configured to select the server for = realm-routed requests. >> SRD> This is a topic on agent behavior that is addressed in the agent >> cases draft. I'll leave the discussion for what the wording should be >> to the discussion on that draft. >>> 14. clause 4.1.2, 2nd paragraph: >>> Should read: "Based on the content of the OC-Supported-Features AVP in = the request message, the reporting node knows what overload control functio= nality is supported by the reacting node. The reporting node then acts acc= ordingly for the subsequent answer messages it initiates for the transactio= n." >> SRD> It would be easier if you didn't make it difficult to understand >> the change you are proposing. I think you are proposing changing >> node(s) to node. I don't agree but that will be addressed as part of >> the agent cases discussion. >> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing two s= entences? The proposal is to insert "is" between "functionality" and "suppo= rted", to add "the" between "by" and "reacting", to replace "node(s)" with = "node", and to insert "for the transaction" after "initiates". > Agree with the proposed change. > >>> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >>> Should read: "message's" >> SRD> I'm assuming you mean section 4.1.2. >> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, and= 19. >> I agree to the change. >>> 16. clause 4.1, 6th paragraph: >>> This should be left to the (future) specification that introduces other= DOIC features. >>> >>> 17. clause 4.1, 7th paragraph, last 6 words: >>> should be based on requiements set by the (future) specification that >>> introduces other DOIC features >> SRD> Again, clause 4.1.2 -- I don't understand the issue when these >> SRD> two >> paragraphs are taken together. >>> 18. clause 4.1, 8th paragraph, last sentence: >>> Should read: "Lack of the OC-Supported-Features AVP in the request mess= age indicates that there is no downstream reacting node for the transaction= ." >> SRD> I think you mean clause 4.1.2. I don't see the need for the change= . >> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not corre= ct. It should either read: "Lack of the OC-Supported-Feature AVP in the req= uest message indicates to the reporting node that there is no reacting node= for the transaction" or as proposed above. > I don't see a reason for the change. Original text seem correct to me. > >>> 19. clause 4.1, last sentence: >>> Should read: "An agent MAY replace the OC-Supported-Features AVP carrie= d in answer messages." This replacement must follow general rules. Its not = so that the agent may do what ever it wants to. The decision must be based = on whether or not the agent has replaced the OC-S-F in the corresponding re= quest. >> SRD> What is the difference between modify and replace? I am ok with >> removing this statement until we have the agent behavior discussion. >> I thought I had taken the agent specific statements out of this version. >> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with identical= values. You remove what has been received in and insert your own stuff. > Agent (proxy) can always do that i.e. modify the APV contents. Obviously = if an agent tampers the OC-Supported-Features AVP it needs to know what it = is doing. In general agree with the clarification but not with the proposed= text. > > - Jouni > >>> 20. clause 5.2, 1st sentence: >>> Should read: "A reporting node using the loss algorithm must use the OC= -Reduction-Percentage AVP (Section 6.7) to indicated the desired percentage= of traffic reduction." >> SRD> Agreed. >>> 21. clause 5.2, last sentence: >>> Should read: "Editor's note: The above duplicates what is in the OC-Red= uction-Percentage AVP section and can probably be removed." >> SRD> Yes, bad wording. The note will be removed, bad wording and all, >> once there is a discussion on if this is redundant. >>> 22. clause 5.4, 6th paragraph: >>> Should read: "If the reacting node does not receive a an OLR in the ans= wer that corresponds to the probe request messages sent to the formally ove= rloaded node then the reacting node should slowly increase the rate of traf= fic sent to the overloaded node." >> SRD Agreed, this is more clear. >>> >>> Best regards >>> Ulrich >>> >>> >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>> Donovan >>> Sent: Saturday, July 05, 2014 9:42 PM >>> To: dime@ietf.org >>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>> >>> All, >>> >>> This version of the DOIC draft is a restructuring of previously >>> agreed to content. >>> >>> The master plan for the restructuring is in Appendix C. This >>> outlines where material from -02 was moved in -03. >>> >>> For those interested, the work was done in steps, with a snapshot for >>> each step available here: >>> >>> https://github.com/jounikor/draft-docdt-dime-ovli >>> >>> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >>> >>> where nn indicates the subversion and "text" indicates the focus for >>> that subversion. >>> >>> The next step will be to resolve open issues already identified and >>> those yet those yet to be identified. >>> >>> Regards, >>> >>> Steve >>> >>> >>> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>>> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >>>> This draft is a work item of the Diameter Maintenance and Extensi= ons Working Group of the IETF. >>>> >>>> Title : Diameter Overload Indication Conveyance >>>> Authors : Jouni Korhonen >>>> Steve Donovan >>>> Ben Campbell >>>> Lionel Morand >>>> Filename : draft-ietf-dime-ovli-03.txt >>>> Pages : 48 >>>> Date : 2014-07-03 >>>> >>>> Abstract: >>>> This specification documents a Diameter Overload Control (DOC) = base >>>> solution and the dissemination of the overload report informati= on. >>>> >>>> Requirements >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-ovli-03 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission until the htmlized version and diff are available at tools.= ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Mon Jul 21 07:28:41 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF281A0005 for ; Mon, 21 Jul 2014 07:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 s5WfIg60iV28 for ; Mon, 21 Jul 2014 07:28:34 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4095B1A000B for ; Mon, 21 Jul 2014 07:28:34 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 588C1264B91; Mon, 21 Jul 2014 16:28:32 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 370BD4C072; Mon, 21 Jul 2014 16:28:32 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Mon, 21 Jul 2014 16:28:31 +0200 From: To: "Nirav Salot (nsalot)" , Steve Donovan , Jouni Korhonen , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" Thread-Topic: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) Thread-Index: AQHPpOYZ/rD6aquvHEqxqtw07rgFTJuqZhiAgAAus9A= Date: Mon, 21 Jul 2014 14:28:30 +0000 Message-ID: <13924_1405952912_53CD2390_13924_94_1_6B7134B31289DC4FAF731D844122B36E669F04@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.81224 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/TaF-MX3CWVMZ652ymWWB0u96XHs Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:28:38 -0000 Assuming that any server can process any request at any time, I would say t= hat the scenario below is a simple illustration for a dynamic weight/load b= alancer, right? Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalo= t) Envoy=E9=A0: lundi 21 juillet 2014 15:36 =C0=A0: Steve Donovan; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dim= e@ietf.org Objet=A0: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dim= e-ovli-03.txt) Steve, In the example below, you are assuming that "any server can serve any subsc= riber session". However, if that is not the case then the agent has no choice but to route = the request to the appropriate server, irrespective of its used/unused capa= city. The point being, "the DOIC supporting agent must take an active role" is no= t accurate/correct. It is based on other factors and finally on local policy. Regards, Nirav. -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Monday, July 21, 2014 6:46 PM To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); = dime@ietf.org Subject: Transparent agents (was Re: [Dime] I-D Action: draft-ietf-dime-ovl= i-03.txt) Ok, let's see if it's possible to completely turn off all DOIC behavior in = agents and still be able to reduce traffic to a server that sends a host ov= erload report. Assume the following agent based deployment: +--+ /--|s1| +-+ +-+ / +--+ |c|--|a|=3D=3D ... +-+ +-+ \ +--+ \--|sn| +--+ Assume that there is a large number of servers, say 50. Now, assume that the Diameter application in question exclusively uses real= m-routed requests - 100% of requests sent by the client do NOT have a desti= nation-host AVP. Now assume that server s1 sends an host type overload report requesting a r= eduction of 20% using the loss algorithm. Also assume that the unused capacity in servers s2 through s50 is sufficien= t to handle the traffic that would have been sent to s1. As such, there is = no reason to throttle any requests. There are no host routed requests for this application and the client does = not have a direct transport connection to server s1. The only option a clie= nt has is to hand the request off to the agent for routing. The proposal in the agent cases draft is that the agent diverts 20% of the = realm routed requests that would have been sent to server s1 to servers s2 = through s50. If DOIC behavior is turned off in the agent then how will the traffic route= d to s1 be reduced? Steve On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote: > +1 for the following aspect. > >>>> Agents must take an active role in even the most basic case for=20 >>>> overload handling to work, so they cannot be transparent. >>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not su= pport DOIC are transparent. Agents that support DOIC in most cases behave l= ike non supporting agents. >> I am towards Ulrich's view here. Even for an agent that understands DOIC= it is up to the local policy whether it is transparent or takes an active = role. > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Monday, July 21, 2014 12:26 AM > To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org > Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt > > Some comments inline.. > > 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >> Steve, >> please see my response inline. >> >> Regards >> Ulrich >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve=20 >> Donovan >> Sent: Tuesday, July 15, 2014 3:53 PM >> To: dime@ietf.org >> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >> >> Ulrich, >> >> Thanks for the comments. Please see my responses inline. >> >> Regards, >> >> Steve >> On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>> Hi Steve, >>> here are my comments. >>> They focus on new text you introduced. I agree that restructuring may r= equire new text, however, I believe that with the new text a new concepts i= s introduced which macerates the agreed end-to-end concept and allows all D= OIC agents on the path to do what they wants, so that we end up in a hop-by= -hop concept. >> SRD> We have never had an agreement on end-to-end versus hop-by-hop=20 >> SRD> and >> I believe that we will end up with a hybrid of the two. We have open=20 >> issues on agent behavior that Ben and I are attempting to address=20 >> with the agent cases draft. >> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop approach= of the roach draft was reason not to proceed with that draft. >> >> SRD> That said, this type of restructuring of the document is likely=20 >> SRD> to >> put agreed to behavior in a new light. If there are cases where I=20 >> have implied changes to agreed to normative behavior, or if the=20 >> informative text is not accurate, then these things need to be corrected. >>> 1. clause 2.3, second paragraph: >>> Should read: "Reacting nodes indicate support for DOIC by including the= OC-Supported-Features AVP into all request messages originated or relayed = by the Reacting node." >> SRD> You mean clause 3.2. >> [Wiehe, Ulrich (NSN - DE/Munich)] yes >> I agree with the change. >>> 2. clause 2.3, 3rd paragraph, 1st sentence: >>> OC-xxx AVPs must not be included in an answer message when the correspo= nding request did not contain an OC-S-F AVP. >> SRD> Agreed. >>> 3. clause 3.3, 7th paragraph: >>> Should read "The reporting node only includes an indication of support = for one overload abatement algorithm. This is the algorithm that the repor= ting node intends to use should it enter an overload condition or requests = to use while it actually is in an overload condition. Reacting nodes can us= e the indicated overload abatement algorithm to prepare for possible overlo= ad reports and must use the indicated overload abatement algorithm if traff= ic reduction is actually requested." >> SRD. OK. >>> 4. clause 3.3, 10th paragraph: >>> The 1st sentence is misleading. In the general case, agents on the path= between reacting node and reporting node are transparent. I agree that the= re are exceptions to the general case where an agent on the path is not tra= nsparent, but then the agent IS the reporting node (reporting to the sender= of the request) and it also IS the reacting node (reacting on reports rece= ived from the upstream reporting node). >>> The first 3 words of the second sentence "in this case" need clarificat= ion: "In the case where an agent takes the role of a reporting node (report= ing to the downstream reacting node) and at the same time takes the role of= a reacting node (reacting on reports received from an upstream reporting n= ode)". >>> Last sentence: Its not an update but a replacement. The two DOIC associ= ations are handled independently. >> SRD> I don't know what you mean when you say an agent is transparent. >> Agents must take an active role in even the most basic case for=20 >> overload handling to work, so they cannot be transparent. >> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not sup= port DOIC are transparent. Agents that support DOIC in most cases behave li= ke non supporting agents. > I am towards Ulrich's view here. Even for an agent that understands DOIC = it is up to the local policy whether it is transparent or takes an active r= ole. > >>> 5. clause 3.3, last paragraph: >>> General rules shall be followed for each of the two associations separa= tely. The content of the OC-S-F AVP sent by the agent upstream should refle= ct what the agent is able and willing to support (as always). >> SRD> What two associations? Is there one association (end-to-end) or=20 >> SRD> is >> the an association on both sides of the agent (hop-by-hop)? Or is=20 >> there an association that involves three entities, the reporting=20 >> node, an agent reacting node for realm-routed requests and a=20 >> transaction-client reporting node for handling host-routed requests? >> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, There=20 >> is one association between C and A, and one association between A and S.= Both associations are "end-to-end" as there may be transparent (supporting= or non-supporting) agents in the middle. >>> 6. clause 3.4, 2nd paragraph: >>> Should read: "The OC-OLR AVP is referred to as an overload report. The= OC-OLR AVP includes the type of report, a sequence number, the length of t= ime that the report is valid and abatement algorithm specific AVPs." >> SRD> The sequence number is being used as an overload report ID. I=20 >> SRD> can >> make the change but I don't see it as necessary. >> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. > OK to do the change. > >>> 7. clause 3.4, 4th paragraph, 2nd sentence: >>> I cannot understand this sentence. Probably only simple typos but I don= 't know. >> SRD> Yes, a typo (this instead of the) and awkward wording. How=20 >> SRD> about >> "This applies to requests that contain the Destination-Host AVP with=20 >> a DiameterIdentity that matches the overload report. >> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that contai= n a DiameterIdentity in the Destination-Host AVP that matches the reporting= host's DiameterIdentity" > I would be inclined to keep the text Steve proposed. But both are ok actu= ally. > >>> 8. clause 3.4, 4th paragraph last 2 sentences: >>> I don't understand and probably do not agree. >> SRD> See above. >>> 9. clause 3.5, 3rd paragraph, last word: >>> Should read "communicated" >> SRD> Agreed. >>> 10. clause 3.5, 4th paragraph, 1st sentence: >>> I don't understand. I can understand: "Reporting nodes use the OC-OLR A= VP to communicate overload occurances towards reacting nodes." >> SRD> Who else would reports be sent to? >> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement algorit= hm but the reporting node that uses the OC-OLR AVP to communicate overload = occurances. > Agree. > >>> 11. clause 4.1, 3rd paragraph, last 4 words: >>> may be misleading. A DOIC supporting agent sitting between DOIC support= ing client and DOIC supporting Server is transparent with regard to DOIC. T= his agent does not indicate DOIC support. >> SRD> I disagree. >> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Should= be: ...This agent does not indicate its DOIC support, rather it transparen= tly forwards the client's DOIC support. > Agree with Ulrich on the intent of agent behavior but not with the propos= ed text change. > >>> 12. clause 4.1, 4th paragraph, 2nd sentence: >>> Should read:"If a request message handled by the DOIC agent does not in= clude the OC-Supported-Features AVP then the DOIC agent inserts the AVP." >> SRD> That is what it already says. >> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... > OC-Supported-Features can be in both request and answer, thus "If a messa= ge" in that sense is correct. > >>> 13. clause 4.1, last sentence: >>> Should read "If the message already has the AVP then the agent either l= eaves it unchanged in the relayed message or replaces it to reflect the fea= tures the agent is able and willing to support." Clarification is needed to= say that strict rules must be followed by the agent to select the correct = option. These rules take into account whether the request is host-routed or= relam-routed and whether the agent is configured to select the server for = realm-routed requests. >> SRD> This is a topic on agent behavior that is addressed in the agent >> cases draft. I'll leave the discussion for what the wording should=20 >> be to the discussion on that draft. >>> 14. clause 4.1.2, 2nd paragraph: >>> Should read: "Based on the content of the OC-Supported-Features AVP in = the request message, the reporting node knows what overload control functio= nality is supported by the reacting node. The reporting node then acts acc= ordingly for the subsequent answer messages it initiates for the transactio= n." >> SRD> It would be easier if you didn't make it difficult to understand >> the change you are proposing. I think you are proposing changing >> node(s) to node. I don't agree but that will be addressed as part of=20 >> the agent cases discussion. >> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing two s= entences? The proposal is to insert "is" between "functionality" and "suppo= rted", to add "the" between "by" and "reacting", to replace "node(s)" with = "node", and to insert "for the transaction" after "initiates". > Agree with the proposed change. > >>> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >>> Should read: "message's" >> SRD> I'm assuming you mean section 4.1.2. >> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, and= 19. >> I agree to the change. >>> 16. clause 4.1, 6th paragraph: >>> This should be left to the (future) specification that introduces other= DOIC features. >>> >>> 17. clause 4.1, 7th paragraph, last 6 words: >>> should be based on requiements set by the (future) specification=20 >>> that introduces other DOIC features >> SRD> Again, clause 4.1.2 -- I don't understand the issue when these=20 >> SRD> two >> paragraphs are taken together. >>> 18. clause 4.1, 8th paragraph, last sentence: >>> Should read: "Lack of the OC-Supported-Features AVP in the request mess= age indicates that there is no downstream reacting node for the transaction= ." >> SRD> I think you mean clause 4.1.2. I don't see the need for the change. >> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not corre= ct. It should either read: "Lack of the OC-Supported-Feature AVP in the req= uest message indicates to the reporting node that there is no reacting node= for the transaction" or as proposed above. > I don't see a reason for the change. Original text seem correct to me. > >>> 19. clause 4.1, last sentence: >>> Should read: "An agent MAY replace the OC-Supported-Features AVP carrie= d in answer messages." This replacement must follow general rules. Its not = so that the agent may do what ever it wants to. The decision must be based = on whether or not the agent has replaced the OC-S-F in the corresponding re= quest. >> SRD> What is the difference between modify and replace? I am ok with >> removing this statement until we have the agent behavior discussion. >> I thought I had taken the agent specific statements out of this version. >> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with identical= values. You remove what has been received in and insert your own stuff. > Agent (proxy) can always do that i.e. modify the APV contents. Obviously = if an agent tampers the OC-Supported-Features AVP it needs to know what it = is doing. In general agree with the clarification but not with the proposed= text. > > - Jouni > >>> 20. clause 5.2, 1st sentence: >>> Should read: "A reporting node using the loss algorithm must use the OC= -Reduction-Percentage AVP (Section 6.7) to indicated the desired percentage= of traffic reduction." >> SRD> Agreed. >>> 21. clause 5.2, last sentence: >>> Should read: "Editor's note: The above duplicates what is in the OC-Red= uction-Percentage AVP section and can probably be removed." >> SRD> Yes, bad wording. The note will be removed, bad wording and=20 >> SRD> all, >> once there is a discussion on if this is redundant. >>> 22. clause 5.4, 6th paragraph: >>> Should read: "If the reacting node does not receive a an OLR in the ans= wer that corresponds to the probe request messages sent to the formally ove= rloaded node then the reacting node should slowly increase the rate of traf= fic sent to the overloaded node." >> SRD Agreed, this is more clear. >>> >>> Best regards >>> Ulrich >>> >>> >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve=20 >>> Donovan >>> Sent: Saturday, July 05, 2014 9:42 PM >>> To: dime@ietf.org >>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>> >>> All, >>> >>> This version of the DOIC draft is a restructuring of previously=20 >>> agreed to content. >>> >>> The master plan for the restructuring is in Appendix C. This=20 >>> outlines where material from -02 was moved in -03. >>> >>> For those interested, the work was done in steps, with a snapshot=20 >>> for each step available here: >>> >>> https://github.com/jounikor/draft-docdt-dime-ovli >>> >>> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >>> >>> where nn indicates the subversion and "text" indicates the focus for=20 >>> that subversion. >>> >>> The next step will be to resolve open issues already identified and=20 >>> those yet those yet to be identified. >>> >>> Regards, >>> >>> Steve >>> >>> >>> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>>> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >>>> This draft is a work item of the Diameter Maintenance and Extensi= ons Working Group of the IETF. >>>> >>>> Title : Diameter Overload Indication Conveyance >>>> Authors : Jouni Korhonen >>>> Steve Donovan >>>> Ben Campbell >>>> Lionel Morand >>>> Filename : draft-ietf-dime-ovli-03.txt >>>> Pages : 48 >>>> Date : 2014-07-03 >>>> >>>> Abstract: >>>> This specification documents a Diameter Overload Control (DOC) = base >>>> solution and the dissemination of the overload report informati= on. >>>> >>>> Requirements >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-ovli-03 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of=20 >>>> submission until the htmlized version and diff are available at tools.= ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Jul 21 07:29:31 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6ED01A002A for ; Mon, 21 Jul 2014 07:29:27 -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, SPF_NEUTRAL=0.779] autolearn=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 oBKUMgSdT6eB for ; Mon, 21 Jul 2014 07:29:25 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 6A4091A001E for ; Mon, 21 Jul 2014 07:29:25 -0700 (PDT) Received: from dhcp-a698.meeting.ietf.org ([31.133.166.152]:52129) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X9Eab-0001qC-Iv for dime@ietf.org; Mon, 21 Jul 2014 07:29:24 -0700 Message-ID: <53CD23BD.8010906@usdonovans.com> Date: Mon, 21 Jul 2014 10:29:17 -0400 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/n4ScNinW1akwkP6szB0lSajJUzA Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:29:28 -0000 Ulrich, I am not arguing that all agents should take an active role in the handling of all overload reports. What I am arguing is that there are scenarios where an agent must take an active role in DOIC to ensure that a requested reduction in traffic an be achieved. For DOIC to work a carrier cannot turn off all DOIC behavior in agents, as suggested by Jouni. I agree that in your scenario below, a1 does not need to take an active role in reducing traffic when c supports DOIC. a1 should take an active role when c does not support DOIC. The problem is that a1 does not know in advance whether c supports DOIC so it will need to inspect all transactions for the presence of OC-S-F to determine if it needs to handle overload reports for a non supporting client. Does that mean a1 is transparent if it inspects all requests and does nothing in the case where there is c supports DOIC? Does transparent mean that there is no observable difference in the DOIC AVPs that pass through the agent or does it mean that there is no observable difference in how transactions are handled by the DOIC agent? I'm guessing that we have multiple assumptions on what transparent means and, if we are going to continue saying agents should be transparent then we need a definition of transparent. I think for this use case, we need the following normative statements in the draft for handling of abatement of realm-routed requests? I think this is general behavior and should go in the section on handling of overload reports. "DOIC nodes with a direct transport connection to a reporting node that has an active overload report must handle abatement of realm-routed requests. The preferred method for handling abatement of realm-routed requests is diversion, where the node with the direct transport connection routes the request to an alternative server that is able to handle the request. If there is no alternative server with the needed capacity to handle the request then the DOIC node must/should throttle the necessary requests to meet the requested reduction in traffic." If we can agree on this then we can move on to the next agent based use case. Regards, Steve On 7/21/14, 9:47 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > The example you show is absolutely valid and 100% inline with A) to F) - (assuming that all servers can serve any request). > However, there are other scenarios like: > > > > +--+ > /--|s1| > +-+ +--+ +--+ / +--+ > |c|--- |a1|--|a2|== ... > +-+ +--+ +--+ \ +--+ > \--|sn| > +--+ > > Here I think a1 should be transparent even when DOICable. > a1 does not take the role of a reacting node since c supports DOIC. > a1 does not perform server selection and therefore does not take the role of a reporting node (for realm-reports). > > Ulrich > > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Monday, July 21, 2014 3:16 PM > To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org > Subject: Transparent agents (was Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt) > > Ok, let's see if it's possible to completely turn off all DOIC behavior > in agents and still be able to reduce traffic to a server that sends a > host overload report. > > Assume the following agent based deployment: > > +--+ > /--|s1| > +-+ +-+ / +--+ > |c|--|a|== ... > +-+ +-+ \ +--+ > \--|sn| > +--+ > > Assume that there is a large number of servers, say 50. > > Now, assume that the Diameter application in question exclusively uses > realm-routed requests - 100% of requests sent by the client do NOT have > a destination-host AVP. > > Now assume that server s1 sends an host type overload report requesting > a reduction of 20% using the loss algorithm. > > Also assume that the unused capacity in servers s2 through s50 is > sufficient to handle the traffic that would have been sent to s1. As > such, there is no reason to throttle any requests. > > There are no host routed requests for this application and the client > does not have a direct transport connection to server s1. The only > option a client has is to hand the request off to the agent for routing. > > The proposal in the agent cases draft is that the agent diverts 20% of > the realm routed requests that would have been sent to server s1 to > servers s2 through s50. > > If DOIC behavior is turned off in the agent then how will the traffic > routed to s1 be reduced? > > Steve > > On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote: >> +1 for the following aspect. >> >>>>> Agents must take an active role in even the most basic case for >>>>> overload handling to work, so they cannot be transparent. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not support DOIC are transparent. Agents that support DOIC in most cases behave like non supporting agents. >>> I am towards Ulrich's view here. Even for an agent that understands DOIC it is up to the local policy whether it is transparent or takes an active role. >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >> Sent: Monday, July 21, 2014 12:26 AM >> To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org >> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >> >> Some comments inline.. >> >> 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >>> Steve, >>> please see my response inline. >>> >>> Regards >>> Ulrich >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>> Donovan >>> Sent: Tuesday, July 15, 2014 3:53 PM >>> To: dime@ietf.org >>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>> >>> Ulrich, >>> >>> Thanks for the comments. Please see my responses inline. >>> >>> Regards, >>> >>> Steve >>> On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>> Hi Steve, >>>> here are my comments. >>>> They focus on new text you introduced. I agree that restructuring may require new text, however, I believe that with the new text a new concepts is introduced which macerates the agreed end-to-end concept and allows all DOIC agents on the path to do what they wants, so that we end up in a hop-by-hop concept. >>> SRD> We have never had an agreement on end-to-end versus hop-by-hop >>> SRD> and >>> I believe that we will end up with a hybrid of the two. We have open >>> issues on agent behavior that Ben and I are attempting to address with >>> the agent cases draft. >>> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop approach of the roach draft was reason not to proceed with that draft. >>> >>> SRD> That said, this type of restructuring of the document is likely >>> SRD> to >>> put agreed to behavior in a new light. If there are cases where I >>> have implied changes to agreed to normative behavior, or if the >>> informative text is not accurate, then these things need to be corrected. >>>> 1. clause 2.3, second paragraph: >>>> Should read: "Reacting nodes indicate support for DOIC by including the OC-Supported-Features AVP into all request messages originated or relayed by the Reacting node." >>> SRD> You mean clause 3.2. >>> [Wiehe, Ulrich (NSN - DE/Munich)] yes >>> I agree with the change. >>>> 2. clause 2.3, 3rd paragraph, 1st sentence: >>>> OC-xxx AVPs must not be included in an answer message when the corresponding request did not contain an OC-S-F AVP. >>> SRD> Agreed. >>>> 3. clause 3.3, 7th paragraph: >>>> Should read "The reporting node only includes an indication of support for one overload abatement algorithm. This is the algorithm that the reporting node intends to use should it enter an overload condition or requests to use while it actually is in an overload condition. Reacting nodes can use the indicated overload abatement algorithm to prepare for possible overload reports and must use the indicated overload abatement algorithm if traffic reduction is actually requested." >>> SRD. OK. >>>> 4. clause 3.3, 10th paragraph: >>>> The 1st sentence is misleading. In the general case, agents on the path between reacting node and reporting node are transparent. I agree that there are exceptions to the general case where an agent on the path is not transparent, but then the agent IS the reporting node (reporting to the sender of the request) and it also IS the reacting node (reacting on reports received from the upstream reporting node). >>>> The first 3 words of the second sentence "in this case" need clarification: "In the case where an agent takes the role of a reporting node (reporting to the downstream reacting node) and at the same time takes the role of a reacting node (reacting on reports received from an upstream reporting node)". >>>> Last sentence: Its not an update but a replacement. The two DOIC associations are handled independently. >>> SRD> I don't know what you mean when you say an agent is transparent. >>> Agents must take an active role in even the most basic case for >>> overload handling to work, so they cannot be transparent. >>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not support DOIC are transparent. Agents that support DOIC in most cases behave like non supporting agents. >> I am towards Ulrich's view here. Even for an agent that understands DOIC it is up to the local policy whether it is transparent or takes an active role. >> >>>> 5. clause 3.3, last paragraph: >>>> General rules shall be followed for each of the two associations separately. The content of the OC-S-F AVP sent by the agent upstream should reflect what the agent is able and willing to support (as always). >>> SRD> What two associations? Is there one association (end-to-end) or >>> SRD> is >>> the an association on both sides of the agent (hop-by-hop)? Or is >>> there an association that involves three entities, the reporting node, >>> an agent reacting node for realm-routed requests and a >>> transaction-client reporting node for handling host-routed requests? >>> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, There is >>> one association between C and A, and one association between A and S. Both associations are "end-to-end" as there may be transparent (supporting or non-supporting) agents in the middle. >>>> 6. clause 3.4, 2nd paragraph: >>>> Should read: "The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP includes the type of report, a sequence number, the length of time that the report is valid and abatement algorithm specific AVPs." >>> SRD> The sequence number is being used as an overload report ID. I can >>> make the change but I don't see it as necessary. >>> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. >> OK to do the change. >> >>>> 7. clause 3.4, 4th paragraph, 2nd sentence: >>>> I cannot understand this sentence. Probably only simple typos but I don't know. >>> SRD> Yes, a typo (this instead of the) and awkward wording. How about >>> "This applies to requests that contain the Destination-Host AVP with a >>> DiameterIdentity that matches the overload report. >>> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that contain a DiameterIdentity in the Destination-Host AVP that matches the reporting host's DiameterIdentity" >> I would be inclined to keep the text Steve proposed. But both are ok actually. >> >>>> 8. clause 3.4, 4th paragraph last 2 sentences: >>>> I don't understand and probably do not agree. >>> SRD> See above. >>>> 9. clause 3.5, 3rd paragraph, last word: >>>> Should read "communicated" >>> SRD> Agreed. >>>> 10. clause 3.5, 4th paragraph, 1st sentence: >>>> I don't understand. I can understand: "Reporting nodes use the OC-OLR AVP to communicate overload occurances towards reacting nodes." >>> SRD> Who else would reports be sent to? >>> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement algorithm but the reporting node that uses the OC-OLR AVP to communicate overload occurances. >> Agree. >> >>>> 11. clause 4.1, 3rd paragraph, last 4 words: >>>> may be misleading. A DOIC supporting agent sitting between DOIC supporting client and DOIC supporting Server is transparent with regard to DOIC. This agent does not indicate DOIC support. >>> SRD> I disagree. >>> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Should be: ...This agent does not indicate its DOIC support, rather it transparently forwards the client's DOIC support. >> Agree with Ulrich on the intent of agent behavior but not with the proposed text change. >> >>>> 12. clause 4.1, 4th paragraph, 2nd sentence: >>>> Should read:"If a request message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent inserts the AVP." >>> SRD> That is what it already says. >>> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... >> OC-Supported-Features can be in both request and answer, thus "If a message" in that sense is correct. >> >>>> 13. clause 4.1, last sentence: >>>> Should read "If the message already has the AVP then the agent either leaves it unchanged in the relayed message or replaces it to reflect the features the agent is able and willing to support." Clarification is needed to say that strict rules must be followed by the agent to select the correct option. These rules take into account whether the request is host-routed or relam-routed and whether the agent is configured to select the server for realm-routed requests. >>> SRD> This is a topic on agent behavior that is addressed in the agent >>> cases draft. I'll leave the discussion for what the wording should be >>> to the discussion on that draft. >>>> 14. clause 4.1.2, 2nd paragraph: >>>> Should read: "Based on the content of the OC-Supported-Features AVP in the request message, the reporting node knows what overload control functionality is supported by the reacting node. The reporting node then acts accordingly for the subsequent answer messages it initiates for the transaction." >>> SRD> It would be easier if you didn't make it difficult to understand >>> the change you are proposing. I think you are proposing changing >>> node(s) to node. I don't agree but that will be addressed as part of >>> the agent cases discussion. >>> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing two sentences? The proposal is to insert "is" between "functionality" and "supported", to add "the" between "by" and "reacting", to replace "node(s)" with "node", and to insert "for the transaction" after "initiates". >> Agree with the proposed change. >> >>>> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >>>> Should read: "message's" >>> SRD> I'm assuming you mean section 4.1.2. >>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, and 19. >>> I agree to the change. >>>> 16. clause 4.1, 6th paragraph: >>>> This should be left to the (future) specification that introduces other DOIC features. >>>> >>>> 17. clause 4.1, 7th paragraph, last 6 words: >>>> should be based on requiements set by the (future) specification that >>>> introduces other DOIC features >>> SRD> Again, clause 4.1.2 -- I don't understand the issue when these >>> SRD> two >>> paragraphs are taken together. >>>> 18. clause 4.1, 8th paragraph, last sentence: >>>> Should read: "Lack of the OC-Supported-Features AVP in the request message indicates that there is no downstream reacting node for the transaction." >>> SRD> I think you mean clause 4.1.2. I don't see the need for the change. >>> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not correct. It should either read: "Lack of the OC-Supported-Feature AVP in the request message indicates to the reporting node that there is no reacting node for the transaction" or as proposed above. >> I don't see a reason for the change. Original text seem correct to me. >> >>>> 19. clause 4.1, last sentence: >>>> Should read: "An agent MAY replace the OC-Supported-Features AVP carried in answer messages." This replacement must follow general rules. Its not so that the agent may do what ever it wants to. The decision must be based on whether or not the agent has replaced the OC-S-F in the corresponding request. >>> SRD> What is the difference between modify and replace? I am ok with >>> removing this statement until we have the agent behavior discussion. >>> I thought I had taken the agent specific statements out of this version. >>> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with identical values. You remove what has been received in and insert your own stuff. >> Agent (proxy) can always do that i.e. modify the APV contents. Obviously if an agent tampers the OC-Supported-Features AVP it needs to know what it is doing. In general agree with the clarification but not with the proposed text. >> >> - Jouni >> >>>> 20. clause 5.2, 1st sentence: >>>> Should read: "A reporting node using the loss algorithm must use the OC-Reduction-Percentage AVP (Section 6.7) to indicated the desired percentage of traffic reduction." >>> SRD> Agreed. >>>> 21. clause 5.2, last sentence: >>>> Should read: "Editor's note: The above duplicates what is in the OC-Reduction-Percentage AVP section and can probably be removed." >>> SRD> Yes, bad wording. The note will be removed, bad wording and all, >>> once there is a discussion on if this is redundant. >>>> 22. clause 5.4, 6th paragraph: >>>> Should read: "If the reacting node does not receive a an OLR in the answer that corresponds to the probe request messages sent to the formally overloaded node then the reacting node should slowly increase the rate of traffic sent to the overloaded node." >>> SRD Agreed, this is more clear. >>>> Best regards >>>> Ulrich >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>> Donovan >>>> Sent: Saturday, July 05, 2014 9:42 PM >>>> To: dime@ietf.org >>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>> >>>> All, >>>> >>>> This version of the DOIC draft is a restructuring of previously >>>> agreed to content. >>>> >>>> The master plan for the restructuring is in Appendix C. This >>>> outlines where material from -02 was moved in -03. >>>> >>>> For those interested, the work was done in steps, with a snapshot for >>>> each step available here: >>>> >>>> https://github.com/jounikor/draft-docdt-dime-ovli >>>> >>>> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >>>> >>>> where nn indicates the subversion and "text" indicates the focus for >>>> that subversion. >>>> >>>> The next step will be to resolve open issues already identified and >>>> those yet those yet to be identified. >>>> >>>> Regards, >>>> >>>> Steve >>>> >>>> >>>> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>> This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. >>>>> >>>>> Title : Diameter Overload Indication Conveyance >>>>> Authors : Jouni Korhonen >>>>> Steve Donovan >>>>> Ben Campbell >>>>> Lionel Morand >>>>> Filename : draft-ietf-dime-ovli-03.txt >>>>> Pages : 48 >>>>> Date : 2014-07-03 >>>>> >>>>> Abstract: >>>>> This specification documents a Diameter Overload Control (DOC) base >>>>> solution and the dissemination of the overload report information. >>>>> >>>>> Requirements >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-03 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > From nobody Mon Jul 21 07:43:01 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C981A009E for ; Mon, 21 Jul 2014 07:42:58 -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, SPF_NEUTRAL=0.779] autolearn=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 VAHHBvOr5qpz for ; Mon, 21 Jul 2014 07:42:56 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 D14901A00A7 for ; Mon, 21 Jul 2014 07:42:54 -0700 (PDT) Received: from dhcp-a698.meeting.ietf.org ([31.133.166.152]:52147) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X9Enc-0006WC-Fm; Mon, 21 Jul 2014 07:42:53 -0700 Message-ID: <53CD26E4.2090703@usdonovans.com> Date: Mon, 21 Jul 2014 10:42:44 -0400 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "Nirav Salot (nsalot)" , Jouni Korhonen , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <13924_1405952912_53CD2390_13924_94_1_6B7134B31289DC4FAF731D844122B36E669F04@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <13924_1405952912_53CD2390_13924_94_1_6B7134B31289DC4FAF731D844122B36E669F04@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gIaIUJK0vz84e9tePj8MdFtjM-s Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:42:58 -0000 Lionel, Only if the thing called a dynamic weight/load balancer understands Diameter. The point I'm trying to make is that the Diameter node that has a direct connection to an overloaded server, be that a client, an agent, a proxy or a Diameter load balancer, MUST take part in abatement of traffic being routed to an overloaded server. This is not optional, as pointed out in the other message I sent this morning. Steve On 7/21/14, 10:28 AM, lionel.morand@orange.com wrote: > Assuming that any server can process any request at any time, I would say that the scenario below is a simple illustration for a dynamic weight/load balancer, right? > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot) > Envoyé : lundi 21 juillet 2014 15:36 > À : Steve Donovan; Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org > Objet : Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) > > Steve, > > In the example below, you are assuming that "any server can serve any subscriber session". > However, if that is not the case then the agent has no choice but to route the request to the appropriate server, irrespective of its used/unused capacity. > > The point being, "the DOIC supporting agent must take an active role" is not accurate/correct. > It is based on other factors and finally on local policy. > > Regards, > Nirav. > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Monday, July 21, 2014 6:46 PM > To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org > Subject: Transparent agents (was Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt) > > Ok, let's see if it's possible to completely turn off all DOIC behavior in agents and still be able to reduce traffic to a server that sends a host overload report. > > Assume the following agent based deployment: > > +--+ > /--|s1| > +-+ +-+ / +--+ > |c|--|a|== ... > +-+ +-+ \ +--+ > \--|sn| > +--+ > > Assume that there is a large number of servers, say 50. > > Now, assume that the Diameter application in question exclusively uses realm-routed requests - 100% of requests sent by the client do NOT have a destination-host AVP. > > Now assume that server s1 sends an host type overload report requesting a reduction of 20% using the loss algorithm. > > Also assume that the unused capacity in servers s2 through s50 is sufficient to handle the traffic that would have been sent to s1. As such, there is no reason to throttle any requests. > > There are no host routed requests for this application and the client does not have a direct transport connection to server s1. The only option a client has is to hand the request off to the agent for routing. > > The proposal in the agent cases draft is that the agent diverts 20% of the realm routed requests that would have been sent to server s1 to servers s2 through s50. > > If DOIC behavior is turned off in the agent then how will the traffic routed to s1 be reduced? > > Steve > > On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote: >> +1 for the following aspect. >> >>>>> Agents must take an active role in even the most basic case for >>>>> overload handling to work, so they cannot be transparent. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not support DOIC are transparent. Agents that support DOIC in most cases behave like non supporting agents. >>> I am towards Ulrich's view here. Even for an agent that understands DOIC it is up to the local policy whether it is transparent or takes an active role. >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >> Sent: Monday, July 21, 2014 12:26 AM >> To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org >> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >> >> Some comments inline.. >> >> 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >>> Steve, >>> please see my response inline. >>> >>> Regards >>> Ulrich >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>> Donovan >>> Sent: Tuesday, July 15, 2014 3:53 PM >>> To: dime@ietf.org >>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>> >>> Ulrich, >>> >>> Thanks for the comments. Please see my responses inline. >>> >>> Regards, >>> >>> Steve >>> On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>> Hi Steve, >>>> here are my comments. >>>> They focus on new text you introduced. I agree that restructuring may require new text, however, I believe that with the new text a new concepts is introduced which macerates the agreed end-to-end concept and allows all DOIC agents on the path to do what they wants, so that we end up in a hop-by-hop concept. >>> SRD> We have never had an agreement on end-to-end versus hop-by-hop >>> SRD> and >>> I believe that we will end up with a hybrid of the two. We have open >>> issues on agent behavior that Ben and I are attempting to address >>> with the agent cases draft. >>> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop approach of the roach draft was reason not to proceed with that draft. >>> >>> SRD> That said, this type of restructuring of the document is likely >>> SRD> to >>> put agreed to behavior in a new light. If there are cases where I >>> have implied changes to agreed to normative behavior, or if the >>> informative text is not accurate, then these things need to be corrected. >>>> 1. clause 2.3, second paragraph: >>>> Should read: "Reacting nodes indicate support for DOIC by including the OC-Supported-Features AVP into all request messages originated or relayed by the Reacting node." >>> SRD> You mean clause 3.2. >>> [Wiehe, Ulrich (NSN - DE/Munich)] yes >>> I agree with the change. >>>> 2. clause 2.3, 3rd paragraph, 1st sentence: >>>> OC-xxx AVPs must not be included in an answer message when the corresponding request did not contain an OC-S-F AVP. >>> SRD> Agreed. >>>> 3. clause 3.3, 7th paragraph: >>>> Should read "The reporting node only includes an indication of support for one overload abatement algorithm. This is the algorithm that the reporting node intends to use should it enter an overload condition or requests to use while it actually is in an overload condition. Reacting nodes can use the indicated overload abatement algorithm to prepare for possible overload reports and must use the indicated overload abatement algorithm if traffic reduction is actually requested." >>> SRD. OK. >>>> 4. clause 3.3, 10th paragraph: >>>> The 1st sentence is misleading. In the general case, agents on the path between reacting node and reporting node are transparent. I agree that there are exceptions to the general case where an agent on the path is not transparent, but then the agent IS the reporting node (reporting to the sender of the request) and it also IS the reacting node (reacting on reports received from the upstream reporting node). >>>> The first 3 words of the second sentence "in this case" need clarification: "In the case where an agent takes the role of a reporting node (reporting to the downstream reacting node) and at the same time takes the role of a reacting node (reacting on reports received from an upstream reporting node)". >>>> Last sentence: Its not an update but a replacement. The two DOIC associations are handled independently. >>> SRD> I don't know what you mean when you say an agent is transparent. >>> Agents must take an active role in even the most basic case for >>> overload handling to work, so they cannot be transparent. >>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not support DOIC are transparent. Agents that support DOIC in most cases behave like non supporting agents. >> I am towards Ulrich's view here. Even for an agent that understands DOIC it is up to the local policy whether it is transparent or takes an active role. >> >>>> 5. clause 3.3, last paragraph: >>>> General rules shall be followed for each of the two associations separately. The content of the OC-S-F AVP sent by the agent upstream should reflect what the agent is able and willing to support (as always). >>> SRD> What two associations? Is there one association (end-to-end) or >>> SRD> is >>> the an association on both sides of the agent (hop-by-hop)? Or is >>> there an association that involves three entities, the reporting >>> node, an agent reacting node for realm-routed requests and a >>> transaction-client reporting node for handling host-routed requests? >>> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, There >>> is one association between C and A, and one association between A and S. Both associations are "end-to-end" as there may be transparent (supporting or non-supporting) agents in the middle. >>>> 6. clause 3.4, 2nd paragraph: >>>> Should read: "The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP includes the type of report, a sequence number, the length of time that the report is valid and abatement algorithm specific AVPs." >>> SRD> The sequence number is being used as an overload report ID. I >>> SRD> can >>> make the change but I don't see it as necessary. >>> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. >> OK to do the change. >> >>>> 7. clause 3.4, 4th paragraph, 2nd sentence: >>>> I cannot understand this sentence. Probably only simple typos but I don't know. >>> SRD> Yes, a typo (this instead of the) and awkward wording. How >>> SRD> about >>> "This applies to requests that contain the Destination-Host AVP with >>> a DiameterIdentity that matches the overload report. >>> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that contain a DiameterIdentity in the Destination-Host AVP that matches the reporting host's DiameterIdentity" >> I would be inclined to keep the text Steve proposed. But both are ok actually. >> >>>> 8. clause 3.4, 4th paragraph last 2 sentences: >>>> I don't understand and probably do not agree. >>> SRD> See above. >>>> 9. clause 3.5, 3rd paragraph, last word: >>>> Should read "communicated" >>> SRD> Agreed. >>>> 10. clause 3.5, 4th paragraph, 1st sentence: >>>> I don't understand. I can understand: "Reporting nodes use the OC-OLR AVP to communicate overload occurances towards reacting nodes." >>> SRD> Who else would reports be sent to? >>> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement algorithm but the reporting node that uses the OC-OLR AVP to communicate overload occurances. >> Agree. >> >>>> 11. clause 4.1, 3rd paragraph, last 4 words: >>>> may be misleading. A DOIC supporting agent sitting between DOIC supporting client and DOIC supporting Server is transparent with regard to DOIC. This agent does not indicate DOIC support. >>> SRD> I disagree. >>> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Should be: ...This agent does not indicate its DOIC support, rather it transparently forwards the client's DOIC support. >> Agree with Ulrich on the intent of agent behavior but not with the proposed text change. >> >>>> 12. clause 4.1, 4th paragraph, 2nd sentence: >>>> Should read:"If a request message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent inserts the AVP." >>> SRD> That is what it already says. >>> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... >> OC-Supported-Features can be in both request and answer, thus "If a message" in that sense is correct. >> >>>> 13. clause 4.1, last sentence: >>>> Should read "If the message already has the AVP then the agent either leaves it unchanged in the relayed message or replaces it to reflect the features the agent is able and willing to support." Clarification is needed to say that strict rules must be followed by the agent to select the correct option. These rules take into account whether the request is host-routed or relam-routed and whether the agent is configured to select the server for realm-routed requests. >>> SRD> This is a topic on agent behavior that is addressed in the agent >>> cases draft. I'll leave the discussion for what the wording should >>> be to the discussion on that draft. >>>> 14. clause 4.1.2, 2nd paragraph: >>>> Should read: "Based on the content of the OC-Supported-Features AVP in the request message, the reporting node knows what overload control functionality is supported by the reacting node. The reporting node then acts accordingly for the subsequent answer messages it initiates for the transaction." >>> SRD> It would be easier if you didn't make it difficult to understand >>> the change you are proposing. I think you are proposing changing >>> node(s) to node. I don't agree but that will be addressed as part of >>> the agent cases discussion. >>> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing two sentences? The proposal is to insert "is" between "functionality" and "supported", to add "the" between "by" and "reacting", to replace "node(s)" with "node", and to insert "for the transaction" after "initiates". >> Agree with the proposed change. >> >>>> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >>>> Should read: "message's" >>> SRD> I'm assuming you mean section 4.1.2. >>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, and 19. >>> I agree to the change. >>>> 16. clause 4.1, 6th paragraph: >>>> This should be left to the (future) specification that introduces other DOIC features. >>>> >>>> 17. clause 4.1, 7th paragraph, last 6 words: >>>> should be based on requiements set by the (future) specification >>>> that introduces other DOIC features >>> SRD> Again, clause 4.1.2 -- I don't understand the issue when these >>> SRD> two >>> paragraphs are taken together. >>>> 18. clause 4.1, 8th paragraph, last sentence: >>>> Should read: "Lack of the OC-Supported-Features AVP in the request message indicates that there is no downstream reacting node for the transaction." >>> SRD> I think you mean clause 4.1.2. I don't see the need for the change. >>> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not correct. It should either read: "Lack of the OC-Supported-Feature AVP in the request message indicates to the reporting node that there is no reacting node for the transaction" or as proposed above. >> I don't see a reason for the change. Original text seem correct to me. >> >>>> 19. clause 4.1, last sentence: >>>> Should read: "An agent MAY replace the OC-Supported-Features AVP carried in answer messages." This replacement must follow general rules. Its not so that the agent may do what ever it wants to. The decision must be based on whether or not the agent has replaced the OC-S-F in the corresponding request. >>> SRD> What is the difference between modify and replace? I am ok with >>> removing this statement until we have the agent behavior discussion. >>> I thought I had taken the agent specific statements out of this version. >>> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with identical values. You remove what has been received in and insert your own stuff. >> Agent (proxy) can always do that i.e. modify the APV contents. Obviously if an agent tampers the OC-Supported-Features AVP it needs to know what it is doing. In general agree with the clarification but not with the proposed text. >> >> - Jouni >> >>>> 20. clause 5.2, 1st sentence: >>>> Should read: "A reporting node using the loss algorithm must use the OC-Reduction-Percentage AVP (Section 6.7) to indicated the desired percentage of traffic reduction." >>> SRD> Agreed. >>>> 21. clause 5.2, last sentence: >>>> Should read: "Editor's note: The above duplicates what is in the OC-Reduction-Percentage AVP section and can probably be removed." >>> SRD> Yes, bad wording. The note will be removed, bad wording and >>> SRD> all, >>> once there is a discussion on if this is redundant. >>>> 22. clause 5.4, 6th paragraph: >>>> Should read: "If the reacting node does not receive a an OLR in the answer that corresponds to the probe request messages sent to the formally overloaded node then the reacting node should slowly increase the rate of traffic sent to the overloaded node." >>> SRD Agreed, this is more clear. >>>> Best regards >>>> Ulrich >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>> Donovan >>>> Sent: Saturday, July 05, 2014 9:42 PM >>>> To: dime@ietf.org >>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>> >>>> All, >>>> >>>> This version of the DOIC draft is a restructuring of previously >>>> agreed to content. >>>> >>>> The master plan for the restructuring is in Appendix C. This >>>> outlines where material from -02 was moved in -03. >>>> >>>> For those interested, the work was done in steps, with a snapshot >>>> for each step available here: >>>> >>>> https://github.com/jounikor/draft-docdt-dime-ovli >>>> >>>> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >>>> >>>> where nn indicates the subversion and "text" indicates the focus for >>>> that subversion. >>>> >>>> The next step will be to resolve open issues already identified and >>>> those yet those yet to be identified. >>>> >>>> Regards, >>>> >>>> Steve >>>> >>>> >>>> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>> This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. >>>>> >>>>> Title : Diameter Overload Indication Conveyance >>>>> Authors : Jouni Korhonen >>>>> Steve Donovan >>>>> Ben Campbell >>>>> Lionel Morand >>>>> Filename : draft-ietf-dime-ovli-03.txt >>>>> Pages : 48 >>>>> Date : 2014-07-03 >>>>> >>>>> Abstract: >>>>> This specification documents a Diameter Overload Control (DOC) base >>>>> solution and the dissemination of the overload report information. >>>>> >>>>> Requirements >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-03 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > From nobody Mon Jul 21 07:44:34 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966F61A00FF for ; Mon, 21 Jul 2014 07:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 DcicHqysqcUq for ; Mon, 21 Jul 2014 07:44:26 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E040F1A00C3 for ; Mon, 21 Jul 2014 07:44:18 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 316F91B8FAB; Mon, 21 Jul 2014 16:44:17 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 12EF5180054; Mon, 21 Jul 2014 16:44:17 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Mon, 21 Jul 2014 16:44:16 +0200 From: To: Jouni Korhonen , "Hirschman, Brent B [CTO]" , "dime@ietf.org" Thread-Topic: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-00 - Use Cases Thread-Index: AQHPoFHcjeWHob/KCU6OTlCDB7Nt4Juqo9Tg Date: Mon, 21 Jul 2014 14:44:16 +0000 Message-ID: <17254_1405953857_53CD2741_17254_8004_1_6B7134B31289DC4FAF731D844122B36E66A03A@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <9203f8d398b14340b45617e019dc512e@PREWE13M04.ad.sprint.com> <53C56425.7040908@gmail.com> In-Reply-To: <53C56425.7040908@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.21.135120 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/imniipVgL4oir7nJp8V-8WTTs60 Cc: "Rajagopal, Arun \[CTO\]" , "Sershen, Dan J \[CTO\]" Subject: Re: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-00 - Use Cases X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:44:31 -0000 Agreed -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Envoy=E9=A0: mardi 15 juillet 2014 19:26 =C0=A0: Hirschman, Brent B [CTO]; dime@ietf.org Cc=A0: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO] Objet=A0: Re: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-= 00 - Use Cases Brent, I do agree with your conclusion that adding examples would be minimal=20 incremental addition to what RFC5777 already has. Also, IMHO use cases=20 for ECN should be rather well known. I see no reason to add text for=20 "topic 2". - Jouni 4/29/2014 5:35 PM, Hirschman, Brent B [CTO] kirjoitti: > At IETF 89 in London, during the discussion of the > draft-ietf-dime-congestion-flow-attributes-00.txt, Two areas were > requested to be investigated further. We will be addressing them in > separate email threads to keep the discussion focused on each topic. > This is Topic 2: > > Second, we were requested to investigate providing example use cases of > ECN. RFC5777 already provides a set of use cases for reporting and ECN > is just one of many such reporting parameters such as byte count. > Adding a paragraph of text such as the following may add some > information but the authors feel little incremental information is > needed because of the work already in RFC 5777. > > "Diameter nodes along the bearer path can implement filters to collect > accounting and policy control information based on these congestion > parameters similar to byte count information. These filters on flows and > overall node congestion for these AVPs can report a measure of quality > of byte counts to collection points in the network where decisions can > be made to mitigate or mediate any congestion conditions for accounting > or real time policy control. These AVPs provide supplemental information > as described in the use cases discussed in RFC5777." > > Thus, the authors are proposing no modification to the working group > draft at this time. Comments are welcome. > > */Brent Hirschman/* > > Tech Dev Strategist III > > Sprint Corporation > > 6220 Sprint Parkway > > Overland Park, KS 66251// > > Office - 913-762-6736 > > Mobile - 913-593-6221 > > > ------------------------------------------------------------------------ > > This e-mail may contain Sprint proprietary information intended for the > sole use of the recipient(s). Any use by others is prohibited. If you > are not the intended recipient, please contact the sender and delete all > copies of the message. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Jul 21 07:53:33 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBE51A0039 for ; Mon, 21 Jul 2014 07:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Jxo2X5GmhWjU for ; Mon, 21 Jul 2014 07:53:28 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 921E51A00A9 for ; Mon, 21 Jul 2014 07:53:27 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w62so7727632wes.15 for ; Mon, 21 Jul 2014 07:53:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=QuDbpllQPuUQebNaXqIoRCcieXQ2fXHQkSOihhie+gk=; b=KfCUZ8vDvSDqg3jPPf78uBXwuhs1EgzisaTS3u5b2TfVZQVGuNuJbJCeAEvuuMyqBq onH97QdO4BOlu1j5yFFNp0rgv/+Xl1WhftQGPm286w+2l4V4ufhW0ZZXQcpf+3Z/xQhO 4x2ehS5GtUqyQldmOkEsmCRI0iqK4LE635bRg2OVpLrYN/a0MuyolBKbFF63yGAqTjyH /ROKLNCnz6hTF4z/6ALvpK0qNk1S84t3PcXk0ugJJRFC7T5QVFBydOa4gITDrR/Qfq6A bO/6qvxGxWzEvw75sFERlVKPAlKIUA8Lq5/SqWDHr6Rn6C/BOkiSm/ZESRnFHCemE1YS ejxQ== X-Received: by 10.180.39.73 with SMTP id n9mr5122376wik.70.1405954405631; Mon, 21 Jul 2014 07:53:25 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:e84e:7a32:d5bb:8e18? ([2001:67c:370:176:e84e:7a32:d5bb:8e18]) by mx.google.com with ESMTPSA id mv3sm42724621wic.21.2014.07.21.07.53.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 07:53:25 -0700 (PDT) Message-ID: <53CD2962.6060403@gmail.com> Date: Mon, 21 Jul 2014 17:53:22 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steve Donovan , "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> In-Reply-To: <53CD23BD.8010906@usdonovans.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2cBwxKX_KVuylvdHbja6PaPMiHI Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:53:31 -0000 Steve, 7/21/2014 5:29 PM, Steve Donovan kirjoitti: > Ulrich, > > I am not arguing that all agents should take an active role in the > handling of all overload reports. What I am arguing is that there are > scenarios where an agent must take an active role in DOIC to ensure that > a requested reduction in traffic an be achieved. > > For DOIC to work a carrier cannot turn off all DOIC behavior in agents, > as suggested by Jouni. Why? If you have a hierarchy of agents I don't see a reason why some of those could be just "vanilla agents" or DOIC agents with functionality turned off. Not arguing such deployment makes sense but the protocol solution should be able to cope with that. - Jouni > > I agree that in your scenario below, a1 does not need to take an active > role in reducing traffic when c supports DOIC. a1 should take an active > role when c does not support DOIC. The problem is that a1 does not know > in advance whether c supports DOIC so it will need to inspect all > transactions for the presence of OC-S-F to determine if it needs to > handle overload reports for a non supporting client. > > Does that mean a1 is transparent if it inspects all requests and does > nothing in the case where there is c supports DOIC? > > Does transparent mean that there is no observable difference in the DOIC > AVPs that pass through the agent or does it mean that there is no > observable difference in how transactions are handled by the DOIC agent? > > I'm guessing that we have multiple assumptions on what transparent means > and, if we are going to continue saying agents should be transparent > then we need a definition of transparent. > > I think for this use case, we need the following normative statements in > the draft for handling of abatement of realm-routed requests? I think > this is general behavior and should go in the section on handling of > overload reports. > > "DOIC nodes with a direct transport connection to a reporting node that > has an active overload report must handle abatement of realm-routed > requests. The preferred method for handling abatement of realm-routed > requests is diversion, where the node with the direct transport > connection routes the request to an alternative server that is able to > handle the request. If there is no alternative server with the needed > capacity to handle the request then the DOIC node must/should throttle > the necessary requests to meet the requested reduction in traffic." > > If we can agree on this then we can move on to the next agent based use > case. > > Regards, > > Steve > > On 7/21/14, 9:47 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Steve, >> >> The example you show is absolutely valid and 100% inline with A) to F) >> - (assuming that all servers can serve any request). >> However, there are other scenarios like: >> >> >> +--+ >> /--|s1| >> +-+ +--+ +--+ / +--+ >> |c|--- |a1|--|a2|== ... >> +-+ +--+ +--+ \ +--+ >> \--|sn| >> +--+ >> >> Here I think a1 should be transparent even when DOICable. >> a1 does not take the role of a reacting node since c supports DOIC. >> a1 does not perform server selection and therefore does not take the >> role of a reporting node (for realm-reports). >> >> Ulrich >> >> >> -----Original Message----- >> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Monday, July 21, 2014 3:16 PM >> To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - >> DE/Munich); dime@ietf.org >> Subject: Transparent agents (was Re: [Dime] I-D Action: >> draft-ietf-dime-ovli-03.txt) >> >> Ok, let's see if it's possible to completely turn off all DOIC behavior >> in agents and still be able to reduce traffic to a server that sends a >> host overload report. >> >> Assume the following agent based deployment: >> >> +--+ >> /--|s1| >> +-+ +-+ / +--+ >> |c|--|a|== ... >> +-+ +-+ \ +--+ >> \--|sn| >> +--+ >> >> Assume that there is a large number of servers, say 50. >> >> Now, assume that the Diameter application in question exclusively uses >> realm-routed requests - 100% of requests sent by the client do NOT have >> a destination-host AVP. >> >> Now assume that server s1 sends an host type overload report requesting >> a reduction of 20% using the loss algorithm. >> >> Also assume that the unused capacity in servers s2 through s50 is >> sufficient to handle the traffic that would have been sent to s1. As >> such, there is no reason to throttle any requests. >> >> There are no host routed requests for this application and the client >> does not have a direct transport connection to server s1. The only >> option a client has is to hand the request off to the agent for routing. >> >> The proposal in the agent cases draft is that the agent diverts 20% of >> the realm routed requests that would have been sent to server s1 to >> servers s2 through s50. >> >> If DOIC behavior is turned off in the agent then how will the traffic >> routed to s1 be reduced? >> >> Steve >> >> On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote: >>> +1 for the following aspect. >>> >>>>>> Agents must take an active role in even the most basic case for >>>>>> overload handling to work, so they cannot be transparent. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do >>>>> not support DOIC are transparent. Agents that support DOIC in most >>>>> cases behave like non supporting agents. >>>> I am towards Ulrich's view here. Even for an agent that understands >>>> DOIC it is up to the local policy whether it is transparent or takes >>>> an active role. >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >>> Sent: Monday, July 21, 2014 12:26 AM >>> To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org >>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>> >>> Some comments inline.. >>> >>> 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >>>> Steve, >>>> please see my response inline. >>>> >>>> Regards >>>> Ulrich >>>> >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>> Donovan >>>> Sent: Tuesday, July 15, 2014 3:53 PM >>>> To: dime@ietf.org >>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>> >>>> Ulrich, >>>> >>>> Thanks for the comments. Please see my responses inline. >>>> >>>> Regards, >>>> >>>> Steve >>>> On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>>> Hi Steve, >>>>> here are my comments. >>>>> They focus on new text you introduced. I agree that restructuring >>>>> may require new text, however, I believe that with the new text a >>>>> new concepts is introduced which macerates the agreed end-to-end >>>>> concept and allows all DOIC agents on the path to do what they >>>>> wants, so that we end up in a hop-by-hop concept. >>>> SRD> We have never had an agreement on end-to-end versus hop-by-hop >>>> SRD> and >>>> I believe that we will end up with a hybrid of the two. We have open >>>> issues on agent behavior that Ben and I are attempting to address with >>>> the agent cases draft. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop >>>> approach of the roach draft was reason not to proceed with that draft. >>>> >>>> SRD> That said, this type of restructuring of the document is likely >>>> SRD> to >>>> put agreed to behavior in a new light. If there are cases where I >>>> have implied changes to agreed to normative behavior, or if the >>>> informative text is not accurate, then these things need to be >>>> corrected. >>>>> 1. clause 2.3, second paragraph: >>>>> Should read: "Reacting nodes indicate support for DOIC by including >>>>> the OC-Supported-Features AVP into all request messages originated >>>>> or relayed by the Reacting node." >>>> SRD> You mean clause 3.2. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes >>>> I agree with the change. >>>>> 2. clause 2.3, 3rd paragraph, 1st sentence: >>>>> OC-xxx AVPs must not be included in an answer message when the >>>>> corresponding request did not contain an OC-S-F AVP. >>>> SRD> Agreed. >>>>> 3. clause 3.3, 7th paragraph: >>>>> Should read "The reporting node only includes an indication of >>>>> support for one overload abatement algorithm. This is the >>>>> algorithm that the reporting node intends to use should it enter an >>>>> overload condition or requests to use while it actually is in an >>>>> overload condition. Reacting nodes can use the indicated overload >>>>> abatement algorithm to prepare for possible overload reports and >>>>> must use the indicated overload abatement algorithm if traffic >>>>> reduction is actually requested." >>>> SRD. OK. >>>>> 4. clause 3.3, 10th paragraph: >>>>> The 1st sentence is misleading. In the general case, agents on the >>>>> path between reacting node and reporting node are transparent. I >>>>> agree that there are exceptions to the general case where an agent >>>>> on the path is not transparent, but then the agent IS the reporting >>>>> node (reporting to the sender of the request) and it also IS the >>>>> reacting node (reacting on reports received from the upstream >>>>> reporting node). >>>>> The first 3 words of the second sentence "in this case" need >>>>> clarification: "In the case where an agent takes the role of a >>>>> reporting node (reporting to the downstream reacting node) and at >>>>> the same time takes the role of a reacting node (reacting on >>>>> reports received from an upstream reporting node)". >>>>> Last sentence: Its not an update but a replacement. The two DOIC >>>>> associations are handled independently. >>>> SRD> I don't know what you mean when you say an agent is transparent. >>>> Agents must take an active role in even the most basic case for >>>> overload handling to work, so they cannot be transparent. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not >>>> support DOIC are transparent. Agents that support DOIC in most cases >>>> behave like non supporting agents. >>> I am towards Ulrich's view here. Even for an agent that understands >>> DOIC it is up to the local policy whether it is transparent or takes >>> an active role. >>> >>>>> 5. clause 3.3, last paragraph: >>>>> General rules shall be followed for each of the two associations >>>>> separately. The content of the OC-S-F AVP sent by the agent >>>>> upstream should reflect what the agent is able and willing to >>>>> support (as always). >>>> SRD> What two associations? Is there one association (end-to-end) or >>>> SRD> is >>>> the an association on both sides of the agent (hop-by-hop)? Or is >>>> there an association that involves three entities, the reporting node, >>>> an agent reacting node for realm-routed requests and a >>>> transaction-client reporting node for handling host-routed requests? >>>> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, There is >>>> one association between C and A, and one association between A and >>>> S. Both associations are "end-to-end" as there may be transparent >>>> (supporting or non-supporting) agents in the middle. >>>>> 6. clause 3.4, 2nd paragraph: >>>>> Should read: "The OC-OLR AVP is referred to as an overload report. >>>>> The OC-OLR AVP includes the type of report, a sequence number, the >>>>> length of time that the report is valid and abatement algorithm >>>>> specific AVPs." >>>> SRD> The sequence number is being used as an overload report ID. I can >>>> make the change but I don't see it as necessary. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. >>> OK to do the change. >>> >>>>> 7. clause 3.4, 4th paragraph, 2nd sentence: >>>>> I cannot understand this sentence. Probably only simple typos but I >>>>> don't know. >>>> SRD> Yes, a typo (this instead of the) and awkward wording. How about >>>> "This applies to requests that contain the Destination-Host AVP with a >>>> DiameterIdentity that matches the overload report. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that >>>> contain a DiameterIdentity in the Destination-Host AVP that matches >>>> the reporting host's DiameterIdentity" >>> I would be inclined to keep the text Steve proposed. But both are ok >>> actually. >>> >>>>> 8. clause 3.4, 4th paragraph last 2 sentences: >>>>> I don't understand and probably do not agree. >>>> SRD> See above. >>>>> 9. clause 3.5, 3rd paragraph, last word: >>>>> Should read "communicated" >>>> SRD> Agreed. >>>>> 10. clause 3.5, 4th paragraph, 1st sentence: >>>>> I don't understand. I can understand: "Reporting nodes use the >>>>> OC-OLR AVP to communicate overload occurances towards reacting nodes." >>>> SRD> Who else would reports be sent to? >>>> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement >>>> algorithm but the reporting node that uses the OC-OLR AVP to >>>> communicate overload occurances. >>> Agree. >>> >>>>> 11. clause 4.1, 3rd paragraph, last 4 words: >>>>> may be misleading. A DOIC supporting agent sitting between DOIC >>>>> supporting client and DOIC supporting Server is transparent with >>>>> regard to DOIC. This agent does not indicate DOIC support. >>>> SRD> I disagree. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. >>>> Should be: ...This agent does not indicate its DOIC support, rather >>>> it transparently forwards the client's DOIC support. >>> Agree with Ulrich on the intent of agent behavior but not with the >>> proposed text change. >>> >>>>> 12. clause 4.1, 4th paragraph, 2nd sentence: >>>>> Should read:"If a request message handled by the DOIC agent does >>>>> not include the OC-Supported-Features AVP then the DOIC agent >>>>> inserts the AVP." >>>> SRD> That is what it already says. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... >>> OC-Supported-Features can be in both request and answer, thus "If a >>> message" in that sense is correct. >>> >>>>> 13. clause 4.1, last sentence: >>>>> Should read "If the message already has the AVP then the agent >>>>> either leaves it unchanged in the relayed message or replaces it to >>>>> reflect the features the agent is able and willing to support." >>>>> Clarification is needed to say that strict rules must be followed >>>>> by the agent to select the correct option. These rules take into >>>>> account whether the request is host-routed or relam-routed and >>>>> whether the agent is configured to select the server for >>>>> realm-routed requests. >>>> SRD> This is a topic on agent behavior that is addressed in the agent >>>> cases draft. I'll leave the discussion for what the wording should be >>>> to the discussion on that draft. >>>>> 14. clause 4.1.2, 2nd paragraph: >>>>> Should read: "Based on the content of the OC-Supported-Features AVP >>>>> in the request message, the reporting node knows what overload >>>>> control functionality is supported by the reacting node. The >>>>> reporting node then acts accordingly for the subsequent answer >>>>> messages it initiates for the transaction." >>>> SRD> It would be easier if you didn't make it difficult to understand >>>> the change you are proposing. I think you are proposing changing >>>> node(s) to node. I don't agree but that will be addressed as part of >>>> the agent cases discussion. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing >>>> two sentences? The proposal is to insert "is" between >>>> "functionality" and "supported", to add "the" between "by" and >>>> "reacting", to replace "node(s)" with "node", and to insert "for the >>>> transaction" after "initiates". >>> Agree with the proposed change. >>> >>>>> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >>>>> Should read: "message's" >>>> SRD> I'm assuming you mean section 4.1.2. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, >>>> and 19. >>>> I agree to the change. >>>>> 16. clause 4.1, 6th paragraph: >>>>> This should be left to the (future) specification that introduces >>>>> other DOIC features. >>>>> >>>>> 17. clause 4.1, 7th paragraph, last 6 words: >>>>> should be based on requiements set by the (future) specification that >>>>> introduces other DOIC features >>>> SRD> Again, clause 4.1.2 -- I don't understand the issue when these >>>> SRD> two >>>> paragraphs are taken together. >>>>> 18. clause 4.1, 8th paragraph, last sentence: >>>>> Should read: "Lack of the OC-Supported-Features AVP in the request >>>>> message indicates that there is no downstream reacting node for the >>>>> transaction." >>>> SRD> I think you mean clause 4.1.2. I don't see the need for the >>>> change. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not >>>> correct. It should either read: "Lack of the OC-Supported-Feature >>>> AVP in the request message indicates to the reporting node that >>>> there is no reacting node for the transaction" or as proposed above. >>> I don't see a reason for the change. Original text seem correct to me. >>> >>>>> 19. clause 4.1, last sentence: >>>>> Should read: "An agent MAY replace the OC-Supported-Features AVP >>>>> carried in answer messages." This replacement must follow general >>>>> rules. Its not so that the agent may do what ever it wants to. The >>>>> decision must be based on whether or not the agent has replaced the >>>>> OC-S-F in the corresponding request. >>>> SRD> What is the difference between modify and replace? I am ok with >>>> removing this statement until we have the agent behavior discussion. >>>> I thought I had taken the agent specific statements out of this >>>> version. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with >>>> identical values. You remove what has been received in and insert >>>> your own stuff. >>> Agent (proxy) can always do that i.e. modify the APV contents. >>> Obviously if an agent tampers the OC-Supported-Features AVP it needs >>> to know what it is doing. In general agree with the clarification but >>> not with the proposed text. >>> >>> - Jouni >>> >>>>> 20. clause 5.2, 1st sentence: >>>>> Should read: "A reporting node using the loss algorithm must use >>>>> the OC-Reduction-Percentage AVP (Section 6.7) to indicated the >>>>> desired percentage of traffic reduction." >>>> SRD> Agreed. >>>>> 21. clause 5.2, last sentence: >>>>> Should read: "Editor's note: The above duplicates what is in the >>>>> OC-Reduction-Percentage AVP section and can probably be removed." >>>> SRD> Yes, bad wording. The note will be removed, bad wording and all, >>>> once there is a discussion on if this is redundant. >>>>> 22. clause 5.4, 6th paragraph: >>>>> Should read: "If the reacting node does not receive a an OLR in the >>>>> answer that corresponds to the probe request messages sent to the >>>>> formally overloaded node then the reacting node should slowly >>>>> increase the rate of traffic sent to the overloaded node." >>>> SRD Agreed, this is more clear. >>>>> Best regards >>>>> Ulrich >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>> Donovan >>>>> Sent: Saturday, July 05, 2014 9:42 PM >>>>> To: dime@ietf.org >>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>> >>>>> All, >>>>> >>>>> This version of the DOIC draft is a restructuring of previously >>>>> agreed to content. >>>>> >>>>> The master plan for the restructuring is in Appendix C. This >>>>> outlines where material from -02 was moved in -03. >>>>> >>>>> For those interested, the work was done in steps, with a snapshot for >>>>> each step available here: >>>>> >>>>> https://github.com/jounikor/draft-docdt-dime-ovli >>>>> >>>>> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >>>>> >>>>> where nn indicates the subversion and "text" indicates the focus for >>>>> that subversion. >>>>> >>>>> The next step will be to resolve open issues already identified and >>>>> those yet those yet to be identified. >>>>> >>>>> Regards, >>>>> >>>>> Steve >>>>> >>>>> >>>>> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> directories. >>>>>> This draft is a work item of the Diameter Maintenance and >>>>>> Extensions Working Group of the IETF. >>>>>> >>>>>> Title : Diameter Overload Indication >>>>>> Conveyance >>>>>> Authors : Jouni Korhonen >>>>>> Steve Donovan >>>>>> Ben Campbell >>>>>> Lionel Morand >>>>>> Filename : draft-ietf-dime-ovli-03.txt >>>>>> Pages : 48 >>>>>> Date : 2014-07-03 >>>>>> >>>>>> Abstract: >>>>>> This specification documents a Diameter Overload Control >>>>>> (DOC) base >>>>>> solution and the dissemination of the overload report >>>>>> information. >>>>>> >>>>>> Requirements >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-03 >>>>>> >>>>>> >>>>>> Please note that it may take a couple of minutes from the time of >>>>>> submission until the htmlized version and diff are available at >>>>>> tools.ietf.org. >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Mon Jul 21 08:17:01 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F37F1A00AE for ; Mon, 21 Jul 2014 08:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 vXP57smo8UcU for ; Mon, 21 Jul 2014 08:16:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69771A0275 for ; Mon, 21 Jul 2014 08:16:45 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 146A53B51AB; Mon, 21 Jul 2014 17:16:44 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id EA1A8C805F; Mon, 21 Jul 2014 17:16:43 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Mon, 21 Jul 2014 17:16:42 +0200 From: To: MORAND Lionel IMT/OLN , Jouni Korhonen , "Hirschman, Brent B [CTO]" , "dime@ietf.org" Thread-Topic: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-00 - Use Cases Thread-Index: AQHPoFHcjeWHob/KCU6OTlCDB7Nt4Juqo9TggAAHnPA= Date: Mon, 21 Jul 2014 15:16:41 +0000 Message-ID: <20946_1405955804_53CD2EDB_20946_9839_1_fd712d90-f481-4805-be7c-ce57c044ce34@PEXCVZYH01.corporate.adroot.infra.ftgroup> References: <9203f8d398b14340b45617e019dc512e@PREWE13M04.ad.sprint.com> <53C56425.7040908@gmail.com> <17254_1405953857_53CD2741_17254_8004_1_6B7134B31289DC4FAF731D844122B36E66A03A@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <17254_1405953857_53CD2741_17254_8004_1_6B7134B31289DC4FAF731D844122B36E66A03A@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.21.143022 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/mDW0Tm5BCpYyPxFxSq7tv7-9MBE Cc: "Rajagopal, Arun \[CTO\]" , "Sershen, Dan J \[CTO\]" Subject: Re: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-00 - Use Cases X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:16:55 -0000 I agreed on the wrong email! :) We have experienced several IETF last calls on similar drafts and the feedb= ack is always the same: difficult to see how the AVPs defined by this new d= raft are managed by the sending and receiving entities. Moreover, the relat= ion with the RFC5777 should be clarified. For instance, it is really diffic= ult to understand a simplem sentence like: -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@oran= ge.com Envoy=E9=A0: lundi 21 juillet 2014 16:44 =C0=A0: Jouni Korhonen; Hirschman, Brent B [CTO]; dime@ietf.org Cc=A0: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO] Objet=A0: Re: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-= 00 - Use Cases Agreed -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Envoy=E9=A0: mardi 15 juillet 2014 19:26 =C0=A0: Hirschman, Brent B [CTO]; dime@ietf.org Cc=A0: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO] Objet=A0: Re: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-= 00 - Use Cases Brent, I do agree with your conclusion that adding examples would be minimal=20 incremental addition to what RFC5777 already has. Also, IMHO use cases=20 for ECN should be rather well known. I see no reason to add text for=20 "topic 2". - Jouni 4/29/2014 5:35 PM, Hirschman, Brent B [CTO] kirjoitti: > At IETF 89 in London, during the discussion of the > draft-ietf-dime-congestion-flow-attributes-00.txt, Two areas were > requested to be investigated further. We will be addressing them in > separate email threads to keep the discussion focused on each topic. > This is Topic 2: > > Second, we were requested to investigate providing example use cases of > ECN. RFC5777 already provides a set of use cases for reporting and ECN > is just one of many such reporting parameters such as byte count. > Adding a paragraph of text such as the following may add some > information but the authors feel little incremental information is > needed because of the work already in RFC 5777. > > "Diameter nodes along the bearer path can implement filters to collect > accounting and policy control information based on these congestion > parameters similar to byte count information. These filters on flows and > overall node congestion for these AVPs can report a measure of quality > of byte counts to collection points in the network where decisions can > be made to mitigate or mediate any congestion conditions for accounting > or real time policy control. These AVPs provide supplemental information > as described in the use cases discussed in RFC5777." > > Thus, the authors are proposing no modification to the working group > draft at this time. Comments are welcome. > > */Brent Hirschman/* > > Tech Dev Strategist III > > Sprint Corporation > > 6220 Sprint Parkway > > Overland Park, KS 66251// > > Office - 913-762-6736 > > Mobile - 913-593-6221 > > > ------------------------------------------------------------------------ > > This e-mail may contain Sprint proprietary information intended for the > sole use of the recipient(s). Any use by others is prohibited. If you > are not the intended recipient, please contact the sender and delete all > copies of the message. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Jul 21 08:32:53 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF3D1A0016 for ; Mon, 21 Jul 2014 08:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 vC4Zm5T2tNB0 for ; Mon, 21 Jul 2014 08:32:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5431A00B8 for ; Mon, 21 Jul 2014 08:32:29 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 699232AD8BF; Mon, 21 Jul 2014 17:32:27 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 49FE9180067; Mon, 21 Jul 2014 17:32:27 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Mon, 21 Jul 2014 17:32:26 +0200 From: To: MORAND Lionel IMT/OLN , Jouni Korhonen , "Hirschman, Brent B [CTO]" , "dime@ietf.org" Thread-Topic: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-00 - Use Cases Thread-Index: AQHPoFHcjeWHob/KCU6OTlCDB7Nt4Juqo9TggAAHnPCAAAGLEA== Date: Mon, 21 Jul 2014 15:32:26 +0000 Message-ID: <17254_1405956747_53CD328B_17254_10542_1_68f3ae65-b172-42e3-8466-a8ae48dd21c4@PEXCVZYH02.corporate.adroot.infra.ftgroup> References: <9203f8d398b14340b45617e019dc512e@PREWE13M04.ad.sprint.com> <53C56425.7040908@gmail.com> <17254_1405953857_53CD2741_17254_8004_1_6B7134B31289DC4FAF731D844122B36E66A03A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <6B7134B31289DC4FAF731D844122B36E66A1E5@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <6B7134B31289DC4FAF731D844122B36E66A1E5@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.21.143022 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/h-bYEuV8Om7N4R6jhrJnm16yqGg Cc: "Rajagopal, Arun \[CTO\]" , "Sershen, Dan J \[CTO\]" Subject: Re: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-00 - Use Cases X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:32:51 -0000 I agreed on the wrong email! :) >From a technical point of view, this draft is ready for WGLC. However, from= an editorial aspect, I think that we could improve the document. We have experienced several IETF last calls on similar drafts and the feedb= ack is always the same: difficult to see how the AVPs defined by this new d= raft are really used over Diameter and managed by the sending and receiving= entities. Moreover, the relation with the RFC3168 and RFC5777 should be cl= arified. For instance, it is really difficult to understand a simple sectio= n like section 3.1: The ECN-IP-Codepoint AVP (AVP Code TBD) is of type Enumerated and specifies the Explicit Congestion Notification codepoint values to match in the IP header. Value | Binary | Keyword | References ----------------------------------------------------------------- 0 | 00 | Non-ECT (Not ECN-Capable Transport)| [RFC3168] 1 | 01 | ECT(1) (ECN-Capable Transport) | [RFC3168] 2 | 10 | ECT(0) (ECN-Capable Transport) | [RFC3168] 3 | 11 | CE (Congestion Experienced) | [RFC3168] When this AVP is used for classification in the Filter-Rule it MUST be part of Classifier Grouped AVP as defined in RFC5777. We should explain why it is used in this Grouped AVP and how this new AVP w= ill be used, how the values are set, etc. So I would suggest to add some extra text if you want to avoid to spend too= much during the LC process. Regards, Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@oran= ge.com Envoy=E9=A0: lundi 21 juillet 2014 16:44 =C0=A0: Jouni Korhonen; Hirschman, Brent B [CTO]; dime@ietf.org Cc=A0: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO] Objet=A0: Re: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-= 00 - Use Cases Agreed -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Envoy=E9=A0: mardi 15 juillet 2014 19:26 =C0=A0: Hirschman, Brent B [CTO]; dime@ietf.org Cc=A0: Rajagopal, Arun [CTO]; Sershen, Dan J [CTO] Objet=A0: Re: [Dime] Topic 2 of draft-ietf-dime-congestion-flow-attributes-= 00 - Use Cases Brent, I do agree with your conclusion that adding examples would be minimal=20 incremental addition to what RFC5777 already has. Also, IMHO use cases=20 for ECN should be rather well known. I see no reason to add text for=20 "topic 2". - Jouni 4/29/2014 5:35 PM, Hirschman, Brent B [CTO] kirjoitti: > At IETF 89 in London, during the discussion of the > draft-ietf-dime-congestion-flow-attributes-00.txt, Two areas were > requested to be investigated further. We will be addressing them in > separate email threads to keep the discussion focused on each topic. > This is Topic 2: > > Second, we were requested to investigate providing example use cases of > ECN. RFC5777 already provides a set of use cases for reporting and ECN > is just one of many such reporting parameters such as byte count. > Adding a paragraph of text such as the following may add some > information but the authors feel little incremental information is > needed because of the work already in RFC 5777. > > "Diameter nodes along the bearer path can implement filters to collect > accounting and policy control information based on these congestion > parameters similar to byte count information. These filters on flows and > overall node congestion for these AVPs can report a measure of quality > of byte counts to collection points in the network where decisions can > be made to mitigate or mediate any congestion conditions for accounting > or real time policy control. These AVPs provide supplemental information > as described in the use cases discussed in RFC5777." > > Thus, the authors are proposing no modification to the working group > draft at this time. Comments are welcome. > > */Brent Hirschman/* > > Tech Dev Strategist III > > Sprint Corporation > > 6220 Sprint Parkway > > Overland Park, KS 66251// > > Office - 913-762-6736 > > Mobile - 913-593-6221 > > > ------------------------------------------------------------------------ > > This e-mail may contain Sprint proprietary information intended for the > sole use of the recipient(s). Any use by others is prohibited. If you > are not the intended recipient, please contact the sender and delete all > copies of the message. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Jul 21 09:44:52 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A03D1A0059 for ; Mon, 21 Jul 2014 09:44:51 -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, SPF_NEUTRAL=0.779] autolearn=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 md5n0avXyGqO for ; Mon, 21 Jul 2014 09:44:48 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 C4B981A005F for ; Mon, 21 Jul 2014 09:44:48 -0700 (PDT) Received: from dhcp-a698.meeting.ietf.org ([31.133.166.152]:52794) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X9Ghf-0002kc-Mx; Mon, 21 Jul 2014 09:44:47 -0700 Message-ID: <53CD4379.3010203@usdonovans.com> Date: Mon, 21 Jul 2014 12:44:41 -0400 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jouni Korhonen , "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <53CD2962.6060403@gmail.com> In-Reply-To: <53CD2962.6060403@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xO3fCmYxFncFmhtvyboJIQ8JnoI Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 16:44:51 -0000 On 7/21/14, 10:53 AM, Jouni Korhonen wrote: > Steve, > > 7/21/2014 5:29 PM, Steve Donovan kirjoitti: >> Ulrich, >> >> I am not arguing that all agents should take an active role in the >> handling of all overload reports. What I am arguing is that there are >> scenarios where an agent must take an active role in DOIC to ensure that >> a requested reduction in traffic an be achieved. >> >> For DOIC to work a carrier cannot turn off all DOIC behavior in agents, >> as suggested by Jouni. > > Why? If you have a hierarchy of agents I don't see a reason why some > of those could be just "vanilla agents" or DOIC agents with > functionality turned off. Not arguing such deployment makes sense but > the protocol solution should be able to cope with that. SRD> I agree that some of the agents can have DOIC behavior turned off, as long as the agent in question does not have a direct transport connection to a Diameter node that could generate a host report. > > - Jouni > >> >> I agree that in your scenario below, a1 does not need to take an active >> role in reducing traffic when c supports DOIC. a1 should take an active >> role when c does not support DOIC. The problem is that a1 does not know >> in advance whether c supports DOIC so it will need to inspect all >> transactions for the presence of OC-S-F to determine if it needs to >> handle overload reports for a non supporting client. >> >> Does that mean a1 is transparent if it inspects all requests and does >> nothing in the case where there is c supports DOIC? >> >> Does transparent mean that there is no observable difference in the DOIC >> AVPs that pass through the agent or does it mean that there is no >> observable difference in how transactions are handled by the DOIC agent? >> >> I'm guessing that we have multiple assumptions on what transparent means >> and, if we are going to continue saying agents should be transparent >> then we need a definition of transparent. >> >> I think for this use case, we need the following normative statements in >> the draft for handling of abatement of realm-routed requests? I think >> this is general behavior and should go in the section on handling of >> overload reports. >> >> "DOIC nodes with a direct transport connection to a reporting node that >> has an active overload report must handle abatement of realm-routed >> requests. The preferred method for handling abatement of realm-routed >> requests is diversion, where the node with the direct transport >> connection routes the request to an alternative server that is able to >> handle the request. If there is no alternative server with the needed >> capacity to handle the request then the DOIC node must/should throttle >> the necessary requests to meet the requested reduction in traffic." >> >> If we can agree on this then we can move on to the next agent based use >> case. >> >> Regards, >> >> Steve >> >> On 7/21/14, 9:47 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>> Steve, >>> >>> The example you show is absolutely valid and 100% inline with A) to F) >>> - (assuming that all servers can serve any request). >>> However, there are other scenarios like: >>> >>> >>> +--+ >>> /--|s1| >>> +-+ +--+ +--+ / +--+ >>> |c|--- |a1|--|a2|== ... >>> +-+ +--+ +--+ \ +--+ >>> \--|sn| >>> +--+ >>> >>> Here I think a1 should be transparent even when DOICable. >>> a1 does not take the role of a reacting node since c supports DOIC. >>> a1 does not perform server selection and therefore does not take the >>> role of a reporting node (for realm-reports). >>> >>> Ulrich >>> >>> >>> -----Original Message----- >>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] >>> Sent: Monday, July 21, 2014 3:16 PM >>> To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - >>> DE/Munich); dime@ietf.org >>> Subject: Transparent agents (was Re: [Dime] I-D Action: >>> draft-ietf-dime-ovli-03.txt) >>> >>> Ok, let's see if it's possible to completely turn off all DOIC behavior >>> in agents and still be able to reduce traffic to a server that sends a >>> host overload report. >>> >>> Assume the following agent based deployment: >>> >>> +--+ >>> /--|s1| >>> +-+ +-+ / +--+ >>> |c|--|a|== ... >>> +-+ +-+ \ +--+ >>> \--|sn| >>> +--+ >>> >>> Assume that there is a large number of servers, say 50. >>> >>> Now, assume that the Diameter application in question exclusively uses >>> realm-routed requests - 100% of requests sent by the client do NOT have >>> a destination-host AVP. >>> >>> Now assume that server s1 sends an host type overload report requesting >>> a reduction of 20% using the loss algorithm. >>> >>> Also assume that the unused capacity in servers s2 through s50 is >>> sufficient to handle the traffic that would have been sent to s1. As >>> such, there is no reason to throttle any requests. >>> >>> There are no host routed requests for this application and the client >>> does not have a direct transport connection to server s1. The only >>> option a client has is to hand the request off to the agent for >>> routing. >>> >>> The proposal in the agent cases draft is that the agent diverts 20% of >>> the realm routed requests that would have been sent to server s1 to >>> servers s2 through s50. >>> >>> If DOIC behavior is turned off in the agent then how will the traffic >>> routed to s1 be reduced? >>> >>> Steve >>> >>> On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote: >>>> +1 for the following aspect. >>>> >>>>>>> Agents must take an active role in even the most basic case for >>>>>>> overload handling to work, so they cannot be transparent. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do >>>>>> not support DOIC are transparent. Agents that support DOIC in most >>>>>> cases behave like non supporting agents. >>>>> I am towards Ulrich's view here. Even for an agent that understands >>>>> DOIC it is up to the local policy whether it is transparent or takes >>>>> an active role. >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >>>> Sent: Monday, July 21, 2014 12:26 AM >>>> To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org >>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>> >>>> Some comments inline.. >>>> >>>> 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >>>>> Steve, >>>>> please see my response inline. >>>>> >>>>> Regards >>>>> Ulrich >>>>> >>>>> -----Original Message----- >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>> Donovan >>>>> Sent: Tuesday, July 15, 2014 3:53 PM >>>>> To: dime@ietf.org >>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>> >>>>> Ulrich, >>>>> >>>>> Thanks for the comments. Please see my responses inline. >>>>> >>>>> Regards, >>>>> >>>>> Steve >>>>> On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>>>> Hi Steve, >>>>>> here are my comments. >>>>>> They focus on new text you introduced. I agree that restructuring >>>>>> may require new text, however, I believe that with the new text a >>>>>> new concepts is introduced which macerates the agreed end-to-end >>>>>> concept and allows all DOIC agents on the path to do what they >>>>>> wants, so that we end up in a hop-by-hop concept. >>>>> SRD> We have never had an agreement on end-to-end versus hop-by-hop >>>>> SRD> and >>>>> I believe that we will end up with a hybrid of the two. We have open >>>>> issues on agent behavior that Ben and I are attempting to address >>>>> with >>>>> the agent cases draft. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop >>>>> approach of the roach draft was reason not to proceed with that >>>>> draft. >>>>> >>>>> SRD> That said, this type of restructuring of the document is likely >>>>> SRD> to >>>>> put agreed to behavior in a new light. If there are cases where I >>>>> have implied changes to agreed to normative behavior, or if the >>>>> informative text is not accurate, then these things need to be >>>>> corrected. >>>>>> 1. clause 2.3, second paragraph: >>>>>> Should read: "Reacting nodes indicate support for DOIC by including >>>>>> the OC-Supported-Features AVP into all request messages originated >>>>>> or relayed by the Reacting node." >>>>> SRD> You mean clause 3.2. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes >>>>> I agree with the change. >>>>>> 2. clause 2.3, 3rd paragraph, 1st sentence: >>>>>> OC-xxx AVPs must not be included in an answer message when the >>>>>> corresponding request did not contain an OC-S-F AVP. >>>>> SRD> Agreed. >>>>>> 3. clause 3.3, 7th paragraph: >>>>>> Should read "The reporting node only includes an indication of >>>>>> support for one overload abatement algorithm. This is the >>>>>> algorithm that the reporting node intends to use should it enter an >>>>>> overload condition or requests to use while it actually is in an >>>>>> overload condition. Reacting nodes can use the indicated overload >>>>>> abatement algorithm to prepare for possible overload reports and >>>>>> must use the indicated overload abatement algorithm if traffic >>>>>> reduction is actually requested." >>>>> SRD. OK. >>>>>> 4. clause 3.3, 10th paragraph: >>>>>> The 1st sentence is misleading. In the general case, agents on the >>>>>> path between reacting node and reporting node are transparent. I >>>>>> agree that there are exceptions to the general case where an agent >>>>>> on the path is not transparent, but then the agent IS the reporting >>>>>> node (reporting to the sender of the request) and it also IS the >>>>>> reacting node (reacting on reports received from the upstream >>>>>> reporting node). >>>>>> The first 3 words of the second sentence "in this case" need >>>>>> clarification: "In the case where an agent takes the role of a >>>>>> reporting node (reporting to the downstream reacting node) and at >>>>>> the same time takes the role of a reacting node (reacting on >>>>>> reports received from an upstream reporting node)". >>>>>> Last sentence: Its not an update but a replacement. The two DOIC >>>>>> associations are handled independently. >>>>> SRD> I don't know what you mean when you say an agent is transparent. >>>>> Agents must take an active role in even the most basic case for >>>>> overload handling to work, so they cannot be transparent. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not >>>>> support DOIC are transparent. Agents that support DOIC in most cases >>>>> behave like non supporting agents. >>>> I am towards Ulrich's view here. Even for an agent that understands >>>> DOIC it is up to the local policy whether it is transparent or takes >>>> an active role. >>>> >>>>>> 5. clause 3.3, last paragraph: >>>>>> General rules shall be followed for each of the two associations >>>>>> separately. The content of the OC-S-F AVP sent by the agent >>>>>> upstream should reflect what the agent is able and willing to >>>>>> support (as always). >>>>> SRD> What two associations? Is there one association (end-to-end) or >>>>> SRD> is >>>>> the an association on both sides of the agent (hop-by-hop)? Or is >>>>> there an association that involves three entities, the reporting >>>>> node, >>>>> an agent reacting node for realm-routed requests and a >>>>> transaction-client reporting node for handling host-routed requests? >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, >>>>> There is >>>>> one association between C and A, and one association between A and >>>>> S. Both associations are "end-to-end" as there may be transparent >>>>> (supporting or non-supporting) agents in the middle. >>>>>> 6. clause 3.4, 2nd paragraph: >>>>>> Should read: "The OC-OLR AVP is referred to as an overload report. >>>>>> The OC-OLR AVP includes the type of report, a sequence number, the >>>>>> length of time that the report is valid and abatement algorithm >>>>>> specific AVPs." >>>>> SRD> The sequence number is being used as an overload report ID. I >>>>> can >>>>> make the change but I don't see it as necessary. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. >>>> OK to do the change. >>>> >>>>>> 7. clause 3.4, 4th paragraph, 2nd sentence: >>>>>> I cannot understand this sentence. Probably only simple typos but I >>>>>> don't know. >>>>> SRD> Yes, a typo (this instead of the) and awkward wording. How >>>>> about >>>>> "This applies to requests that contain the Destination-Host AVP >>>>> with a >>>>> DiameterIdentity that matches the overload report. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that >>>>> contain a DiameterIdentity in the Destination-Host AVP that matches >>>>> the reporting host's DiameterIdentity" >>>> I would be inclined to keep the text Steve proposed. But both are ok >>>> actually. >>>> >>>>>> 8. clause 3.4, 4th paragraph last 2 sentences: >>>>>> I don't understand and probably do not agree. >>>>> SRD> See above. >>>>>> 9. clause 3.5, 3rd paragraph, last word: >>>>>> Should read "communicated" >>>>> SRD> Agreed. >>>>>> 10. clause 3.5, 4th paragraph, 1st sentence: >>>>>> I don't understand. I can understand: "Reporting nodes use the >>>>>> OC-OLR AVP to communicate overload occurances towards reacting >>>>>> nodes." >>>>> SRD> Who else would reports be sent to? >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement >>>>> algorithm but the reporting node that uses the OC-OLR AVP to >>>>> communicate overload occurances. >>>> Agree. >>>> >>>>>> 11. clause 4.1, 3rd paragraph, last 4 words: >>>>>> may be misleading. A DOIC supporting agent sitting between DOIC >>>>>> supporting client and DOIC supporting Server is transparent with >>>>>> regard to DOIC. This agent does not indicate DOIC support. >>>>> SRD> I disagree. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. >>>>> Should be: ...This agent does not indicate its DOIC support, rather >>>>> it transparently forwards the client's DOIC support. >>>> Agree with Ulrich on the intent of agent behavior but not with the >>>> proposed text change. >>>> >>>>>> 12. clause 4.1, 4th paragraph, 2nd sentence: >>>>>> Should read:"If a request message handled by the DOIC agent does >>>>>> not include the OC-Supported-Features AVP then the DOIC agent >>>>>> inserts the AVP." >>>>> SRD> That is what it already says. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... >>>> OC-Supported-Features can be in both request and answer, thus "If a >>>> message" in that sense is correct. >>>> >>>>>> 13. clause 4.1, last sentence: >>>>>> Should read "If the message already has the AVP then the agent >>>>>> either leaves it unchanged in the relayed message or replaces it to >>>>>> reflect the features the agent is able and willing to support." >>>>>> Clarification is needed to say that strict rules must be followed >>>>>> by the agent to select the correct option. These rules take into >>>>>> account whether the request is host-routed or relam-routed and >>>>>> whether the agent is configured to select the server for >>>>>> realm-routed requests. >>>>> SRD> This is a topic on agent behavior that is addressed in the agent >>>>> cases draft. I'll leave the discussion for what the wording >>>>> should be >>>>> to the discussion on that draft. >>>>>> 14. clause 4.1.2, 2nd paragraph: >>>>>> Should read: "Based on the content of the OC-Supported-Features AVP >>>>>> in the request message, the reporting node knows what overload >>>>>> control functionality is supported by the reacting node. The >>>>>> reporting node then acts accordingly for the subsequent answer >>>>>> messages it initiates for the transaction." >>>>> SRD> It would be easier if you didn't make it difficult to understand >>>>> the change you are proposing. I think you are proposing changing >>>>> node(s) to node. I don't agree but that will be addressed as part of >>>>> the agent cases discussion. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing >>>>> two sentences? The proposal is to insert "is" between >>>>> "functionality" and "supported", to add "the" between "by" and >>>>> "reacting", to replace "node(s)" with "node", and to insert "for the >>>>> transaction" after "initiates". >>>> Agree with the proposed change. >>>> >>>>>> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >>>>>> Should read: "message's" >>>>> SRD> I'm assuming you mean section 4.1.2. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, >>>>> and 19. >>>>> I agree to the change. >>>>>> 16. clause 4.1, 6th paragraph: >>>>>> This should be left to the (future) specification that introduces >>>>>> other DOIC features. >>>>>> >>>>>> 17. clause 4.1, 7th paragraph, last 6 words: >>>>>> should be based on requiements set by the (future) specification >>>>>> that >>>>>> introduces other DOIC features >>>>> SRD> Again, clause 4.1.2 -- I don't understand the issue when these >>>>> SRD> two >>>>> paragraphs are taken together. >>>>>> 18. clause 4.1, 8th paragraph, last sentence: >>>>>> Should read: "Lack of the OC-Supported-Features AVP in the request >>>>>> message indicates that there is no downstream reacting node for the >>>>>> transaction." >>>>> SRD> I think you mean clause 4.1.2. I don't see the need for the >>>>> change. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not >>>>> correct. It should either read: "Lack of the OC-Supported-Feature >>>>> AVP in the request message indicates to the reporting node that >>>>> there is no reacting node for the transaction" or as proposed above. >>>> I don't see a reason for the change. Original text seem correct to me. >>>> >>>>>> 19. clause 4.1, last sentence: >>>>>> Should read: "An agent MAY replace the OC-Supported-Features AVP >>>>>> carried in answer messages." This replacement must follow general >>>>>> rules. Its not so that the agent may do what ever it wants to. The >>>>>> decision must be based on whether or not the agent has replaced the >>>>>> OC-S-F in the corresponding request. >>>>> SRD> What is the difference between modify and replace? I am ok with >>>>> removing this statement until we have the agent behavior discussion. >>>>> I thought I had taken the agent specific statements out of this >>>>> version. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with >>>>> identical values. You remove what has been received in and insert >>>>> your own stuff. >>>> Agent (proxy) can always do that i.e. modify the APV contents. >>>> Obviously if an agent tampers the OC-Supported-Features AVP it needs >>>> to know what it is doing. In general agree with the clarification but >>>> not with the proposed text. >>>> >>>> - Jouni >>>> >>>>>> 20. clause 5.2, 1st sentence: >>>>>> Should read: "A reporting node using the loss algorithm must use >>>>>> the OC-Reduction-Percentage AVP (Section 6.7) to indicated the >>>>>> desired percentage of traffic reduction." >>>>> SRD> Agreed. >>>>>> 21. clause 5.2, last sentence: >>>>>> Should read: "Editor's note: The above duplicates what is in the >>>>>> OC-Reduction-Percentage AVP section and can probably be removed." >>>>> SRD> Yes, bad wording. The note will be removed, bad wording and >>>>> all, >>>>> once there is a discussion on if this is redundant. >>>>>> 22. clause 5.4, 6th paragraph: >>>>>> Should read: "If the reacting node does not receive a an OLR in the >>>>>> answer that corresponds to the probe request messages sent to the >>>>>> formally overloaded node then the reacting node should slowly >>>>>> increase the rate of traffic sent to the overloaded node." >>>>> SRD Agreed, this is more clear. >>>>>> Best regards >>>>>> Ulrich >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>>> Donovan >>>>>> Sent: Saturday, July 05, 2014 9:42 PM >>>>>> To: dime@ietf.org >>>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>> >>>>>> All, >>>>>> >>>>>> This version of the DOIC draft is a restructuring of previously >>>>>> agreed to content. >>>>>> >>>>>> The master plan for the restructuring is in Appendix C. This >>>>>> outlines where material from -02 was moved in -03. >>>>>> >>>>>> For those interested, the work was done in steps, with a snapshot >>>>>> for >>>>>> each step available here: >>>>>> >>>>>> https://github.com/jounikor/draft-docdt-dime-ovli >>>>>> >>>>>> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >>>>>> >>>>>> where nn indicates the subversion and "text" indicates the focus for >>>>>> that subversion. >>>>>> >>>>>> The next step will be to resolve open issues already identified and >>>>>> those yet those yet to be identified. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>>> directories. >>>>>>> This draft is a work item of the Diameter Maintenance and >>>>>>> Extensions Working Group of the IETF. >>>>>>> >>>>>>> Title : Diameter Overload Indication >>>>>>> Conveyance >>>>>>> Authors : Jouni Korhonen >>>>>>> Steve Donovan >>>>>>> Ben Campbell >>>>>>> Lionel Morand >>>>>>> Filename : draft-ietf-dime-ovli-03.txt >>>>>>> Pages : 48 >>>>>>> Date : 2014-07-03 >>>>>>> >>>>>>> Abstract: >>>>>>> This specification documents a Diameter Overload Control >>>>>>> (DOC) base >>>>>>> solution and the dissemination of the overload report >>>>>>> information. >>>>>>> >>>>>>> Requirements >>>>>>> >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>>>>>> >>>>>>> There's also a htmlized version available at: >>>>>>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-03 >>>>>>> >>>>>>> >>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>> submission until the htmlized version and diff are available at >>>>>>> tools.ietf.org. >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>> DiME@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > From nobody Mon Jul 21 10:44:51 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57451A0065 for ; Mon, 21 Jul 2014 10:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 ErsnsOqu-05w for ; Mon, 21 Jul 2014 10:44:46 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDB7F1A024C for ; Mon, 21 Jul 2014 10:44:44 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id w61so7899711wes.23 for ; Mon, 21 Jul 2014 10:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ytdfMnl8TwWHgzqSN1p9QUePaRwmujy+91UdxMII88c=; b=F9coVtZKWfClaoJ4Jotq1Yb93D7pDcrKkG8UyutOEekhNbQHH/7CCYLjYylFkpaNbz NaEH2WLOVf9Y+b/g8W/mXxzHGg37vppp0qBfmLfD2leppsgLIzSFkFuN8r5mmfKyiA36 on7IXdVXa90G5sUL42eQv0g1qkwfSvG8XWpzvvJ4G0BVxXMTXE26+BrZ6RMHg0RkaNkK Hd3QjlE37v0dxtxEmn8mSGFgQ1r9iDo2Hf25g4QaiFtcCJHsS9/bvEfOHJSyKN1xyFWT a8lBmEus0vD5+yXBboEQnlHrwqrJ6uwJow++RNu62jz5nBx/Q2sL0rqDDhX2ObHS2zIz SUZQ== X-Received: by 10.180.94.166 with SMTP id dd6mr6347214wib.33.1405964683361; Mon, 21 Jul 2014 10:44:43 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:d5fb:9652:9d68:924c? ([2001:67c:370:176:d5fb:9652:9d68:924c]) by mx.google.com with ESMTPSA id di7sm39173157wjb.34.2014.07.21.10.44.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 10:44:42 -0700 (PDT) Message-ID: <53CD5188.1010009@gmail.com> Date: Mon, 21 Jul 2014 20:44:40 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steve Donovan , "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <53CD2962.6060403@gmail.com> <53CD4379.3010203@usdonovans.com> In-Reply-To: <53CD4379.3010203@usdonovans.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qE0qJeWkBQKQfeVJGFTRxU3koBc Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 17:44:50 -0000 Steve, A bit more inline. 7/21/2014 7:44 PM, Steve Donovan kirjoitti: > > On 7/21/14, 10:53 AM, Jouni Korhonen wrote: >> Steve, >> >> 7/21/2014 5:29 PM, Steve Donovan kirjoitti: >>> Ulrich, >>> >>> I am not arguing that all agents should take an active role in the >>> handling of all overload reports. What I am arguing is that there are >>> scenarios where an agent must take an active role in DOIC to ensure that >>> a requested reduction in traffic an be achieved. >>> >>> For DOIC to work a carrier cannot turn off all DOIC behavior in agents, >>> as suggested by Jouni. >> >> Why? If you have a hierarchy of agents I don't see a reason why some >> of those could be just "vanilla agents" or DOIC agents with >> functionality turned off. Not arguing such deployment makes sense but >> the protocol solution should be able to cope with that. > SRD> I agree that some of the agents can have DOIC behavior turned off, > as long as the agent in question does not have a direct transport > connection to a Diameter node that could generate a host report. Ok. One more thing. If there is an agent that either has no DOIC capability or it is turned off the outcome can be non-optimal/non-desired, but that should not break anything, right? In that light I do not understand the direct peer connection requirement since if the agent allows turning off the DOIC functionally such deployment can be done irrespective what the RFC says (e.g. misconfiguration or for a specific reason). - Jouni >> >> - Jouni >> >>> >>> I agree that in your scenario below, a1 does not need to take an active >>> role in reducing traffic when c supports DOIC. a1 should take an active >>> role when c does not support DOIC. The problem is that a1 does not know >>> in advance whether c supports DOIC so it will need to inspect all >>> transactions for the presence of OC-S-F to determine if it needs to >>> handle overload reports for a non supporting client. >>> >>> Does that mean a1 is transparent if it inspects all requests and does >>> nothing in the case where there is c supports DOIC? >>> >>> Does transparent mean that there is no observable difference in the DOIC >>> AVPs that pass through the agent or does it mean that there is no >>> observable difference in how transactions are handled by the DOIC agent? >>> >>> I'm guessing that we have multiple assumptions on what transparent means >>> and, if we are going to continue saying agents should be transparent >>> then we need a definition of transparent. >>> >>> I think for this use case, we need the following normative statements in >>> the draft for handling of abatement of realm-routed requests? I think >>> this is general behavior and should go in the section on handling of >>> overload reports. >>> >>> "DOIC nodes with a direct transport connection to a reporting node that >>> has an active overload report must handle abatement of realm-routed >>> requests. The preferred method for handling abatement of realm-routed >>> requests is diversion, where the node with the direct transport >>> connection routes the request to an alternative server that is able to >>> handle the request. If there is no alternative server with the needed >>> capacity to handle the request then the DOIC node must/should throttle >>> the necessary requests to meet the requested reduction in traffic." >>> >>> If we can agree on this then we can move on to the next agent based use >>> case. >>> >>> Regards, >>> >>> Steve >>> >>> On 7/21/14, 9:47 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>> Steve, >>>> >>>> The example you show is absolutely valid and 100% inline with A) to F) >>>> - (assuming that all servers can serve any request). >>>> However, there are other scenarios like: >>>> >>>> >>>> +--+ >>>> /--|s1| >>>> +-+ +--+ +--+ / +--+ >>>> |c|--- |a1|--|a2|== ... >>>> +-+ +--+ +--+ \ +--+ >>>> \--|sn| >>>> +--+ >>>> >>>> Here I think a1 should be transparent even when DOICable. >>>> a1 does not take the role of a reacting node since c supports DOIC. >>>> a1 does not perform server selection and therefore does not take the >>>> role of a reporting node (for realm-reports). >>>> >>>> Ulrich >>>> >>>> >>>> -----Original Message----- >>>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] >>>> Sent: Monday, July 21, 2014 3:16 PM >>>> To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - >>>> DE/Munich); dime@ietf.org >>>> Subject: Transparent agents (was Re: [Dime] I-D Action: >>>> draft-ietf-dime-ovli-03.txt) >>>> >>>> Ok, let's see if it's possible to completely turn off all DOIC behavior >>>> in agents and still be able to reduce traffic to a server that sends a >>>> host overload report. >>>> >>>> Assume the following agent based deployment: >>>> >>>> +--+ >>>> /--|s1| >>>> +-+ +-+ / +--+ >>>> |c|--|a|== ... >>>> +-+ +-+ \ +--+ >>>> \--|sn| >>>> +--+ >>>> >>>> Assume that there is a large number of servers, say 50. >>>> >>>> Now, assume that the Diameter application in question exclusively uses >>>> realm-routed requests - 100% of requests sent by the client do NOT have >>>> a destination-host AVP. >>>> >>>> Now assume that server s1 sends an host type overload report requesting >>>> a reduction of 20% using the loss algorithm. >>>> >>>> Also assume that the unused capacity in servers s2 through s50 is >>>> sufficient to handle the traffic that would have been sent to s1. As >>>> such, there is no reason to throttle any requests. >>>> >>>> There are no host routed requests for this application and the client >>>> does not have a direct transport connection to server s1. The only >>>> option a client has is to hand the request off to the agent for >>>> routing. >>>> >>>> The proposal in the agent cases draft is that the agent diverts 20% of >>>> the realm routed requests that would have been sent to server s1 to >>>> servers s2 through s50. >>>> >>>> If DOIC behavior is turned off in the agent then how will the traffic >>>> routed to s1 be reduced? >>>> >>>> Steve >>>> >>>> On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote: >>>>> +1 for the following aspect. >>>>> >>>>>>>> Agents must take an active role in even the most basic case for >>>>>>>> overload handling to work, so they cannot be transparent. >>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do >>>>>>> not support DOIC are transparent. Agents that support DOIC in most >>>>>>> cases behave like non supporting agents. >>>>>> I am towards Ulrich's view here. Even for an agent that understands >>>>>> DOIC it is up to the local policy whether it is transparent or takes >>>>>> an active role. >>>>> -----Original Message----- >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >>>>> Sent: Monday, July 21, 2014 12:26 AM >>>>> To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org >>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>> >>>>> Some comments inline.. >>>>> >>>>> 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >>>>>> Steve, >>>>>> please see my response inline. >>>>>> >>>>>> Regards >>>>>> Ulrich >>>>>> >>>>>> -----Original Message----- >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>>> Donovan >>>>>> Sent: Tuesday, July 15, 2014 3:53 PM >>>>>> To: dime@ietf.org >>>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>> >>>>>> Ulrich, >>>>>> >>>>>> Thanks for the comments. Please see my responses inline. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Steve >>>>>> On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>>>>> Hi Steve, >>>>>>> here are my comments. >>>>>>> They focus on new text you introduced. I agree that restructuring >>>>>>> may require new text, however, I believe that with the new text a >>>>>>> new concepts is introduced which macerates the agreed end-to-end >>>>>>> concept and allows all DOIC agents on the path to do what they >>>>>>> wants, so that we end up in a hop-by-hop concept. >>>>>> SRD> We have never had an agreement on end-to-end versus hop-by-hop >>>>>> SRD> and >>>>>> I believe that we will end up with a hybrid of the two. We have open >>>>>> issues on agent behavior that Ben and I are attempting to address >>>>>> with >>>>>> the agent cases draft. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop >>>>>> approach of the roach draft was reason not to proceed with that >>>>>> draft. >>>>>> >>>>>> SRD> That said, this type of restructuring of the document is likely >>>>>> SRD> to >>>>>> put agreed to behavior in a new light. If there are cases where I >>>>>> have implied changes to agreed to normative behavior, or if the >>>>>> informative text is not accurate, then these things need to be >>>>>> corrected. >>>>>>> 1. clause 2.3, second paragraph: >>>>>>> Should read: "Reacting nodes indicate support for DOIC by including >>>>>>> the OC-Supported-Features AVP into all request messages originated >>>>>>> or relayed by the Reacting node." >>>>>> SRD> You mean clause 3.2. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes >>>>>> I agree with the change. >>>>>>> 2. clause 2.3, 3rd paragraph, 1st sentence: >>>>>>> OC-xxx AVPs must not be included in an answer message when the >>>>>>> corresponding request did not contain an OC-S-F AVP. >>>>>> SRD> Agreed. >>>>>>> 3. clause 3.3, 7th paragraph: >>>>>>> Should read "The reporting node only includes an indication of >>>>>>> support for one overload abatement algorithm. This is the >>>>>>> algorithm that the reporting node intends to use should it enter an >>>>>>> overload condition or requests to use while it actually is in an >>>>>>> overload condition. Reacting nodes can use the indicated overload >>>>>>> abatement algorithm to prepare for possible overload reports and >>>>>>> must use the indicated overload abatement algorithm if traffic >>>>>>> reduction is actually requested." >>>>>> SRD. OK. >>>>>>> 4. clause 3.3, 10th paragraph: >>>>>>> The 1st sentence is misleading. In the general case, agents on the >>>>>>> path between reacting node and reporting node are transparent. I >>>>>>> agree that there are exceptions to the general case where an agent >>>>>>> on the path is not transparent, but then the agent IS the reporting >>>>>>> node (reporting to the sender of the request) and it also IS the >>>>>>> reacting node (reacting on reports received from the upstream >>>>>>> reporting node). >>>>>>> The first 3 words of the second sentence "in this case" need >>>>>>> clarification: "In the case where an agent takes the role of a >>>>>>> reporting node (reporting to the downstream reacting node) and at >>>>>>> the same time takes the role of a reacting node (reacting on >>>>>>> reports received from an upstream reporting node)". >>>>>>> Last sentence: Its not an update but a replacement. The two DOIC >>>>>>> associations are handled independently. >>>>>> SRD> I don't know what you mean when you say an agent is transparent. >>>>>> Agents must take an active role in even the most basic case for >>>>>> overload handling to work, so they cannot be transparent. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not >>>>>> support DOIC are transparent. Agents that support DOIC in most cases >>>>>> behave like non supporting agents. >>>>> I am towards Ulrich's view here. Even for an agent that understands >>>>> DOIC it is up to the local policy whether it is transparent or takes >>>>> an active role. >>>>> >>>>>>> 5. clause 3.3, last paragraph: >>>>>>> General rules shall be followed for each of the two associations >>>>>>> separately. The content of the OC-S-F AVP sent by the agent >>>>>>> upstream should reflect what the agent is able and willing to >>>>>>> support (as always). >>>>>> SRD> What two associations? Is there one association (end-to-end) or >>>>>> SRD> is >>>>>> the an association on both sides of the agent (hop-by-hop)? Or is >>>>>> there an association that involves three entities, the reporting >>>>>> node, >>>>>> an agent reacting node for realm-routed requests and a >>>>>> transaction-client reporting node for handling host-routed requests? >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, >>>>>> There is >>>>>> one association between C and A, and one association between A and >>>>>> S. Both associations are "end-to-end" as there may be transparent >>>>>> (supporting or non-supporting) agents in the middle. >>>>>>> 6. clause 3.4, 2nd paragraph: >>>>>>> Should read: "The OC-OLR AVP is referred to as an overload report. >>>>>>> The OC-OLR AVP includes the type of report, a sequence number, the >>>>>>> length of time that the report is valid and abatement algorithm >>>>>>> specific AVPs." >>>>>> SRD> The sequence number is being used as an overload report ID. I >>>>>> can >>>>>> make the change but I don't see it as necessary. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. >>>>> OK to do the change. >>>>> >>>>>>> 7. clause 3.4, 4th paragraph, 2nd sentence: >>>>>>> I cannot understand this sentence. Probably only simple typos but I >>>>>>> don't know. >>>>>> SRD> Yes, a typo (this instead of the) and awkward wording. How >>>>>> about >>>>>> "This applies to requests that contain the Destination-Host AVP >>>>>> with a >>>>>> DiameterIdentity that matches the overload report. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that >>>>>> contain a DiameterIdentity in the Destination-Host AVP that matches >>>>>> the reporting host's DiameterIdentity" >>>>> I would be inclined to keep the text Steve proposed. But both are ok >>>>> actually. >>>>> >>>>>>> 8. clause 3.4, 4th paragraph last 2 sentences: >>>>>>> I don't understand and probably do not agree. >>>>>> SRD> See above. >>>>>>> 9. clause 3.5, 3rd paragraph, last word: >>>>>>> Should read "communicated" >>>>>> SRD> Agreed. >>>>>>> 10. clause 3.5, 4th paragraph, 1st sentence: >>>>>>> I don't understand. I can understand: "Reporting nodes use the >>>>>>> OC-OLR AVP to communicate overload occurances towards reacting >>>>>>> nodes." >>>>>> SRD> Who else would reports be sent to? >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement >>>>>> algorithm but the reporting node that uses the OC-OLR AVP to >>>>>> communicate overload occurances. >>>>> Agree. >>>>> >>>>>>> 11. clause 4.1, 3rd paragraph, last 4 words: >>>>>>> may be misleading. A DOIC supporting agent sitting between DOIC >>>>>>> supporting client and DOIC supporting Server is transparent with >>>>>>> regard to DOIC. This agent does not indicate DOIC support. >>>>>> SRD> I disagree. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. >>>>>> Should be: ...This agent does not indicate its DOIC support, rather >>>>>> it transparently forwards the client's DOIC support. >>>>> Agree with Ulrich on the intent of agent behavior but not with the >>>>> proposed text change. >>>>> >>>>>>> 12. clause 4.1, 4th paragraph, 2nd sentence: >>>>>>> Should read:"If a request message handled by the DOIC agent does >>>>>>> not include the OC-Supported-Features AVP then the DOIC agent >>>>>>> inserts the AVP." >>>>>> SRD> That is what it already says. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... >>>>> OC-Supported-Features can be in both request and answer, thus "If a >>>>> message" in that sense is correct. >>>>> >>>>>>> 13. clause 4.1, last sentence: >>>>>>> Should read "If the message already has the AVP then the agent >>>>>>> either leaves it unchanged in the relayed message or replaces it to >>>>>>> reflect the features the agent is able and willing to support." >>>>>>> Clarification is needed to say that strict rules must be followed >>>>>>> by the agent to select the correct option. These rules take into >>>>>>> account whether the request is host-routed or relam-routed and >>>>>>> whether the agent is configured to select the server for >>>>>>> realm-routed requests. >>>>>> SRD> This is a topic on agent behavior that is addressed in the agent >>>>>> cases draft. I'll leave the discussion for what the wording >>>>>> should be >>>>>> to the discussion on that draft. >>>>>>> 14. clause 4.1.2, 2nd paragraph: >>>>>>> Should read: "Based on the content of the OC-Supported-Features AVP >>>>>>> in the request message, the reporting node knows what overload >>>>>>> control functionality is supported by the reacting node. The >>>>>>> reporting node then acts accordingly for the subsequent answer >>>>>>> messages it initiates for the transaction." >>>>>> SRD> It would be easier if you didn't make it difficult to understand >>>>>> the change you are proposing. I think you are proposing changing >>>>>> node(s) to node. I don't agree but that will be addressed as part of >>>>>> the agent cases discussion. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing >>>>>> two sentences? The proposal is to insert "is" between >>>>>> "functionality" and "supported", to add "the" between "by" and >>>>>> "reacting", to replace "node(s)" with "node", and to insert "for the >>>>>> transaction" after "initiates". >>>>> Agree with the proposed change. >>>>> >>>>>>> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >>>>>>> Should read: "message's" >>>>>> SRD> I'm assuming you mean section 4.1.2. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, >>>>>> and 19. >>>>>> I agree to the change. >>>>>>> 16. clause 4.1, 6th paragraph: >>>>>>> This should be left to the (future) specification that introduces >>>>>>> other DOIC features. >>>>>>> >>>>>>> 17. clause 4.1, 7th paragraph, last 6 words: >>>>>>> should be based on requiements set by the (future) specification >>>>>>> that >>>>>>> introduces other DOIC features >>>>>> SRD> Again, clause 4.1.2 -- I don't understand the issue when these >>>>>> SRD> two >>>>>> paragraphs are taken together. >>>>>>> 18. clause 4.1, 8th paragraph, last sentence: >>>>>>> Should read: "Lack of the OC-Supported-Features AVP in the request >>>>>>> message indicates that there is no downstream reacting node for the >>>>>>> transaction." >>>>>> SRD> I think you mean clause 4.1.2. I don't see the need for the >>>>>> change. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not >>>>>> correct. It should either read: "Lack of the OC-Supported-Feature >>>>>> AVP in the request message indicates to the reporting node that >>>>>> there is no reacting node for the transaction" or as proposed above. >>>>> I don't see a reason for the change. Original text seem correct to me. >>>>> >>>>>>> 19. clause 4.1, last sentence: >>>>>>> Should read: "An agent MAY replace the OC-Supported-Features AVP >>>>>>> carried in answer messages." This replacement must follow general >>>>>>> rules. Its not so that the agent may do what ever it wants to. The >>>>>>> decision must be based on whether or not the agent has replaced the >>>>>>> OC-S-F in the corresponding request. >>>>>> SRD> What is the difference between modify and replace? I am ok with >>>>>> removing this statement until we have the agent behavior discussion. >>>>>> I thought I had taken the agent specific statements out of this >>>>>> version. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with >>>>>> identical values. You remove what has been received in and insert >>>>>> your own stuff. >>>>> Agent (proxy) can always do that i.e. modify the APV contents. >>>>> Obviously if an agent tampers the OC-Supported-Features AVP it needs >>>>> to know what it is doing. In general agree with the clarification but >>>>> not with the proposed text. >>>>> >>>>> - Jouni >>>>> >>>>>>> 20. clause 5.2, 1st sentence: >>>>>>> Should read: "A reporting node using the loss algorithm must use >>>>>>> the OC-Reduction-Percentage AVP (Section 6.7) to indicated the >>>>>>> desired percentage of traffic reduction." >>>>>> SRD> Agreed. >>>>>>> 21. clause 5.2, last sentence: >>>>>>> Should read: "Editor's note: The above duplicates what is in the >>>>>>> OC-Reduction-Percentage AVP section and can probably be removed." >>>>>> SRD> Yes, bad wording. The note will be removed, bad wording and >>>>>> all, >>>>>> once there is a discussion on if this is redundant. >>>>>>> 22. clause 5.4, 6th paragraph: >>>>>>> Should read: "If the reacting node does not receive a an OLR in the >>>>>>> answer that corresponds to the probe request messages sent to the >>>>>>> formally overloaded node then the reacting node should slowly >>>>>>> increase the rate of traffic sent to the overloaded node." >>>>>> SRD Agreed, this is more clear. >>>>>>> Best regards >>>>>>> Ulrich >>>>>>> >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>>>> Donovan >>>>>>> Sent: Saturday, July 05, 2014 9:42 PM >>>>>>> To: dime@ietf.org >>>>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>>> >>>>>>> All, >>>>>>> >>>>>>> This version of the DOIC draft is a restructuring of previously >>>>>>> agreed to content. >>>>>>> >>>>>>> The master plan for the restructuring is in Appendix C. This >>>>>>> outlines where material from -02 was moved in -03. >>>>>>> >>>>>>> For those interested, the work was done in steps, with a snapshot >>>>>>> for >>>>>>> each step available here: >>>>>>> >>>>>>> https://github.com/jounikor/draft-docdt-dime-ovli >>>>>>> >>>>>>> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >>>>>>> >>>>>>> where nn indicates the subversion and "text" indicates the focus for >>>>>>> that subversion. >>>>>>> >>>>>>> The next step will be to resolve open issues already identified and >>>>>>> those yet those yet to be identified. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>>>> directories. >>>>>>>> This draft is a work item of the Diameter Maintenance and >>>>>>>> Extensions Working Group of the IETF. >>>>>>>> >>>>>>>> Title : Diameter Overload Indication >>>>>>>> Conveyance >>>>>>>> Authors : Jouni Korhonen >>>>>>>> Steve Donovan >>>>>>>> Ben Campbell >>>>>>>> Lionel Morand >>>>>>>> Filename : draft-ietf-dime-ovli-03.txt >>>>>>>> Pages : 48 >>>>>>>> Date : 2014-07-03 >>>>>>>> >>>>>>>> Abstract: >>>>>>>> This specification documents a Diameter Overload Control >>>>>>>> (DOC) base >>>>>>>> solution and the dissemination of the overload report >>>>>>>> information. >>>>>>>> >>>>>>>> Requirements >>>>>>>> >>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>>>>>>> >>>>>>>> There's also a htmlized version available at: >>>>>>>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>>>>>>> >>>>>>>> A diff from the previous version is available at: >>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-03 >>>>>>>> >>>>>>>> >>>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>>> submission until the htmlized version and diff are available at >>>>>>>> tools.ietf.org. >>>>>>>> >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> DiME mailing list >>>>>>>> DiME@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>> DiME@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>>> >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >> > From nobody Mon Jul 21 11:17:14 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6F31A0350 for ; Mon, 21 Jul 2014 11:17:10 -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, SPF_NEUTRAL=0.779] autolearn=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 I0_rjAKTVXsj for ; Mon, 21 Jul 2014 11:17:08 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 63F3B1A0345 for ; Mon, 21 Jul 2014 11:17:08 -0700 (PDT) Received: from [174.142.25.230] (port=55332 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X9I8z-0003UU-97; Mon, 21 Jul 2014 11:17:07 -0700 Message-ID: <53CD591D.1040809@usdonovans.com> Date: Mon, 21 Jul 2014 14:17:01 -0400 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jouni Korhonen , "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <53CD2962.6060403@gmail.com> <53CD4379.3010203@usdonovans.com> <53CD5188.1010009@gmail.com> In-Reply-To: <53CD5188.1010009@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/O3lPVg-K586e97VOIjpNOBDhmRA Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 18:17:11 -0000 Inline... On 7/21/14, 1:44 PM, Jouni Korhonen wrote: > Steve, > > A bit more inline. > > 7/21/2014 7:44 PM, Steve Donovan kirjoitti: >> >> On 7/21/14, 10:53 AM, Jouni Korhonen wrote: >>> Steve, >>> >>> 7/21/2014 5:29 PM, Steve Donovan kirjoitti: >>>> Ulrich, >>>> >>>> I am not arguing that all agents should take an active role in the >>>> handling of all overload reports. What I am arguing is that there are >>>> scenarios where an agent must take an active role in DOIC to ensure >>>> that >>>> a requested reduction in traffic an be achieved. >>>> >>>> For DOIC to work a carrier cannot turn off all DOIC behavior in >>>> agents, >>>> as suggested by Jouni. >>> >>> Why? If you have a hierarchy of agents I don't see a reason why some >>> of those could be just "vanilla agents" or DOIC agents with >>> functionality turned off. Not arguing such deployment makes sense but >>> the protocol solution should be able to cope with that. >> SRD> I agree that some of the agents can have DOIC behavior turned off, >> as long as the agent in question does not have a direct transport >> connection to a Diameter node that could generate a host report. > > Ok. One more thing. If there is an agent that either has no DOIC > capability or it is turned off the outcome can be > non-optimal/non-desired, but that should not break anything, right? In > that light I do not understand the direct peer connection requirement > since if the agent allows turning off the DOIC functionally such > deployment can be done irrespective what the RFC says (e.g. > misconfiguration or for a specific reason). Things don't work if the Diameter nodes that have direct transport connections to overloaded servers do not support DOIC. We illustrated that use case in the draft in the section about non supporting agents with the statement that that specific deployment scenario should be avoided. If an operator wants to deploy a network that doesn't not properly handle overload then they are free to do so. We cannot prevent that from happening. We do need to have a mechanism that does allow sane operators to deploy their network in a way that properly handles overload. This requires us to recognize that agents will be required to react to overload reports. Do you disagree with this? > > - Jouni > > >>> >>> - Jouni >>> >>>> >>>> I agree that in your scenario below, a1 does not need to take an >>>> active >>>> role in reducing traffic when c supports DOIC. a1 should take an >>>> active >>>> role when c does not support DOIC. The problem is that a1 does not >>>> know >>>> in advance whether c supports DOIC so it will need to inspect all >>>> transactions for the presence of OC-S-F to determine if it needs to >>>> handle overload reports for a non supporting client. >>>> >>>> Does that mean a1 is transparent if it inspects all requests and does >>>> nothing in the case where there is c supports DOIC? >>>> >>>> Does transparent mean that there is no observable difference in the >>>> DOIC >>>> AVPs that pass through the agent or does it mean that there is no >>>> observable difference in how transactions are handled by the DOIC >>>> agent? >>>> >>>> I'm guessing that we have multiple assumptions on what transparent >>>> means >>>> and, if we are going to continue saying agents should be transparent >>>> then we need a definition of transparent. >>>> >>>> I think for this use case, we need the following normative >>>> statements in >>>> the draft for handling of abatement of realm-routed requests? I think >>>> this is general behavior and should go in the section on handling of >>>> overload reports. >>>> >>>> "DOIC nodes with a direct transport connection to a reporting node >>>> that >>>> has an active overload report must handle abatement of realm-routed >>>> requests. The preferred method for handling abatement of realm-routed >>>> requests is diversion, where the node with the direct transport >>>> connection routes the request to an alternative server that is able to >>>> handle the request. If there is no alternative server with the needed >>>> capacity to handle the request then the DOIC node must/should throttle >>>> the necessary requests to meet the requested reduction in traffic." >>>> >>>> If we can agree on this then we can move on to the next agent based >>>> use >>>> case. >>>> >>>> Regards, >>>> >>>> Steve >>>> >>>> On 7/21/14, 9:47 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>>> Steve, >>>>> >>>>> The example you show is absolutely valid and 100% inline with A) >>>>> to F) >>>>> - (assuming that all servers can serve any request). >>>>> However, there are other scenarios like: >>>>> >>>>> >>>>> +--+ >>>>> /--|s1| >>>>> +-+ +--+ +--+ / +--+ >>>>> |c|--- |a1|--|a2|== ... >>>>> +-+ +--+ +--+ \ +--+ >>>>> \--|sn| >>>>> +--+ >>>>> >>>>> Here I think a1 should be transparent even when DOICable. >>>>> a1 does not take the role of a reacting node since c supports DOIC. >>>>> a1 does not perform server selection and therefore does not take the >>>>> role of a reporting node (for realm-reports). >>>>> >>>>> Ulrich >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] >>>>> Sent: Monday, July 21, 2014 3:16 PM >>>>> To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - >>>>> DE/Munich); dime@ietf.org >>>>> Subject: Transparent agents (was Re: [Dime] I-D Action: >>>>> draft-ietf-dime-ovli-03.txt) >>>>> >>>>> Ok, let's see if it's possible to completely turn off all DOIC >>>>> behavior >>>>> in agents and still be able to reduce traffic to a server that >>>>> sends a >>>>> host overload report. >>>>> >>>>> Assume the following agent based deployment: >>>>> >>>>> +--+ >>>>> /--|s1| >>>>> +-+ +-+ / +--+ >>>>> |c|--|a|== ... >>>>> +-+ +-+ \ +--+ >>>>> \--|sn| >>>>> +--+ >>>>> >>>>> Assume that there is a large number of servers, say 50. >>>>> >>>>> Now, assume that the Diameter application in question exclusively >>>>> uses >>>>> realm-routed requests - 100% of requests sent by the client do NOT >>>>> have >>>>> a destination-host AVP. >>>>> >>>>> Now assume that server s1 sends an host type overload report >>>>> requesting >>>>> a reduction of 20% using the loss algorithm. >>>>> >>>>> Also assume that the unused capacity in servers s2 through s50 is >>>>> sufficient to handle the traffic that would have been sent to s1. As >>>>> such, there is no reason to throttle any requests. >>>>> >>>>> There are no host routed requests for this application and the client >>>>> does not have a direct transport connection to server s1. The only >>>>> option a client has is to hand the request off to the agent for >>>>> routing. >>>>> >>>>> The proposal in the agent cases draft is that the agent diverts >>>>> 20% of >>>>> the realm routed requests that would have been sent to server s1 to >>>>> servers s2 through s50. >>>>> >>>>> If DOIC behavior is turned off in the agent then how will the traffic >>>>> routed to s1 be reduced? >>>>> >>>>> Steve >>>>> >>>>> On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote: >>>>>> +1 for the following aspect. >>>>>> >>>>>>>>> Agents must take an active role in even the most basic case for >>>>>>>>> overload handling to work, so they cannot be transparent. >>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do >>>>>>>> not support DOIC are transparent. Agents that support DOIC in most >>>>>>>> cases behave like non supporting agents. >>>>>>> I am towards Ulrich's view here. Even for an agent that understands >>>>>>> DOIC it is up to the local policy whether it is transparent or >>>>>>> takes >>>>>>> an active role. >>>>>> -----Original Message----- >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni >>>>>> Korhonen >>>>>> Sent: Monday, July 21, 2014 12:26 AM >>>>>> To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; >>>>>> dime@ietf.org >>>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>> >>>>>> Some comments inline.. >>>>>> >>>>>> 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >>>>>>> Steve, >>>>>>> please see my response inline. >>>>>>> >>>>>>> Regards >>>>>>> Ulrich >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>>>> Donovan >>>>>>> Sent: Tuesday, July 15, 2014 3:53 PM >>>>>>> To: dime@ietf.org >>>>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>>> >>>>>>> Ulrich, >>>>>>> >>>>>>> Thanks for the comments. Please see my responses inline. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Steve >>>>>>> On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>>>>>> Hi Steve, >>>>>>>> here are my comments. >>>>>>>> They focus on new text you introduced. I agree that restructuring >>>>>>>> may require new text, however, I believe that with the new text a >>>>>>>> new concepts is introduced which macerates the agreed end-to-end >>>>>>>> concept and allows all DOIC agents on the path to do what they >>>>>>>> wants, so that we end up in a hop-by-hop concept. >>>>>>> SRD> We have never had an agreement on end-to-end versus hop-by-hop >>>>>>> SRD> and >>>>>>> I believe that we will end up with a hybrid of the two. We have >>>>>>> open >>>>>>> issues on agent behavior that Ben and I are attempting to address >>>>>>> with >>>>>>> the agent cases draft. >>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop >>>>>>> approach of the roach draft was reason not to proceed with that >>>>>>> draft. >>>>>>> >>>>>>> SRD> That said, this type of restructuring of the document is >>>>>>> likely >>>>>>> SRD> to >>>>>>> put agreed to behavior in a new light. If there are cases where I >>>>>>> have implied changes to agreed to normative behavior, or if the >>>>>>> informative text is not accurate, then these things need to be >>>>>>> corrected. >>>>>>>> 1. clause 2.3, second paragraph: >>>>>>>> Should read: "Reacting nodes indicate support for DOIC by >>>>>>>> including >>>>>>>> the OC-Supported-Features AVP into all request messages originated >>>>>>>> or relayed by the Reacting node." >>>>>>> SRD> You mean clause 3.2. >>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes >>>>>>> I agree with the change. >>>>>>>> 2. clause 2.3, 3rd paragraph, 1st sentence: >>>>>>>> OC-xxx AVPs must not be included in an answer message when the >>>>>>>> corresponding request did not contain an OC-S-F AVP. >>>>>>> SRD> Agreed. >>>>>>>> 3. clause 3.3, 7th paragraph: >>>>>>>> Should read "The reporting node only includes an indication of >>>>>>>> support for one overload abatement algorithm. This is the >>>>>>>> algorithm that the reporting node intends to use should it >>>>>>>> enter an >>>>>>>> overload condition or requests to use while it actually is in an >>>>>>>> overload condition. Reacting nodes can use the indicated overload >>>>>>>> abatement algorithm to prepare for possible overload reports and >>>>>>>> must use the indicated overload abatement algorithm if traffic >>>>>>>> reduction is actually requested." >>>>>>> SRD. OK. >>>>>>>> 4. clause 3.3, 10th paragraph: >>>>>>>> The 1st sentence is misleading. In the general case, agents on the >>>>>>>> path between reacting node and reporting node are transparent. I >>>>>>>> agree that there are exceptions to the general case where an agent >>>>>>>> on the path is not transparent, but then the agent IS the >>>>>>>> reporting >>>>>>>> node (reporting to the sender of the request) and it also IS the >>>>>>>> reacting node (reacting on reports received from the upstream >>>>>>>> reporting node). >>>>>>>> The first 3 words of the second sentence "in this case" need >>>>>>>> clarification: "In the case where an agent takes the role of a >>>>>>>> reporting node (reporting to the downstream reacting node) and at >>>>>>>> the same time takes the role of a reacting node (reacting on >>>>>>>> reports received from an upstream reporting node)". >>>>>>>> Last sentence: Its not an update but a replacement. The two DOIC >>>>>>>> associations are handled independently. >>>>>>> SRD> I don't know what you mean when you say an agent is >>>>>>> transparent. >>>>>>> Agents must take an active role in even the most basic case for >>>>>>> overload handling to work, so they cannot be transparent. >>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do >>>>>>> not >>>>>>> support DOIC are transparent. Agents that support DOIC in most >>>>>>> cases >>>>>>> behave like non supporting agents. >>>>>> I am towards Ulrich's view here. Even for an agent that understands >>>>>> DOIC it is up to the local policy whether it is transparent or takes >>>>>> an active role. >>>>>> >>>>>>>> 5. clause 3.3, last paragraph: >>>>>>>> General rules shall be followed for each of the two associations >>>>>>>> separately. The content of the OC-S-F AVP sent by the agent >>>>>>>> upstream should reflect what the agent is able and willing to >>>>>>>> support (as always). >>>>>>> SRD> What two associations? Is there one association >>>>>>> (end-to-end) or >>>>>>> SRD> is >>>>>>> the an association on both sides of the agent (hop-by-hop)? Or is >>>>>>> there an association that involves three entities, the reporting >>>>>>> node, >>>>>>> an agent reacting node for realm-routed requests and a >>>>>>> transaction-client reporting node for handling host-routed >>>>>>> requests? >>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, >>>>>>> There is >>>>>>> one association between C and A, and one association between A and >>>>>>> S. Both associations are "end-to-end" as there may be transparent >>>>>>> (supporting or non-supporting) agents in the middle. >>>>>>>> 6. clause 3.4, 2nd paragraph: >>>>>>>> Should read: "The OC-OLR AVP is referred to as an overload report. >>>>>>>> The OC-OLR AVP includes the type of report, a sequence number, the >>>>>>>> length of time that the report is valid and abatement algorithm >>>>>>>> specific AVPs." >>>>>>> SRD> The sequence number is being used as an overload report ID. I >>>>>>> can >>>>>>> make the change but I don't see it as necessary. >>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. >>>>>> OK to do the change. >>>>>> >>>>>>>> 7. clause 3.4, 4th paragraph, 2nd sentence: >>>>>>>> I cannot understand this sentence. Probably only simple typos >>>>>>>> but I >>>>>>>> don't know. >>>>>>> SRD> Yes, a typo (this instead of the) and awkward wording. How >>>>>>> about >>>>>>> "This applies to requests that contain the Destination-Host AVP >>>>>>> with a >>>>>>> DiameterIdentity that matches the overload report. >>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that >>>>>>> contain a DiameterIdentity in the Destination-Host AVP that matches >>>>>>> the reporting host's DiameterIdentity" >>>>>> I would be inclined to keep the text Steve proposed. But both are ok >>>>>> actually. >>>>>> >>>>>>>> 8. clause 3.4, 4th paragraph last 2 sentences: >>>>>>>> I don't understand and probably do not agree. >>>>>>> SRD> See above. >>>>>>>> 9. clause 3.5, 3rd paragraph, last word: >>>>>>>> Should read "communicated" >>>>>>> SRD> Agreed. >>>>>>>> 10. clause 3.5, 4th paragraph, 1st sentence: >>>>>>>> I don't understand. I can understand: "Reporting nodes use the >>>>>>>> OC-OLR AVP to communicate overload occurances towards reacting >>>>>>>> nodes." >>>>>>> SRD> Who else would reports be sent to? >>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement >>>>>>> algorithm but the reporting node that uses the OC-OLR AVP to >>>>>>> communicate overload occurances. >>>>>> Agree. >>>>>> >>>>>>>> 11. clause 4.1, 3rd paragraph, last 4 words: >>>>>>>> may be misleading. A DOIC supporting agent sitting between DOIC >>>>>>>> supporting client and DOIC supporting Server is transparent with >>>>>>>> regard to DOIC. This agent does not indicate DOIC support. >>>>>>> SRD> I disagree. >>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. >>>>>>> Should be: ...This agent does not indicate its DOIC support, rather >>>>>>> it transparently forwards the client's DOIC support. >>>>>> Agree with Ulrich on the intent of agent behavior but not with the >>>>>> proposed text change. >>>>>> >>>>>>>> 12. clause 4.1, 4th paragraph, 2nd sentence: >>>>>>>> Should read:"If a request message handled by the DOIC agent does >>>>>>>> not include the OC-Supported-Features AVP then the DOIC agent >>>>>>>> inserts the AVP." >>>>>>> SRD> That is what it already says. >>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... >>>>>> OC-Supported-Features can be in both request and answer, thus "If a >>>>>> message" in that sense is correct. >>>>>> >>>>>>>> 13. clause 4.1, last sentence: >>>>>>>> Should read "If the message already has the AVP then the agent >>>>>>>> either leaves it unchanged in the relayed message or replaces >>>>>>>> it to >>>>>>>> reflect the features the agent is able and willing to support." >>>>>>>> Clarification is needed to say that strict rules must be followed >>>>>>>> by the agent to select the correct option. These rules take into >>>>>>>> account whether the request is host-routed or relam-routed and >>>>>>>> whether the agent is configured to select the server for >>>>>>>> realm-routed requests. >>>>>>> SRD> This is a topic on agent behavior that is addressed in the >>>>>>> agent >>>>>>> cases draft. I'll leave the discussion for what the wording >>>>>>> should be >>>>>>> to the discussion on that draft. >>>>>>>> 14. clause 4.1.2, 2nd paragraph: >>>>>>>> Should read: "Based on the content of the OC-Supported-Features >>>>>>>> AVP >>>>>>>> in the request message, the reporting node knows what overload >>>>>>>> control functionality is supported by the reacting node. The >>>>>>>> reporting node then acts accordingly for the subsequent answer >>>>>>>> messages it initiates for the transaction." >>>>>>> SRD> It would be easier if you didn't make it difficult to >>>>>>> understand >>>>>>> the change you are proposing. I think you are proposing changing >>>>>>> node(s) to node. I don't agree but that will be addressed as >>>>>>> part of >>>>>>> the agent cases discussion. >>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing >>>>>>> two sentences? The proposal is to insert "is" between >>>>>>> "functionality" and "supported", to add "the" between "by" and >>>>>>> "reacting", to replace "node(s)" with "node", and to insert "for >>>>>>> the >>>>>>> transaction" after "initiates". >>>>>> Agree with the proposed change. >>>>>> >>>>>>>> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >>>>>>>> Should read: "message's" >>>>>>> SRD> I'm assuming you mean section 4.1.2. >>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, >>>>>>> 18, >>>>>>> and 19. >>>>>>> I agree to the change. >>>>>>>> 16. clause 4.1, 6th paragraph: >>>>>>>> This should be left to the (future) specification that introduces >>>>>>>> other DOIC features. >>>>>>>> >>>>>>>> 17. clause 4.1, 7th paragraph, last 6 words: >>>>>>>> should be based on requiements set by the (future) specification >>>>>>>> that >>>>>>>> introduces other DOIC features >>>>>>> SRD> Again, clause 4.1.2 -- I don't understand the issue when these >>>>>>> SRD> two >>>>>>> paragraphs are taken together. >>>>>>>> 18. clause 4.1, 8th paragraph, last sentence: >>>>>>>> Should read: "Lack of the OC-Supported-Features AVP in the request >>>>>>>> message indicates that there is no downstream reacting node for >>>>>>>> the >>>>>>>> transaction." >>>>>>> SRD> I think you mean clause 4.1.2. I don't see the need for the >>>>>>> change. >>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not >>>>>>> correct. It should either read: "Lack of the OC-Supported-Feature >>>>>>> AVP in the request message indicates to the reporting node that >>>>>>> there is no reacting node for the transaction" or as proposed >>>>>>> above. >>>>>> I don't see a reason for the change. Original text seem correct >>>>>> to me. >>>>>> >>>>>>>> 19. clause 4.1, last sentence: >>>>>>>> Should read: "An agent MAY replace the OC-Supported-Features AVP >>>>>>>> carried in answer messages." This replacement must follow general >>>>>>>> rules. Its not so that the agent may do what ever it wants to. The >>>>>>>> decision must be based on whether or not the agent has replaced >>>>>>>> the >>>>>>>> OC-S-F in the corresponding request. >>>>>>> SRD> What is the difference between modify and replace? I am ok >>>>>>> with >>>>>>> removing this statement until we have the agent behavior >>>>>>> discussion. >>>>>>> I thought I had taken the agent specific statements out of this >>>>>>> version. >>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with >>>>>>> identical values. You remove what has been received in and insert >>>>>>> your own stuff. >>>>>> Agent (proxy) can always do that i.e. modify the APV contents. >>>>>> Obviously if an agent tampers the OC-Supported-Features AVP it needs >>>>>> to know what it is doing. In general agree with the clarification >>>>>> but >>>>>> not with the proposed text. >>>>>> >>>>>> - Jouni >>>>>> >>>>>>>> 20. clause 5.2, 1st sentence: >>>>>>>> Should read: "A reporting node using the loss algorithm must use >>>>>>>> the OC-Reduction-Percentage AVP (Section 6.7) to indicated the >>>>>>>> desired percentage of traffic reduction." >>>>>>> SRD> Agreed. >>>>>>>> 21. clause 5.2, last sentence: >>>>>>>> Should read: "Editor's note: The above duplicates what is in the >>>>>>>> OC-Reduction-Percentage AVP section and can probably be removed." >>>>>>> SRD> Yes, bad wording. The note will be removed, bad wording and >>>>>>> all, >>>>>>> once there is a discussion on if this is redundant. >>>>>>>> 22. clause 5.4, 6th paragraph: >>>>>>>> Should read: "If the reacting node does not receive a an OLR in >>>>>>>> the >>>>>>>> answer that corresponds to the probe request messages sent to the >>>>>>>> formally overloaded node then the reacting node should slowly >>>>>>>> increase the rate of traffic sent to the overloaded node." >>>>>>> SRD Agreed, this is more clear. >>>>>>>> Best regards >>>>>>>> Ulrich >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>>>>> Donovan >>>>>>>> Sent: Saturday, July 05, 2014 9:42 PM >>>>>>>> To: dime@ietf.org >>>>>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>>>> >>>>>>>> All, >>>>>>>> >>>>>>>> This version of the DOIC draft is a restructuring of previously >>>>>>>> agreed to content. >>>>>>>> >>>>>>>> The master plan for the restructuring is in Appendix C. This >>>>>>>> outlines where material from -02 was moved in -03. >>>>>>>> >>>>>>>> For those interested, the work was done in steps, with a snapshot >>>>>>>> for >>>>>>>> each step available here: >>>>>>>> >>>>>>>> https://github.com/jounikor/draft-docdt-dime-ovli >>>>>>>> >>>>>>>> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >>>>>>>> >>>>>>>> where nn indicates the subversion and "text" indicates the >>>>>>>> focus for >>>>>>>> that subversion. >>>>>>>> >>>>>>>> The next step will be to resolve open issues already identified >>>>>>>> and >>>>>>>> those yet those yet to be identified. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Steve >>>>>>>> >>>>>>>> >>>>>>>> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>>> Internet-Drafts >>>>>>>>> directories. >>>>>>>>> This draft is a work item of the Diameter Maintenance and >>>>>>>>> Extensions Working Group of the IETF. >>>>>>>>> >>>>>>>>> Title : Diameter Overload Indication >>>>>>>>> Conveyance >>>>>>>>> Authors : Jouni Korhonen >>>>>>>>> Steve Donovan >>>>>>>>> Ben Campbell >>>>>>>>> Lionel Morand >>>>>>>>> Filename : draft-ietf-dime-ovli-03.txt >>>>>>>>> Pages : 48 >>>>>>>>> Date : 2014-07-03 >>>>>>>>> >>>>>>>>> Abstract: >>>>>>>>> This specification documents a Diameter Overload Control >>>>>>>>> (DOC) base >>>>>>>>> solution and the dissemination of the overload report >>>>>>>>> information. >>>>>>>>> >>>>>>>>> Requirements >>>>>>>>> >>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>>>>>>>> >>>>>>>>> There's also a htmlized version available at: >>>>>>>>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>>>>>>>> >>>>>>>>> A diff from the previous version is available at: >>>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-03 >>>>>>>>> >>>>>>>>> >>>>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>>>> submission until the htmlized version and diff are available at >>>>>>>>> tools.ietf.org. >>>>>>>>> >>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> DiME mailing list >>>>>>>>> DiME@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> DiME mailing list >>>>>>>> DiME@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>> DiME@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>> >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>> DiME@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>> >> > From nobody Mon Jul 21 12:02:23 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257151A039F for ; Mon, 21 Jul 2014 12:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 0Bcsy0p8d4-u for ; Mon, 21 Jul 2014 12:02:17 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9217C1A0395 for ; Mon, 21 Jul 2014 12:02:04 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w62so8096934wes.29 for ; Mon, 21 Jul 2014 12:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=AdFlMVzDZbrbAL2Rlf8VyDCLTar2yyP7rR+B95642xc=; b=P4aRovYuMKxu6dXUsMsVnB9qt8pLLOrAB3fqSvqUSDpWgfqqd1V78e/rnBAF94wJdh AU1ko6UEE5Ipapv8GbsOea/OmiWyzNYH7351e84eJ2FlB/ChvHkP5wPatLM1qRVgxg4N I2z0UphYGZMseX0UnxrASDTniYxbNS08U3+WndhZRqsKqNiwkn06ZGL/8G39pNGBLMQr tH+yRBLXvkzvRaXBHNCpS60OBAQcoCluesQwcl8eDSC1d79bEenaNhDxOPFUcX+bwsFT 9ZRczdUgupJlXgvBBRbGgU50y6+VqAoWQVQGCaoOoZUleLB2+FWFhml8kuC8kkCKv3E5 iAuw== X-Received: by 10.180.7.230 with SMTP id m6mr7008267wia.3.1405969323036; Mon, 21 Jul 2014 12:02:03 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:d5fb:9652:9d68:924c? ([2001:67c:370:176:d5fb:9652:9d68:924c]) by mx.google.com with ESMTPSA id ek3sm39634536wjd.17.2014.07.21.12.02.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 12:02:02 -0700 (PDT) Message-ID: <53CD63A6.6020305@gmail.com> Date: Mon, 21 Jul 2014 22:01:58 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steve Donovan , "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <53CD2962.6060403@gmail.com> <53CD4379.3010203@usdonovans.com> <53CD5188.1010009@gmail.com> <53CD591D.1040809@usdonovans.com> In-Reply-To: <53CD591D.1040809@usdonovans.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/IU4sabNkUnAlXTiJ036uOkVXq_M Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 19:02:22 -0000 Steve, Inline. 7/21/2014 9:17 PM, Steve Donovan kirjoitti: > Inline... > On 7/21/14, 1:44 PM, Jouni Korhonen wrote: >> Steve, >> >> A bit more inline. >> >> 7/21/2014 7:44 PM, Steve Donovan kirjoitti: >>> >>> On 7/21/14, 10:53 AM, Jouni Korhonen wrote: >>>> Steve, >>>> >>>> 7/21/2014 5:29 PM, Steve Donovan kirjoitti: >>>>> Ulrich, >>>>> >>>>> I am not arguing that all agents should take an active role in the >>>>> handling of all overload reports. What I am arguing is that there are >>>>> scenarios where an agent must take an active role in DOIC to ensure >>>>> that >>>>> a requested reduction in traffic an be achieved. >>>>> >>>>> For DOIC to work a carrier cannot turn off all DOIC behavior in >>>>> agents, >>>>> as suggested by Jouni. >>>> >>>> Why? If you have a hierarchy of agents I don't see a reason why some >>>> of those could be just "vanilla agents" or DOIC agents with >>>> functionality turned off. Not arguing such deployment makes sense but >>>> the protocol solution should be able to cope with that. >>> SRD> I agree that some of the agents can have DOIC behavior turned off, >>> as long as the agent in question does not have a direct transport >>> connection to a Diameter node that could generate a host report. >> >> Ok. One more thing. If there is an agent that either has no DOIC >> capability or it is turned off the outcome can be >> non-optimal/non-desired, but that should not break anything, right? In >> that light I do not understand the direct peer connection requirement >> since if the agent allows turning off the DOIC functionally such >> deployment can be done irrespective what the RFC says (e.g. >> misconfiguration or for a specific reason). > Things don't work if the Diameter nodes that have direct transport > connections to overloaded servers do not support DOIC. We illustrated Obviously. > that use case in the draft in the section about non supporting agents > with the statement that that specific deployment scenario should be > avoided. Should be avoided is fine. > If an operator wants to deploy a network that doesn't not properly > handle overload then they are free to do so. We cannot prevent that > from happening. We do need to have a mechanism that does allow sane Exactly.. and operators might have a reason to do so e.g. for temporarily. > operators to deploy their network in a way that properly handles > overload. This requires us to recognize that agents will be required to > react to overload reports. > > Do you disagree with this? I agree but I want to be clear on the wording with MUSTs and alike that the specification does not imply that all proxies must be upgraded for DOIC to work or that the operator cannot have a local policy that applies DOIC selectively. - Jouni >> >> - Jouni >> >> >>>> >>>> - Jouni >>>> >>>>> >>>>> I agree that in your scenario below, a1 does not need to take an >>>>> active >>>>> role in reducing traffic when c supports DOIC. a1 should take an >>>>> active >>>>> role when c does not support DOIC. The problem is that a1 does not >>>>> know >>>>> in advance whether c supports DOIC so it will need to inspect all >>>>> transactions for the presence of OC-S-F to determine if it needs to >>>>> handle overload reports for a non supporting client. >>>>> >>>>> Does that mean a1 is transparent if it inspects all requests and does >>>>> nothing in the case where there is c supports DOIC? >>>>> >>>>> Does transparent mean that there is no observable difference in the >>>>> DOIC >>>>> AVPs that pass through the agent or does it mean that there is no >>>>> observable difference in how transactions are handled by the DOIC >>>>> agent? >>>>> >>>>> I'm guessing that we have multiple assumptions on what transparent >>>>> means >>>>> and, if we are going to continue saying agents should be transparent >>>>> then we need a definition of transparent. >>>>> >>>>> I think for this use case, we need the following normative >>>>> statements in >>>>> the draft for handling of abatement of realm-routed requests? I think >>>>> this is general behavior and should go in the section on handling of >>>>> overload reports. >>>>> >>>>> "DOIC nodes with a direct transport connection to a reporting node >>>>> that >>>>> has an active overload report must handle abatement of realm-routed >>>>> requests. The preferred method for handling abatement of realm-routed >>>>> requests is diversion, where the node with the direct transport >>>>> connection routes the request to an alternative server that is able to >>>>> handle the request. If there is no alternative server with the needed >>>>> capacity to handle the request then the DOIC node must/should throttle >>>>> the necessary requests to meet the requested reduction in traffic." >>>>> >>>>> If we can agree on this then we can move on to the next agent based >>>>> use >>>>> case. >>>>> >>>>> Regards, >>>>> >>>>> Steve >>>>> >>>>> On 7/21/14, 9:47 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>>>> Steve, >>>>>> >>>>>> The example you show is absolutely valid and 100% inline with A) >>>>>> to F) >>>>>> - (assuming that all servers can serve any request). >>>>>> However, there are other scenarios like: >>>>>> >>>>>> >>>>>> +--+ >>>>>> /--|s1| >>>>>> +-+ +--+ +--+ / +--+ >>>>>> |c|--- |a1|--|a2|== ... >>>>>> +-+ +--+ +--+ \ +--+ >>>>>> \--|sn| >>>>>> +--+ >>>>>> >>>>>> Here I think a1 should be transparent even when DOICable. >>>>>> a1 does not take the role of a reacting node since c supports DOIC. >>>>>> a1 does not perform server selection and therefore does not take the >>>>>> role of a reporting node (for realm-reports). >>>>>> >>>>>> Ulrich >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] >>>>>> Sent: Monday, July 21, 2014 3:16 PM >>>>>> To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - >>>>>> DE/Munich); dime@ietf.org >>>>>> Subject: Transparent agents (was Re: [Dime] I-D Action: >>>>>> draft-ietf-dime-ovli-03.txt) >>>>>> >>>>>> Ok, let's see if it's possible to completely turn off all DOIC >>>>>> behavior >>>>>> in agents and still be able to reduce traffic to a server that >>>>>> sends a >>>>>> host overload report. >>>>>> >>>>>> Assume the following agent based deployment: >>>>>> >>>>>> +--+ >>>>>> /--|s1| >>>>>> +-+ +-+ / +--+ >>>>>> |c|--|a|== ... >>>>>> +-+ +-+ \ +--+ >>>>>> \--|sn| >>>>>> +--+ >>>>>> >>>>>> Assume that there is a large number of servers, say 50. >>>>>> >>>>>> Now, assume that the Diameter application in question exclusively >>>>>> uses >>>>>> realm-routed requests - 100% of requests sent by the client do NOT >>>>>> have >>>>>> a destination-host AVP. >>>>>> >>>>>> Now assume that server s1 sends an host type overload report >>>>>> requesting >>>>>> a reduction of 20% using the loss algorithm. >>>>>> >>>>>> Also assume that the unused capacity in servers s2 through s50 is >>>>>> sufficient to handle the traffic that would have been sent to s1. As >>>>>> such, there is no reason to throttle any requests. >>>>>> >>>>>> There are no host routed requests for this application and the client >>>>>> does not have a direct transport connection to server s1. The only >>>>>> option a client has is to hand the request off to the agent for >>>>>> routing. >>>>>> >>>>>> The proposal in the agent cases draft is that the agent diverts >>>>>> 20% of >>>>>> the realm routed requests that would have been sent to server s1 to >>>>>> servers s2 through s50. >>>>>> >>>>>> If DOIC behavior is turned off in the agent then how will the traffic >>>>>> routed to s1 be reduced? >>>>>> >>>>>> Steve >>>>>> >>>>>> On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote: >>>>>>> +1 for the following aspect. >>>>>>> >>>>>>>>>> Agents must take an active role in even the most basic case for >>>>>>>>>> overload handling to work, so they cannot be transparent. >>>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do >>>>>>>>> not support DOIC are transparent. Agents that support DOIC in most >>>>>>>>> cases behave like non supporting agents. >>>>>>>> I am towards Ulrich's view here. Even for an agent that understands >>>>>>>> DOIC it is up to the local policy whether it is transparent or >>>>>>>> takes >>>>>>>> an active role. >>>>>>> -----Original Message----- >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni >>>>>>> Korhonen >>>>>>> Sent: Monday, July 21, 2014 12:26 AM >>>>>>> To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; >>>>>>> dime@ietf.org >>>>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>>> >>>>>>> Some comments inline.. >>>>>>> >>>>>>> 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >>>>>>>> Steve, >>>>>>>> please see my response inline. >>>>>>>> >>>>>>>> Regards >>>>>>>> Ulrich >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>>>>> Donovan >>>>>>>> Sent: Tuesday, July 15, 2014 3:53 PM >>>>>>>> To: dime@ietf.org >>>>>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>>>> >>>>>>>> Ulrich, >>>>>>>> >>>>>>>> Thanks for the comments. Please see my responses inline. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Steve >>>>>>>> On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>>>>>>> Hi Steve, >>>>>>>>> here are my comments. >>>>>>>>> They focus on new text you introduced. I agree that restructuring >>>>>>>>> may require new text, however, I believe that with the new text a >>>>>>>>> new concepts is introduced which macerates the agreed end-to-end >>>>>>>>> concept and allows all DOIC agents on the path to do what they >>>>>>>>> wants, so that we end up in a hop-by-hop concept. >>>>>>>> SRD> We have never had an agreement on end-to-end versus hop-by-hop >>>>>>>> SRD> and >>>>>>>> I believe that we will end up with a hybrid of the two. We have >>>>>>>> open >>>>>>>> issues on agent behavior that Ben and I are attempting to address >>>>>>>> with >>>>>>>> the agent cases draft. >>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop >>>>>>>> approach of the roach draft was reason not to proceed with that >>>>>>>> draft. >>>>>>>> >>>>>>>> SRD> That said, this type of restructuring of the document is >>>>>>>> likely >>>>>>>> SRD> to >>>>>>>> put agreed to behavior in a new light. If there are cases where I >>>>>>>> have implied changes to agreed to normative behavior, or if the >>>>>>>> informative text is not accurate, then these things need to be >>>>>>>> corrected. >>>>>>>>> 1. clause 2.3, second paragraph: >>>>>>>>> Should read: "Reacting nodes indicate support for DOIC by >>>>>>>>> including >>>>>>>>> the OC-Supported-Features AVP into all request messages originated >>>>>>>>> or relayed by the Reacting node." >>>>>>>> SRD> You mean clause 3.2. >>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes >>>>>>>> I agree with the change. >>>>>>>>> 2. clause 2.3, 3rd paragraph, 1st sentence: >>>>>>>>> OC-xxx AVPs must not be included in an answer message when the >>>>>>>>> corresponding request did not contain an OC-S-F AVP. >>>>>>>> SRD> Agreed. >>>>>>>>> 3. clause 3.3, 7th paragraph: >>>>>>>>> Should read "The reporting node only includes an indication of >>>>>>>>> support for one overload abatement algorithm. This is the >>>>>>>>> algorithm that the reporting node intends to use should it >>>>>>>>> enter an >>>>>>>>> overload condition or requests to use while it actually is in an >>>>>>>>> overload condition. Reacting nodes can use the indicated overload >>>>>>>>> abatement algorithm to prepare for possible overload reports and >>>>>>>>> must use the indicated overload abatement algorithm if traffic >>>>>>>>> reduction is actually requested." >>>>>>>> SRD. OK. >>>>>>>>> 4. clause 3.3, 10th paragraph: >>>>>>>>> The 1st sentence is misleading. In the general case, agents on the >>>>>>>>> path between reacting node and reporting node are transparent. I >>>>>>>>> agree that there are exceptions to the general case where an agent >>>>>>>>> on the path is not transparent, but then the agent IS the >>>>>>>>> reporting >>>>>>>>> node (reporting to the sender of the request) and it also IS the >>>>>>>>> reacting node (reacting on reports received from the upstream >>>>>>>>> reporting node). >>>>>>>>> The first 3 words of the second sentence "in this case" need >>>>>>>>> clarification: "In the case where an agent takes the role of a >>>>>>>>> reporting node (reporting to the downstream reacting node) and at >>>>>>>>> the same time takes the role of a reacting node (reacting on >>>>>>>>> reports received from an upstream reporting node)". >>>>>>>>> Last sentence: Its not an update but a replacement. The two DOIC >>>>>>>>> associations are handled independently. >>>>>>>> SRD> I don't know what you mean when you say an agent is >>>>>>>> transparent. >>>>>>>> Agents must take an active role in even the most basic case for >>>>>>>> overload handling to work, so they cannot be transparent. >>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do >>>>>>>> not >>>>>>>> support DOIC are transparent. Agents that support DOIC in most >>>>>>>> cases >>>>>>>> behave like non supporting agents. >>>>>>> I am towards Ulrich's view here. Even for an agent that understands >>>>>>> DOIC it is up to the local policy whether it is transparent or takes >>>>>>> an active role. >>>>>>> >>>>>>>>> 5. clause 3.3, last paragraph: >>>>>>>>> General rules shall be followed for each of the two associations >>>>>>>>> separately. The content of the OC-S-F AVP sent by the agent >>>>>>>>> upstream should reflect what the agent is able and willing to >>>>>>>>> support (as always). >>>>>>>> SRD> What two associations? Is there one association >>>>>>>> (end-to-end) or >>>>>>>> SRD> is >>>>>>>> the an association on both sides of the agent (hop-by-hop)? Or is >>>>>>>> there an association that involves three entities, the reporting >>>>>>>> node, >>>>>>>> an agent reacting node for realm-routed requests and a >>>>>>>> transaction-client reporting node for handling host-routed >>>>>>>> requests? >>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, >>>>>>>> There is >>>>>>>> one association between C and A, and one association between A and >>>>>>>> S. Both associations are "end-to-end" as there may be transparent >>>>>>>> (supporting or non-supporting) agents in the middle. >>>>>>>>> 6. clause 3.4, 2nd paragraph: >>>>>>>>> Should read: "The OC-OLR AVP is referred to as an overload report. >>>>>>>>> The OC-OLR AVP includes the type of report, a sequence number, the >>>>>>>>> length of time that the report is valid and abatement algorithm >>>>>>>>> specific AVPs." >>>>>>>> SRD> The sequence number is being used as an overload report ID. I >>>>>>>> can >>>>>>>> make the change but I don't see it as necessary. >>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. >>>>>>> OK to do the change. >>>>>>> >>>>>>>>> 7. clause 3.4, 4th paragraph, 2nd sentence: >>>>>>>>> I cannot understand this sentence. Probably only simple typos >>>>>>>>> but I >>>>>>>>> don't know. >>>>>>>> SRD> Yes, a typo (this instead of the) and awkward wording. How >>>>>>>> about >>>>>>>> "This applies to requests that contain the Destination-Host AVP >>>>>>>> with a >>>>>>>> DiameterIdentity that matches the overload report. >>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that >>>>>>>> contain a DiameterIdentity in the Destination-Host AVP that matches >>>>>>>> the reporting host's DiameterIdentity" >>>>>>> I would be inclined to keep the text Steve proposed. But both are ok >>>>>>> actually. >>>>>>> >>>>>>>>> 8. clause 3.4, 4th paragraph last 2 sentences: >>>>>>>>> I don't understand and probably do not agree. >>>>>>>> SRD> See above. >>>>>>>>> 9. clause 3.5, 3rd paragraph, last word: >>>>>>>>> Should read "communicated" >>>>>>>> SRD> Agreed. >>>>>>>>> 10. clause 3.5, 4th paragraph, 1st sentence: >>>>>>>>> I don't understand. I can understand: "Reporting nodes use the >>>>>>>>> OC-OLR AVP to communicate overload occurances towards reacting >>>>>>>>> nodes." >>>>>>>> SRD> Who else would reports be sent to? >>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement >>>>>>>> algorithm but the reporting node that uses the OC-OLR AVP to >>>>>>>> communicate overload occurances. >>>>>>> Agree. >>>>>>> >>>>>>>>> 11. clause 4.1, 3rd paragraph, last 4 words: >>>>>>>>> may be misleading. A DOIC supporting agent sitting between DOIC >>>>>>>>> supporting client and DOIC supporting Server is transparent with >>>>>>>>> regard to DOIC. This agent does not indicate DOIC support. >>>>>>>> SRD> I disagree. >>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. >>>>>>>> Should be: ...This agent does not indicate its DOIC support, rather >>>>>>>> it transparently forwards the client's DOIC support. >>>>>>> Agree with Ulrich on the intent of agent behavior but not with the >>>>>>> proposed text change. >>>>>>> >>>>>>>>> 12. clause 4.1, 4th paragraph, 2nd sentence: >>>>>>>>> Should read:"If a request message handled by the DOIC agent does >>>>>>>>> not include the OC-Supported-Features AVP then the DOIC agent >>>>>>>>> inserts the AVP." >>>>>>>> SRD> That is what it already says. >>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... >>>>>>> OC-Supported-Features can be in both request and answer, thus "If a >>>>>>> message" in that sense is correct. >>>>>>> >>>>>>>>> 13. clause 4.1, last sentence: >>>>>>>>> Should read "If the message already has the AVP then the agent >>>>>>>>> either leaves it unchanged in the relayed message or replaces >>>>>>>>> it to >>>>>>>>> reflect the features the agent is able and willing to support." >>>>>>>>> Clarification is needed to say that strict rules must be followed >>>>>>>>> by the agent to select the correct option. These rules take into >>>>>>>>> account whether the request is host-routed or relam-routed and >>>>>>>>> whether the agent is configured to select the server for >>>>>>>>> realm-routed requests. >>>>>>>> SRD> This is a topic on agent behavior that is addressed in the >>>>>>>> agent >>>>>>>> cases draft. I'll leave the discussion for what the wording >>>>>>>> should be >>>>>>>> to the discussion on that draft. >>>>>>>>> 14. clause 4.1.2, 2nd paragraph: >>>>>>>>> Should read: "Based on the content of the OC-Supported-Features >>>>>>>>> AVP >>>>>>>>> in the request message, the reporting node knows what overload >>>>>>>>> control functionality is supported by the reacting node. The >>>>>>>>> reporting node then acts accordingly for the subsequent answer >>>>>>>>> messages it initiates for the transaction." >>>>>>>> SRD> It would be easier if you didn't make it difficult to >>>>>>>> understand >>>>>>>> the change you are proposing. I think you are proposing changing >>>>>>>> node(s) to node. I don't agree but that will be addressed as >>>>>>>> part of >>>>>>>> the agent cases discussion. >>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing >>>>>>>> two sentences? The proposal is to insert "is" between >>>>>>>> "functionality" and "supported", to add "the" between "by" and >>>>>>>> "reacting", to replace "node(s)" with "node", and to insert "for >>>>>>>> the >>>>>>>> transaction" after "initiates". >>>>>>> Agree with the proposed change. >>>>>>> >>>>>>>>> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >>>>>>>>> Should read: "message's" >>>>>>>> SRD> I'm assuming you mean section 4.1.2. >>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, >>>>>>>> 18, >>>>>>>> and 19. >>>>>>>> I agree to the change. >>>>>>>>> 16. clause 4.1, 6th paragraph: >>>>>>>>> This should be left to the (future) specification that introduces >>>>>>>>> other DOIC features. >>>>>>>>> >>>>>>>>> 17. clause 4.1, 7th paragraph, last 6 words: >>>>>>>>> should be based on requiements set by the (future) specification >>>>>>>>> that >>>>>>>>> introduces other DOIC features >>>>>>>> SRD> Again, clause 4.1.2 -- I don't understand the issue when these >>>>>>>> SRD> two >>>>>>>> paragraphs are taken together. >>>>>>>>> 18. clause 4.1, 8th paragraph, last sentence: >>>>>>>>> Should read: "Lack of the OC-Supported-Features AVP in the request >>>>>>>>> message indicates that there is no downstream reacting node for >>>>>>>>> the >>>>>>>>> transaction." >>>>>>>> SRD> I think you mean clause 4.1.2. I don't see the need for the >>>>>>>> change. >>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not >>>>>>>> correct. It should either read: "Lack of the OC-Supported-Feature >>>>>>>> AVP in the request message indicates to the reporting node that >>>>>>>> there is no reacting node for the transaction" or as proposed >>>>>>>> above. >>>>>>> I don't see a reason for the change. Original text seem correct >>>>>>> to me. >>>>>>> >>>>>>>>> 19. clause 4.1, last sentence: >>>>>>>>> Should read: "An agent MAY replace the OC-Supported-Features AVP >>>>>>>>> carried in answer messages." This replacement must follow general >>>>>>>>> rules. Its not so that the agent may do what ever it wants to. The >>>>>>>>> decision must be based on whether or not the agent has replaced >>>>>>>>> the >>>>>>>>> OC-S-F in the corresponding request. >>>>>>>> SRD> What is the difference between modify and replace? I am ok >>>>>>>> with >>>>>>>> removing this statement until we have the agent behavior >>>>>>>> discussion. >>>>>>>> I thought I had taken the agent specific statements out of this >>>>>>>> version. >>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with >>>>>>>> identical values. You remove what has been received in and insert >>>>>>>> your own stuff. >>>>>>> Agent (proxy) can always do that i.e. modify the APV contents. >>>>>>> Obviously if an agent tampers the OC-Supported-Features AVP it needs >>>>>>> to know what it is doing. In general agree with the clarification >>>>>>> but >>>>>>> not with the proposed text. >>>>>>> >>>>>>> - Jouni >>>>>>> >>>>>>>>> 20. clause 5.2, 1st sentence: >>>>>>>>> Should read: "A reporting node using the loss algorithm must use >>>>>>>>> the OC-Reduction-Percentage AVP (Section 6.7) to indicated the >>>>>>>>> desired percentage of traffic reduction." >>>>>>>> SRD> Agreed. >>>>>>>>> 21. clause 5.2, last sentence: >>>>>>>>> Should read: "Editor's note: The above duplicates what is in the >>>>>>>>> OC-Reduction-Percentage AVP section and can probably be removed." >>>>>>>> SRD> Yes, bad wording. The note will be removed, bad wording and >>>>>>>> all, >>>>>>>> once there is a discussion on if this is redundant. >>>>>>>>> 22. clause 5.4, 6th paragraph: >>>>>>>>> Should read: "If the reacting node does not receive a an OLR in >>>>>>>>> the >>>>>>>>> answer that corresponds to the probe request messages sent to the >>>>>>>>> formally overloaded node then the reacting node should slowly >>>>>>>>> increase the rate of traffic sent to the overloaded node." >>>>>>>> SRD Agreed, this is more clear. >>>>>>>>> Best regards >>>>>>>>> Ulrich >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>>>>>> Donovan >>>>>>>>> Sent: Saturday, July 05, 2014 9:42 PM >>>>>>>>> To: dime@ietf.org >>>>>>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>>>>> >>>>>>>>> All, >>>>>>>>> >>>>>>>>> This version of the DOIC draft is a restructuring of previously >>>>>>>>> agreed to content. >>>>>>>>> >>>>>>>>> The master plan for the restructuring is in Appendix C. This >>>>>>>>> outlines where material from -02 was moved in -03. >>>>>>>>> >>>>>>>>> For those interested, the work was done in steps, with a snapshot >>>>>>>>> for >>>>>>>>> each step available here: >>>>>>>>> >>>>>>>>> https://github.com/jounikor/draft-docdt-dime-ovli >>>>>>>>> >>>>>>>>> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >>>>>>>>> >>>>>>>>> where nn indicates the subversion and "text" indicates the >>>>>>>>> focus for >>>>>>>>> that subversion. >>>>>>>>> >>>>>>>>> The next step will be to resolve open issues already identified >>>>>>>>> and >>>>>>>>> those yet those yet to be identified. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Steve >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>>>> Internet-Drafts >>>>>>>>>> directories. >>>>>>>>>> This draft is a work item of the Diameter Maintenance and >>>>>>>>>> Extensions Working Group of the IETF. >>>>>>>>>> >>>>>>>>>> Title : Diameter Overload Indication >>>>>>>>>> Conveyance >>>>>>>>>> Authors : Jouni Korhonen >>>>>>>>>> Steve Donovan >>>>>>>>>> Ben Campbell >>>>>>>>>> Lionel Morand >>>>>>>>>> Filename : draft-ietf-dime-ovli-03.txt >>>>>>>>>> Pages : 48 >>>>>>>>>> Date : 2014-07-03 >>>>>>>>>> >>>>>>>>>> Abstract: >>>>>>>>>> This specification documents a Diameter Overload Control >>>>>>>>>> (DOC) base >>>>>>>>>> solution and the dissemination of the overload report >>>>>>>>>> information. >>>>>>>>>> >>>>>>>>>> Requirements >>>>>>>>>> >>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>>>>>>>>> >>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>>>>>>>>> >>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-03 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>>>>> submission until the htmlized version and diff are available at >>>>>>>>>> tools.ietf.org. >>>>>>>>>> >>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> DiME mailing list >>>>>>>>>> DiME@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> DiME mailing list >>>>>>>>> DiME@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> DiME mailing list >>>>>>>> DiME@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> DiME mailing list >>>>>>>> DiME@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>> DiME@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>> >> > From nobody Mon Jul 21 14:14:12 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5791A0456 for ; Mon, 21 Jul 2014 14:14:10 -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, SPF_NEUTRAL=0.779] autolearn=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 HUz51Srqp2eD for ; Mon, 21 Jul 2014 14:14:07 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 792871A03F6 for ; Mon, 21 Jul 2014 14:14:07 -0700 (PDT) Received: from dhcp-a698.meeting.ietf.org ([31.133.166.152]:60424) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X9KuB-00040T-FV; Mon, 21 Jul 2014 14:14:06 -0700 Message-ID: <53CD8293.4050301@usdonovans.com> Date: Mon, 21 Jul 2014 17:13:55 -0400 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jouni Korhonen , "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <53CD2962.6060403@gmail.com> <53CD4379.3010203@usdonovans.com> <53CD5188.1010009@gmail.com> <53CD591D.1040809@usdonovans.com> <53CD63A6.6020305@gmail.com> In-Reply-To: <53CD63A6.6020305@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/fkZjt8wUmq5TCtuwx36mv3aAQ40 Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 21:14:10 -0000 Jouni, One more (hopefully) inline... On 7/21/14, 3:01 PM, Jouni Korhonen wrote: > Steve, > > Inline. > > 7/21/2014 9:17 PM, Steve Donovan kirjoitti: >> Inline... >> On 7/21/14, 1:44 PM, Jouni Korhonen wrote: >>> Steve, >>> >>> A bit more inline. >>> >>> 7/21/2014 7:44 PM, Steve Donovan kirjoitti: >>>> >>>> On 7/21/14, 10:53 AM, Jouni Korhonen wrote: >>>>> Steve, >>>>> >>>>> 7/21/2014 5:29 PM, Steve Donovan kirjoitti: >>>>>> Ulrich, >>>>>> >>>>>> I am not arguing that all agents should take an active role in the >>>>>> handling of all overload reports. What I am arguing is that >>>>>> there are >>>>>> scenarios where an agent must take an active role in DOIC to ensure >>>>>> that >>>>>> a requested reduction in traffic an be achieved. >>>>>> >>>>>> For DOIC to work a carrier cannot turn off all DOIC behavior in >>>>>> agents, >>>>>> as suggested by Jouni. >>>>> >>>>> Why? If you have a hierarchy of agents I don't see a reason why some >>>>> of those could be just "vanilla agents" or DOIC agents with >>>>> functionality turned off. Not arguing such deployment makes sense but >>>>> the protocol solution should be able to cope with that. >>>> SRD> I agree that some of the agents can have DOIC behavior turned >>>> off, >>>> as long as the agent in question does not have a direct transport >>>> connection to a Diameter node that could generate a host report. >>> >>> Ok. One more thing. If there is an agent that either has no DOIC >>> capability or it is turned off the outcome can be >>> non-optimal/non-desired, but that should not break anything, right? In >>> that light I do not understand the direct peer connection requirement >>> since if the agent allows turning off the DOIC functionally such >>> deployment can be done irrespective what the RFC says (e.g. >>> misconfiguration or for a specific reason). >> Things don't work if the Diameter nodes that have direct transport >> connections to overloaded servers do not support DOIC. We illustrated > > Obviously. > >> that use case in the draft in the section about non supporting agents >> with the statement that that specific deployment scenario should be >> avoided. > > Should be avoided is fine. > >> If an operator wants to deploy a network that doesn't not properly >> handle overload then they are free to do so. We cannot prevent that >> from happening. We do need to have a mechanism that does allow sane > > Exactly.. and operators might have a reason to do so e.g. for > temporarily. > >> operators to deploy their network in a way that properly handles >> overload. This requires us to recognize that agents will be required to >> react to overload reports. >> >> Do you disagree with this? > > I agree but I want to be clear on the wording with MUSTs and alike > that the specification does not imply that all proxies must be > upgraded for DOIC to work or that the operator cannot have a local > policy that applies DOIC selectively. I'm assuming (or hoping) you mean agent, not proxy. The same can be said about clients and servers. Operators can turn DOIC on and off for the same reasons they would do it for agents. I'm not sure how this gets reflected in the text of a protocol specification, but I suspect we can come up with agreeable wording. > - Jouni > >>> >>> - Jouni >>> >>> >>>>> >>>>> - Jouni >>>>> >>>>>> >>>>>> I agree that in your scenario below, a1 does not need to take an >>>>>> active >>>>>> role in reducing traffic when c supports DOIC. a1 should take an >>>>>> active >>>>>> role when c does not support DOIC. The problem is that a1 does not >>>>>> know >>>>>> in advance whether c supports DOIC so it will need to inspect all >>>>>> transactions for the presence of OC-S-F to determine if it needs to >>>>>> handle overload reports for a non supporting client. >>>>>> >>>>>> Does that mean a1 is transparent if it inspects all requests and >>>>>> does >>>>>> nothing in the case where there is c supports DOIC? >>>>>> >>>>>> Does transparent mean that there is no observable difference in the >>>>>> DOIC >>>>>> AVPs that pass through the agent or does it mean that there is no >>>>>> observable difference in how transactions are handled by the DOIC >>>>>> agent? >>>>>> >>>>>> I'm guessing that we have multiple assumptions on what transparent >>>>>> means >>>>>> and, if we are going to continue saying agents should be transparent >>>>>> then we need a definition of transparent. >>>>>> >>>>>> I think for this use case, we need the following normative >>>>>> statements in >>>>>> the draft for handling of abatement of realm-routed requests? I >>>>>> think >>>>>> this is general behavior and should go in the section on handling of >>>>>> overload reports. >>>>>> >>>>>> "DOIC nodes with a direct transport connection to a reporting node >>>>>> that >>>>>> has an active overload report must handle abatement of realm-routed >>>>>> requests. The preferred method for handling abatement of >>>>>> realm-routed >>>>>> requests is diversion, where the node with the direct transport >>>>>> connection routes the request to an alternative server that is >>>>>> able to >>>>>> handle the request. If there is no alternative server with the >>>>>> needed >>>>>> capacity to handle the request then the DOIC node must/should >>>>>> throttle >>>>>> the necessary requests to meet the requested reduction in traffic." >>>>>> >>>>>> If we can agree on this then we can move on to the next agent based >>>>>> use >>>>>> case. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Steve >>>>>> >>>>>> On 7/21/14, 9:47 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>>>>> Steve, >>>>>>> >>>>>>> The example you show is absolutely valid and 100% inline with A) >>>>>>> to F) >>>>>>> - (assuming that all servers can serve any request). >>>>>>> However, there are other scenarios like: >>>>>>> >>>>>>> >>>>>>> +--+ >>>>>>> /--|s1| >>>>>>> +-+ +--+ +--+ / +--+ >>>>>>> |c|--- |a1|--|a2|== ... >>>>>>> +-+ +--+ +--+ \ +--+ >>>>>>> \--|sn| >>>>>>> +--+ >>>>>>> >>>>>>> Here I think a1 should be transparent even when DOICable. >>>>>>> a1 does not take the role of a reacting node since c supports DOIC. >>>>>>> a1 does not perform server selection and therefore does not take >>>>>>> the >>>>>>> role of a reporting node (for realm-reports). >>>>>>> >>>>>>> Ulrich >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] >>>>>>> Sent: Monday, July 21, 2014 3:16 PM >>>>>>> To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - >>>>>>> DE/Munich); dime@ietf.org >>>>>>> Subject: Transparent agents (was Re: [Dime] I-D Action: >>>>>>> draft-ietf-dime-ovli-03.txt) >>>>>>> >>>>>>> Ok, let's see if it's possible to completely turn off all DOIC >>>>>>> behavior >>>>>>> in agents and still be able to reduce traffic to a server that >>>>>>> sends a >>>>>>> host overload report. >>>>>>> >>>>>>> Assume the following agent based deployment: >>>>>>> >>>>>>> +--+ >>>>>>> /--|s1| >>>>>>> +-+ +-+ / +--+ >>>>>>> |c|--|a|== ... >>>>>>> +-+ +-+ \ +--+ >>>>>>> \--|sn| >>>>>>> +--+ >>>>>>> >>>>>>> Assume that there is a large number of servers, say 50. >>>>>>> >>>>>>> Now, assume that the Diameter application in question exclusively >>>>>>> uses >>>>>>> realm-routed requests - 100% of requests sent by the client do NOT >>>>>>> have >>>>>>> a destination-host AVP. >>>>>>> >>>>>>> Now assume that server s1 sends an host type overload report >>>>>>> requesting >>>>>>> a reduction of 20% using the loss algorithm. >>>>>>> >>>>>>> Also assume that the unused capacity in servers s2 through s50 is >>>>>>> sufficient to handle the traffic that would have been sent to >>>>>>> s1. As >>>>>>> such, there is no reason to throttle any requests. >>>>>>> >>>>>>> There are no host routed requests for this application and the >>>>>>> client >>>>>>> does not have a direct transport connection to server s1. The only >>>>>>> option a client has is to hand the request off to the agent for >>>>>>> routing. >>>>>>> >>>>>>> The proposal in the agent cases draft is that the agent diverts >>>>>>> 20% of >>>>>>> the realm routed requests that would have been sent to server s1 to >>>>>>> servers s2 through s50. >>>>>>> >>>>>>> If DOIC behavior is turned off in the agent then how will the >>>>>>> traffic >>>>>>> routed to s1 be reduced? >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote: >>>>>>>> +1 for the following aspect. >>>>>>>> >>>>>>>>>>> Agents must take an active role in even the most basic case for >>>>>>>>>>> overload handling to work, so they cannot be transparent. >>>>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do >>>>>>>>>> not support DOIC are transparent. Agents that support DOIC in >>>>>>>>>> most >>>>>>>>>> cases behave like non supporting agents. >>>>>>>>> I am towards Ulrich's view here. Even for an agent that >>>>>>>>> understands >>>>>>>>> DOIC it is up to the local policy whether it is transparent or >>>>>>>>> takes >>>>>>>>> an active role. >>>>>>>> -----Original Message----- >>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni >>>>>>>> Korhonen >>>>>>>> Sent: Monday, July 21, 2014 12:26 AM >>>>>>>> To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; >>>>>>>> dime@ietf.org >>>>>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>>>> >>>>>>>> Some comments inline.. >>>>>>>> >>>>>>>> 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >>>>>>>>> Steve, >>>>>>>>> please see my response inline. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Ulrich >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>>>>>> Donovan >>>>>>>>> Sent: Tuesday, July 15, 2014 3:53 PM >>>>>>>>> To: dime@ietf.org >>>>>>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>>>>> >>>>>>>>> Ulrich, >>>>>>>>> >>>>>>>>> Thanks for the comments. Please see my responses inline. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Steve >>>>>>>>> On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>>>>>>>> Hi Steve, >>>>>>>>>> here are my comments. >>>>>>>>>> They focus on new text you introduced. I agree that >>>>>>>>>> restructuring >>>>>>>>>> may require new text, however, I believe that with the new >>>>>>>>>> text a >>>>>>>>>> new concepts is introduced which macerates the agreed end-to-end >>>>>>>>>> concept and allows all DOIC agents on the path to do what they >>>>>>>>>> wants, so that we end up in a hop-by-hop concept. >>>>>>>>> SRD> We have never had an agreement on end-to-end versus >>>>>>>>> hop-by-hop >>>>>>>>> SRD> and >>>>>>>>> I believe that we will end up with a hybrid of the two. We have >>>>>>>>> open >>>>>>>>> issues on agent behavior that Ben and I are attempting to address >>>>>>>>> with >>>>>>>>> the agent cases draft. >>>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop >>>>>>>>> approach of the roach draft was reason not to proceed with that >>>>>>>>> draft. >>>>>>>>> >>>>>>>>> SRD> That said, this type of restructuring of the document is >>>>>>>>> likely >>>>>>>>> SRD> to >>>>>>>>> put agreed to behavior in a new light. If there are cases >>>>>>>>> where I >>>>>>>>> have implied changes to agreed to normative behavior, or if the >>>>>>>>> informative text is not accurate, then these things need to be >>>>>>>>> corrected. >>>>>>>>>> 1. clause 2.3, second paragraph: >>>>>>>>>> Should read: "Reacting nodes indicate support for DOIC by >>>>>>>>>> including >>>>>>>>>> the OC-Supported-Features AVP into all request messages >>>>>>>>>> originated >>>>>>>>>> or relayed by the Reacting node." >>>>>>>>> SRD> You mean clause 3.2. >>>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes >>>>>>>>> I agree with the change. >>>>>>>>>> 2. clause 2.3, 3rd paragraph, 1st sentence: >>>>>>>>>> OC-xxx AVPs must not be included in an answer message when the >>>>>>>>>> corresponding request did not contain an OC-S-F AVP. >>>>>>>>> SRD> Agreed. >>>>>>>>>> 3. clause 3.3, 7th paragraph: >>>>>>>>>> Should read "The reporting node only includes an indication of >>>>>>>>>> support for one overload abatement algorithm. This is the >>>>>>>>>> algorithm that the reporting node intends to use should it >>>>>>>>>> enter an >>>>>>>>>> overload condition or requests to use while it actually is in an >>>>>>>>>> overload condition. Reacting nodes can use the indicated >>>>>>>>>> overload >>>>>>>>>> abatement algorithm to prepare for possible overload reports and >>>>>>>>>> must use the indicated overload abatement algorithm if traffic >>>>>>>>>> reduction is actually requested." >>>>>>>>> SRD. OK. >>>>>>>>>> 4. clause 3.3, 10th paragraph: >>>>>>>>>> The 1st sentence is misleading. In the general case, agents >>>>>>>>>> on the >>>>>>>>>> path between reacting node and reporting node are transparent. I >>>>>>>>>> agree that there are exceptions to the general case where an >>>>>>>>>> agent >>>>>>>>>> on the path is not transparent, but then the agent IS the >>>>>>>>>> reporting >>>>>>>>>> node (reporting to the sender of the request) and it also IS the >>>>>>>>>> reacting node (reacting on reports received from the upstream >>>>>>>>>> reporting node). >>>>>>>>>> The first 3 words of the second sentence "in this case" need >>>>>>>>>> clarification: "In the case where an agent takes the role of a >>>>>>>>>> reporting node (reporting to the downstream reacting node) >>>>>>>>>> and at >>>>>>>>>> the same time takes the role of a reacting node (reacting on >>>>>>>>>> reports received from an upstream reporting node)". >>>>>>>>>> Last sentence: Its not an update but a replacement. The two DOIC >>>>>>>>>> associations are handled independently. >>>>>>>>> SRD> I don't know what you mean when you say an agent is >>>>>>>>> transparent. >>>>>>>>> Agents must take an active role in even the most basic case for >>>>>>>>> overload handling to work, so they cannot be transparent. >>>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do >>>>>>>>> not >>>>>>>>> support DOIC are transparent. Agents that support DOIC in most >>>>>>>>> cases >>>>>>>>> behave like non supporting agents. >>>>>>>> I am towards Ulrich's view here. Even for an agent that >>>>>>>> understands >>>>>>>> DOIC it is up to the local policy whether it is transparent or >>>>>>>> takes >>>>>>>> an active role. >>>>>>>> >>>>>>>>>> 5. clause 3.3, last paragraph: >>>>>>>>>> General rules shall be followed for each of the two associations >>>>>>>>>> separately. The content of the OC-S-F AVP sent by the agent >>>>>>>>>> upstream should reflect what the agent is able and willing to >>>>>>>>>> support (as always). >>>>>>>>> SRD> What two associations? Is there one association >>>>>>>>> (end-to-end) or >>>>>>>>> SRD> is >>>>>>>>> the an association on both sides of the agent (hop-by-hop)? >>>>>>>>> Or is >>>>>>>>> there an association that involves three entities, the reporting >>>>>>>>> node, >>>>>>>>> an agent reacting node for realm-routed requests and a >>>>>>>>> transaction-client reporting node for handling host-routed >>>>>>>>> requests? >>>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, >>>>>>>>> There is >>>>>>>>> one association between C and A, and one association between A >>>>>>>>> and >>>>>>>>> S. Both associations are "end-to-end" as there may be transparent >>>>>>>>> (supporting or non-supporting) agents in the middle. >>>>>>>>>> 6. clause 3.4, 2nd paragraph: >>>>>>>>>> Should read: "The OC-OLR AVP is referred to as an overload >>>>>>>>>> report. >>>>>>>>>> The OC-OLR AVP includes the type of report, a sequence >>>>>>>>>> number, the >>>>>>>>>> length of time that the report is valid and abatement algorithm >>>>>>>>>> specific AVPs." >>>>>>>>> SRD> The sequence number is being used as an overload report >>>>>>>>> ID. I >>>>>>>>> can >>>>>>>>> make the change but I don't see it as necessary. >>>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. >>>>>>>> OK to do the change. >>>>>>>> >>>>>>>>>> 7. clause 3.4, 4th paragraph, 2nd sentence: >>>>>>>>>> I cannot understand this sentence. Probably only simple typos >>>>>>>>>> but I >>>>>>>>>> don't know. >>>>>>>>> SRD> Yes, a typo (this instead of the) and awkward wording. How >>>>>>>>> about >>>>>>>>> "This applies to requests that contain the Destination-Host AVP >>>>>>>>> with a >>>>>>>>> DiameterIdentity that matches the overload report. >>>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that >>>>>>>>> contain a DiameterIdentity in the Destination-Host AVP that >>>>>>>>> matches >>>>>>>>> the reporting host's DiameterIdentity" >>>>>>>> I would be inclined to keep the text Steve proposed. But both >>>>>>>> are ok >>>>>>>> actually. >>>>>>>> >>>>>>>>>> 8. clause 3.4, 4th paragraph last 2 sentences: >>>>>>>>>> I don't understand and probably do not agree. >>>>>>>>> SRD> See above. >>>>>>>>>> 9. clause 3.5, 3rd paragraph, last word: >>>>>>>>>> Should read "communicated" >>>>>>>>> SRD> Agreed. >>>>>>>>>> 10. clause 3.5, 4th paragraph, 1st sentence: >>>>>>>>>> I don't understand. I can understand: "Reporting nodes use the >>>>>>>>>> OC-OLR AVP to communicate overload occurances towards reacting >>>>>>>>>> nodes." >>>>>>>>> SRD> Who else would reports be sent to? >>>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement >>>>>>>>> algorithm but the reporting node that uses the OC-OLR AVP to >>>>>>>>> communicate overload occurances. >>>>>>>> Agree. >>>>>>>> >>>>>>>>>> 11. clause 4.1, 3rd paragraph, last 4 words: >>>>>>>>>> may be misleading. A DOIC supporting agent sitting between DOIC >>>>>>>>>> supporting client and DOIC supporting Server is transparent with >>>>>>>>>> regard to DOIC. This agent does not indicate DOIC support. >>>>>>>>> SRD> I disagree. >>>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. >>>>>>>>> Should be: ...This agent does not indicate its DOIC support, >>>>>>>>> rather >>>>>>>>> it transparently forwards the client's DOIC support. >>>>>>>> Agree with Ulrich on the intent of agent behavior but not with the >>>>>>>> proposed text change. >>>>>>>> >>>>>>>>>> 12. clause 4.1, 4th paragraph, 2nd sentence: >>>>>>>>>> Should read:"If a request message handled by the DOIC agent does >>>>>>>>>> not include the OC-Supported-Features AVP then the DOIC agent >>>>>>>>>> inserts the AVP." >>>>>>>>> SRD> That is what it already says. >>>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... >>>>>>>> OC-Supported-Features can be in both request and answer, thus >>>>>>>> "If a >>>>>>>> message" in that sense is correct. >>>>>>>> >>>>>>>>>> 13. clause 4.1, last sentence: >>>>>>>>>> Should read "If the message already has the AVP then the agent >>>>>>>>>> either leaves it unchanged in the relayed message or replaces >>>>>>>>>> it to >>>>>>>>>> reflect the features the agent is able and willing to support." >>>>>>>>>> Clarification is needed to say that strict rules must be >>>>>>>>>> followed >>>>>>>>>> by the agent to select the correct option. These rules take into >>>>>>>>>> account whether the request is host-routed or relam-routed and >>>>>>>>>> whether the agent is configured to select the server for >>>>>>>>>> realm-routed requests. >>>>>>>>> SRD> This is a topic on agent behavior that is addressed in the >>>>>>>>> agent >>>>>>>>> cases draft. I'll leave the discussion for what the wording >>>>>>>>> should be >>>>>>>>> to the discussion on that draft. >>>>>>>>>> 14. clause 4.1.2, 2nd paragraph: >>>>>>>>>> Should read: "Based on the content of the OC-Supported-Features >>>>>>>>>> AVP >>>>>>>>>> in the request message, the reporting node knows what overload >>>>>>>>>> control functionality is supported by the reacting node. The >>>>>>>>>> reporting node then acts accordingly for the subsequent answer >>>>>>>>>> messages it initiates for the transaction." >>>>>>>>> SRD> It would be easier if you didn't make it difficult to >>>>>>>>> understand >>>>>>>>> the change you are proposing. I think you are proposing changing >>>>>>>>> node(s) to node. I don't agree but that will be addressed as >>>>>>>>> part of >>>>>>>>> the agent cases discussion. >>>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with >>>>>>>>> comparing >>>>>>>>> two sentences? The proposal is to insert "is" between >>>>>>>>> "functionality" and "supported", to add "the" between "by" and >>>>>>>>> "reacting", to replace "node(s)" with "node", and to insert "for >>>>>>>>> the >>>>>>>>> transaction" after "initiates". >>>>>>>> Agree with the proposed change. >>>>>>>> >>>>>>>>>> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >>>>>>>>>> Should read: "message's" >>>>>>>>> SRD> I'm assuming you mean section 4.1.2. >>>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, >>>>>>>>> 18, >>>>>>>>> and 19. >>>>>>>>> I agree to the change. >>>>>>>>>> 16. clause 4.1, 6th paragraph: >>>>>>>>>> This should be left to the (future) specification that >>>>>>>>>> introduces >>>>>>>>>> other DOIC features. >>>>>>>>>> >>>>>>>>>> 17. clause 4.1, 7th paragraph, last 6 words: >>>>>>>>>> should be based on requiements set by the (future) specification >>>>>>>>>> that >>>>>>>>>> introduces other DOIC features >>>>>>>>> SRD> Again, clause 4.1.2 -- I don't understand the issue when >>>>>>>>> these >>>>>>>>> SRD> two >>>>>>>>> paragraphs are taken together. >>>>>>>>>> 18. clause 4.1, 8th paragraph, last sentence: >>>>>>>>>> Should read: "Lack of the OC-Supported-Features AVP in the >>>>>>>>>> request >>>>>>>>>> message indicates that there is no downstream reacting node for >>>>>>>>>> the >>>>>>>>>> transaction." >>>>>>>>> SRD> I think you mean clause 4.1.2. I don't see the need for the >>>>>>>>> change. >>>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is >>>>>>>>> not >>>>>>>>> correct. It should either read: "Lack of the OC-Supported-Feature >>>>>>>>> AVP in the request message indicates to the reporting node that >>>>>>>>> there is no reacting node for the transaction" or as proposed >>>>>>>>> above. >>>>>>>> I don't see a reason for the change. Original text seem correct >>>>>>>> to me. >>>>>>>> >>>>>>>>>> 19. clause 4.1, last sentence: >>>>>>>>>> Should read: "An agent MAY replace the OC-Supported-Features AVP >>>>>>>>>> carried in answer messages." This replacement must follow >>>>>>>>>> general >>>>>>>>>> rules. Its not so that the agent may do what ever it wants >>>>>>>>>> to. The >>>>>>>>>> decision must be based on whether or not the agent has replaced >>>>>>>>>> the >>>>>>>>>> OC-S-F in the corresponding request. >>>>>>>>> SRD> What is the difference between modify and replace? I am ok >>>>>>>>> with >>>>>>>>> removing this statement until we have the agent behavior >>>>>>>>> discussion. >>>>>>>>> I thought I had taken the agent specific statements out of this >>>>>>>>> version. >>>>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with >>>>>>>>> identical values. You remove what has been received in and insert >>>>>>>>> your own stuff. >>>>>>>> Agent (proxy) can always do that i.e. modify the APV contents. >>>>>>>> Obviously if an agent tampers the OC-Supported-Features AVP it >>>>>>>> needs >>>>>>>> to know what it is doing. In general agree with the clarification >>>>>>>> but >>>>>>>> not with the proposed text. >>>>>>>> >>>>>>>> - Jouni >>>>>>>> >>>>>>>>>> 20. clause 5.2, 1st sentence: >>>>>>>>>> Should read: "A reporting node using the loss algorithm must use >>>>>>>>>> the OC-Reduction-Percentage AVP (Section 6.7) to indicated the >>>>>>>>>> desired percentage of traffic reduction." >>>>>>>>> SRD> Agreed. >>>>>>>>>> 21. clause 5.2, last sentence: >>>>>>>>>> Should read: "Editor's note: The above duplicates what is in the >>>>>>>>>> OC-Reduction-Percentage AVP section and can probably be >>>>>>>>>> removed." >>>>>>>>> SRD> Yes, bad wording. The note will be removed, bad wording and >>>>>>>>> all, >>>>>>>>> once there is a discussion on if this is redundant. >>>>>>>>>> 22. clause 5.4, 6th paragraph: >>>>>>>>>> Should read: "If the reacting node does not receive a an OLR in >>>>>>>>>> the >>>>>>>>>> answer that corresponds to the probe request messages sent to >>>>>>>>>> the >>>>>>>>>> formally overloaded node then the reacting node should slowly >>>>>>>>>> increase the rate of traffic sent to the overloaded node." >>>>>>>>> SRD Agreed, this is more clear. >>>>>>>>>> Best regards >>>>>>>>>> Ulrich >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>>>>>>> Donovan >>>>>>>>>> Sent: Saturday, July 05, 2014 9:42 PM >>>>>>>>>> To: dime@ietf.org >>>>>>>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>>>>>> >>>>>>>>>> All, >>>>>>>>>> >>>>>>>>>> This version of the DOIC draft is a restructuring of previously >>>>>>>>>> agreed to content. >>>>>>>>>> >>>>>>>>>> The master plan for the restructuring is in Appendix C. This >>>>>>>>>> outlines where material from -02 was moved in -03. >>>>>>>>>> >>>>>>>>>> For those interested, the work was done in steps, with a >>>>>>>>>> snapshot >>>>>>>>>> for >>>>>>>>>> each step available here: >>>>>>>>>> >>>>>>>>>> https://github.com/jounikor/draft-docdt-dime-ovli >>>>>>>>>> >>>>>>>>>> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >>>>>>>>>> >>>>>>>>>> where nn indicates the subversion and "text" indicates the >>>>>>>>>> focus for >>>>>>>>>> that subversion. >>>>>>>>>> >>>>>>>>>> The next step will be to resolve open issues already identified >>>>>>>>>> and >>>>>>>>>> those yet those yet to be identified. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Steve >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>>>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>>>>> Internet-Drafts >>>>>>>>>>> directories. >>>>>>>>>>> This draft is a work item of the Diameter Maintenance and >>>>>>>>>>> Extensions Working Group of the IETF. >>>>>>>>>>> >>>>>>>>>>> Title : Diameter Overload Indication >>>>>>>>>>> Conveyance >>>>>>>>>>> Authors : Jouni Korhonen >>>>>>>>>>> Steve Donovan >>>>>>>>>>> Ben Campbell >>>>>>>>>>> Lionel Morand >>>>>>>>>>> Filename : draft-ietf-dime-ovli-03.txt >>>>>>>>>>> Pages : 48 >>>>>>>>>>> Date : 2014-07-03 >>>>>>>>>>> >>>>>>>>>>> Abstract: >>>>>>>>>>> This specification documents a Diameter Overload >>>>>>>>>>> Control >>>>>>>>>>> (DOC) base >>>>>>>>>>> solution and the dissemination of the overload report >>>>>>>>>>> information. >>>>>>>>>>> >>>>>>>>>>> Requirements >>>>>>>>>>> >>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>>>>>>>>>> >>>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>>>>>>>>>> >>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-03 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Please note that it may take a couple of minutes from the >>>>>>>>>>> time of >>>>>>>>>>> submission until the htmlized version and diff are available at >>>>>>>>>>> tools.ietf.org. >>>>>>>>>>> >>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> DiME mailing list >>>>>>>>>>> DiME@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> DiME mailing list >>>>>>>>>> DiME@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> DiME mailing list >>>>>>>>> DiME@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> DiME mailing list >>>>>>>>> DiME@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> DiME mailing list >>>>>>>> DiME@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>>> >>> >> > From nobody Mon Jul 21 14:50:15 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE791A00AD for ; Mon, 21 Jul 2014 14:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 opNcXASWeSvC for ; Mon, 21 Jul 2014 14:50:12 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 88FF61A02BD for ; Mon, 21 Jul 2014 14:50:10 -0700 (PDT) Received: from dhcp-bbc7.meeting.ietf.org (dhcp-bbc7.meeting.ietf.org [31.133.187.199]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6LLo4bg060900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Jul 2014 16:50:07 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53CD591D.1040809@usdonovans.com> Date: Mon, 21 Jul 2014 17:50:00 -0400 X-Mao-Original-Outgoing-Id: 427672200.508523-d92eb11ebbd7a208c49ec6a935cba0c1 Content-Transfer-Encoding: quoted-printable Message-Id: <829BF76B-6404-4524-BBF1-5088DCD2FC0E@nostrum.com> References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <53CD2962.6060403@gmail.com> <53CD4379.3010203@usdonovans.com> <53CD5188.1010009@gmail.com> <53CD591D.1040809@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/M4uCnwY7tIN4fhrXhzv0JG3ML2k Cc: "dime@ietf.org" Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 21:50:13 -0000 On Jul 21, 2014, at 2:17 PM, Steve Donovan = wrote: >> Ok. One more thing. If there is an agent that either has no DOIC = capability or it is turned off the outcome can be = non-optimal/non-desired, but that should not break anything, right? In = that light I do not understand the direct peer connection requirement = since if the agent allows turning off the DOIC functionally such = deployment can be done irrespective what the RFC says (e.g. = misconfiguration or for a specific reason). > Things don't work if the Diameter nodes that have direct transport = connections to overloaded servers do not support DOIC. We illustrated = that use case in the draft in the section about non supporting agents = with the statement that that specific deployment scenario should be = avoided. >=20 One thing we should keep in mind is that we cannot really assume that = only one node, or "tier" of nodes has a direct connection to servers. = e.g: S / =20 C----A1 S=20 \ \ / S A2 \ S Is a perfectly legal, if weird, configuration. And to further complicate things, consider that A2 might perform = topology hiding, so that A1 thinks it's a server. > If an operator wants to deploy a network that doesn't not properly = handle overload then they are free to do so. We cannot prevent that = from happening. We do need to have a mechanism that does allow sane = operators to deploy their network in a way that properly handles = overload. This requires us to recognize that agents will be required to = react to overload reports. >=20 > Do you disagree with this? From nobody Mon Jul 21 15:06:50 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890D51A00FC for ; Mon, 21 Jul 2014 15:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 PEUvndYL3FNU for ; Mon, 21 Jul 2014 15:06:48 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 66FAA1A0068 for ; Mon, 21 Jul 2014 15:06:48 -0700 (PDT) Received: from dhcp-bbc7.meeting.ietf.org (dhcp-bbc7.meeting.ietf.org [31.133.187.199]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6LM6jZO062359 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Jul 2014 17:06:47 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <829BF76B-6404-4524-BBF1-5088DCD2FC0E@nostrum.com> Date: Mon, 21 Jul 2014 18:06:40 -0400 X-Mao-Original-Outgoing-Id: 427673200.732047-0145473dcd83dcb7c1cce7364dc53778 Content-Transfer-Encoding: quoted-printable Message-Id: <919319F5-8770-42B5-AC43-6FCDD3948AED@nostrum.com> References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <53CD2962.6060403@gmail.com> <53CD4379.3010203@usdonovans.com> <53CD5188.1010009@gmail.com> <53CD591D.1040809@usdonovans.com> <829BF76B-6404-4524-BBF1-5088DCD2FC0E@nostrum.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xNXEy9isv0LPnuxEFx3pum9zQ9A Cc: "dime@ietf.org" Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 22:06:49 -0000 On Jul 21, 2014, at 5:50 PM, Ben Campbell wrote: >=20 > On Jul 21, 2014, at 2:17 PM, Steve Donovan = wrote: >=20 >>> Ok. One more thing. If there is an agent that either has no DOIC = capability or it is turned off the outcome can be = non-optimal/non-desired, but that should not break anything, right? In = that light I do not understand the direct peer connection requirement = since if the agent allows turning off the DOIC functionally such = deployment can be done irrespective what the RFC says (e.g. = misconfiguration or for a specific reason). >> Things don't work if the Diameter nodes that have direct transport = connections to overloaded servers do not support DOIC. We illustrated = that use case in the draft in the section about non supporting agents = with the statement that that specific deployment scenario should be = avoided. >>=20 >=20 > One thing we should keep in mind is that we cannot really assume that = only one node, or "tier" of nodes has a direct connection to servers. = e.g: >=20 > S > / =20 > C----A1 S=20 > \ \ / > S A2 > \ > S >=20 > Is a perfectly legal, if weird, configuration. >=20 > And to further complicate things, consider that A2 might perform = topology hiding, so that A1 thinks it's a server. We should also not forget the possibility of servers sending requests to = clients. A slightly different picture: C S \ / C--A1 -- A2 =20 / \ C S If a server sends a realm-routed request to a client (not common, but = not illegal), A1 becomes the "server-selecting node". =20 From nobody Tue Jul 22 07:11:42 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D1E1B28A3 for ; Tue, 22 Jul 2014 07:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 RhoQa1_Y6LF6 for ; Tue, 22 Jul 2014 07:11:22 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F6291B2895 for ; Tue, 22 Jul 2014 07:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22704; q=dns/txt; s=iport; t=1406038282; x=1407247882; h=message-id:date:from:mime-version:to:cc:subject; bh=Xye9Z3weTtfH0cRfeK9sn/q51D8aVdGWLBWWwmr5HXg=; b=Ey+Qkmmk4yZwlijU1g9uukXnk6zbrAEqWS9zJmzp7qLPgagGFPObAO3p fSkHaYBYDjAoIK6zTXNimNkvWE5AGlpyGW02opMdCNbILIHviTEVgVzzE iF1HZFdD/2l6pdr44Tcl4wv9Janthiep7lwnK3F0r2exoD1n7OzCZIXPE Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FAChwzlOtJA2B/2dsb2JhbABYgkdHgSnOXIEPFnaEN0sBPBYBARYDAgECAVgBBwEBiD6/SRePSx2EMAEEmyaHFY0ag2AhL4EDJA X-IronPort-AV: E=Sophos;i="5.01,710,1400025600"; d="scan'208,217";a="341912145" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-7.cisco.com with ESMTP; 22 Jul 2014 14:11:21 +0000 Received: from [10.82.211.224] (rtp-vpn4-992.cisco.com [10.82.211.224]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s6MEBKl6019820; Tue, 22 Jul 2014 14:11:20 GMT Message-ID: <53CE7108.6030300@cisco.com> Date: Tue, 22 Jul 2014 10:11:20 -0400 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: marco.liebsch@neclab.eu Content-Type: multipart/alternative; boundary="------------080409060608000007010104" Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ai-tbDBU2Lc9GnTqtl9XuV3XQ78 Cc: dime mailing list Subject: [Dime] draft-ietf-dime-group-signaling-04 feedback X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 14:11:27 -0000 This is a multi-part message in MIME format. --------------080409060608000007010104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Marco, I didn't express myself correctly this morning: not enough coffee or maybe too many. My high level points were: - The draft doesn't mention that mid-session group assignment modifications is an exceptional case - The draft is not intended for temporary groups Another potential one, not discussed: The situation of policy conflict between Diameter client and Diameter server has to be handled by the application. Regards, Benoit --------------080409060608000007010104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Marco,

I didn't express myself correctly this morning: not enough coffee or maybe too many.

My high level points were:
- The draft doesn't mention that mid-session group assignment modifications is an exceptional case
- The draft is not intended for temporary groups

Another potential one, not discussed: The situation of policy conflict between Diameter client and Diameter server has to be handled by the application.

Regards, Benoit
--------------080409060608000007010104-- From nobody Tue Jul 22 08:09:53 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DC01A0AE5 for ; Tue, 22 Jul 2014 08:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 uEGCNDr-a8PK for ; Tue, 22 Jul 2014 08:09:48 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 155CE1A007A for ; Tue, 22 Jul 2014 08:09:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D29E91077A9; Tue, 22 Jul 2014 17:09:46 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vG9jjsqCt1p; Tue, 22 Jul 2014 17:09:46 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id B1F61107598; Tue, 22 Jul 2014 17:09:36 +0200 (CEST) Received: from HYDRA.office.hd ([169.254.4.11]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 22 Jul 2014 17:09:36 +0200 From: Marco Liebsch To: Benoit Claise Thread-Topic: draft-ietf-dime-group-signaling-04 feedback Thread-Index: AQHPpbh9DtLWmbBdz0qqyWGm51oxK5usKZJQ Date: Tue, 22 Jul 2014 15:09:36 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D8DD7DE16@Hydra.office.hd> References: <53CE7108.6030300@cisco.com> In-Reply-To: <53CE7108.6030300@cisco.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.202] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D8DD7DE16Hydraofficehd_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/BtQaMj4M2Pszx4cd1o98aQlUvCs Cc: dime mailing list Subject: Re: [Dime] draft-ietf-dime-group-signaling-04 feedback X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 15:09:50 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D8DD7DE16Hydraofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Benoit, please see inline. From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Dienstag, 22. Juli 2014 16:11 To: Marco Liebsch Cc: dime mailing list Subject: draft-ietf-dime-group-signaling-04 feedback Hi Marco, I didn't express myself correctly this morning: not enough coffee or maybe = too many. My high level points were: - The draft doesn't mention that mid-session group assignment modifications= is an exceptional case - The draft is not intended for temporary groups A sessions may be added to one or multiple groups when it is established. M= oving a session from one group to another may happen less often, true. Important is that the spe= cification supports and describes the procedure for mid-session group modifications. So your comment is to highlight that in the draft and classify how frequent= a certain procedure may happen ? We may need to classify the term 'temporary'. A group ID's lifetime may be = temporary and the associated group identifier will be deleted accordingly when the group does= not exists anymore. Sessions, which had been assigned to this group, need individual t= reatment then. Temporary in terms of a single command, I doubt it saves signaling costs, a= s adding/removing a session to a group mid-session requires signaling. Another potential one, not discussed: The situation of policy conflict betw= een Diameter client and Diameter server has to be handled by the applicatio= n. Do you refer to the policy to manage groups and apply commands to a group ?= The draft's permission model has clear rules about which peer can add/remove a session to/from a group. Cert= ain applications may constrain this model even more, so true that the application, or better its specification,= needs to handle potential conflicts. Hope that addresses your point. Best regards, marco Regards, Benoit --_000_69756203DDDDE64E987BC4F70B71A26D8DD7DE16Hydraofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Beno= it,

please see inline.

From: 

Hi Marco,

I didn't express myself correctly this morning: not enough coffee or maybe = too many.

My high level points were:
- The draft doesn't mention that mid-session group assignment modifications= is an exceptional case
- The draft is not intended for temporary groups

 

A sessions may be added to one= or multiple groups when it is established. Moving a session from
one group to another may happen less often, true. Important is that the spe= cification supports and
describes the procedure for mid-session group modifications.

So your comment is to highligh= t that in the draft and classify how frequent a certain procedure
may happen ?

We may need to classify the te= rm ‘temporary’. A group ID’s lifetime may be temporary an= d the

associated group identifier wi= ll be deleted accordingly when the group does not exists
anymore. Sessions, which had been assigned to this group, need individual t= reatment then.

Temporary in terms of a single= command, I doubt it saves signaling costs, as adding/removing
a session to a group mid-session requires signaling.



Another potential one, not discussed: The situation of policy conflict betw= een Diameter client and Diameter server has to be handled by the applicatio= n.

Do you refer to the policy to = manage groups and apply commands to a group ? The draft’s permis= sion model has
clear rules about which peer can add/remove a session to/from a group. Cert= ain applications may constrain this
model even more, so true that the application, or better its specification,= needs to handle potential conflicts.

Hope that addresses your point= .

 

Best regards,

marco
  

 

 


Regards, Benoit

--_000_69756203DDDDE64E987BC4F70B71A26D8DD7DE16Hydraofficehd_-- From nobody Tue Jul 22 20:23:15 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1780B1A0199 for ; Tue, 22 Jul 2014 20:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 mp179ZBLLEBx for ; Tue, 22 Jul 2014 20:23:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AADFA1A0108 for ; Tue, 22 Jul 2014 20:23:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHM72935; Wed, 23 Jul 2014 03:23:07 +0000 (GMT) Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 04:23:07 +0100 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.49]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 11:22:59 +0800 From: "Shishufeng (Susan)" To: Ben Campbell , Steve Donovan Thread-Topic: [Dime] DOIC #54: OC-Report-Type as mandatory AVP Thread-Index: AQHPomk6cevUvjwKcEWz/JbjZMq6hputAq1Q Date: Wed, 23 Jul 2014 03:22:58 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F258DF5F51F@SZXEMA512-MBX.china.huawei.com> References: <53C6754B.5020600@usdonovans.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.62.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2-a3PM5KM4Wntcn-jjvAVO34Nmo Cc: "keith.drage@alcatel-lucent.com" , "dime@ietf.org" Subject: Re: [Dime] DOIC #54: OC-Report-Type as mandatory AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 03:23:13 -0000 Dear Steve, Sorry for late reply due to busy meeting last week. Firstly thanks for kicking off the discussion. I'm not saying that this AVP will never be used, but I believe it can never= be used by a server, e.g. HSS. My understanding is that this AVP is used b= y the agent which may have the realm knowledge. For the case you mentioned = that the HSS has knowledge of the status of all servers for the application= , the HSS would be kind of agent, not a pure server. Anyway, with the AVP a= s an optional, it does not prevent the HSS from using it for this particula= r case. For all other cases, the AVP is useless for the server, I didn't se= e benefit to define it as mandatory for the server to always put this AVP i= nto the message. Best Regards, Susan -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Wednesday, July 16, 2014 10:19 PM To: Steve Donovan Cc: dime@ietf.org Subject: Re: [Dime] DOIC #54: OC-Report-Type as mandatory AVP I thought our chairs had declared a rough consensus on this. Do I have that= confused with another issue? On Jul 16, 2014, at 7:51 AM, Steve Donovan wrote= : > All, >=20 > Now that the restructure of the DOIC specification is complete we need to= start resolving open issues. Those that entered the issues are encouraged= to work to get them closed. >=20 > I'll start on #54 in this email. >=20 > The question is whether the OC-Report-Type AVP is required any time that = an OC-OLR AVP is sent. >=20 > The current version of the draft is the same as the -02 version, showing = the AVP as being required. This was based on an earlier attempt to close t= he issue prior to -02 being published. >=20 > Susan has stated that she does not think it should be required. If I und= erstand correctly this is based on the assumption that an HSS would never s= end an OLR with report-type of any value but host. >=20 > Susan, please correct me if I'm mistaken. >=20 > I don't believe this is a correct assumption. It is reasonable for an HS= S to send an OLR with report-type of realm. This might happen in a non age= nt based deployment or in a deployment where the HSS (or more generically, = server) has knowledge of the status of all servers for the application. >=20 > Based on this, I propose that the text be kept as is and that this issue = be closed without changes to the specification. >=20 > The threshold for changing what is currently in the DOIC specification is= rough consensus in the group that it should be changed. Anyone with an op= inion is encouraged to state it now. This is not a vote (we don't vote in t= he IETF...) but an attempt to see if we have consensus to either close the = issue without a change in the specification or if we have consensus to chan= ge the specification. >=20 > Regards, >=20 > Steve >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Tue Jul 22 21:12:33 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030771B28E6 for ; Tue, 22 Jul 2014 21:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 rXcrRpb5EloO for ; Tue, 22 Jul 2014 21:12:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F37B1A0AA7 for ; Tue, 22 Jul 2014 21:12:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHM75714; Wed, 23 Jul 2014 04:12:27 +0000 (GMT) Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Jul 2014 05:12:25 +0100 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.49]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Wed, 23 Jul 2014 12:12:16 +0800 From: "Shishufeng (Susan)" To: Jouni Korhonen , "Wiehe, Ulrich (NSN - DE/Munich)" , ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt Thread-Index: AQHPpE0KrRWoA7FmWkmnhigPhsKuJJutCRgQ Date: Wed, 23 Jul 2014 04:12:15 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F258DF5F542@SZXEMA512-MBX.china.huawei.com> References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> In-Reply-To: <53CC10A4.4070200@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.62.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dime/pzKBHokNxs_v6m5GqD5Hye6dlfA Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 04:12:32 -0000 Hello all, Please see some views from my side. Best Regards, Susan -----Original Message----- From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Monday, July 21, 2014 2:56 AM To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt Some comments inline.. 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: > Steve, > please see my response inline. > > Regards > Ulrich > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve=20 > Donovan > Sent: Tuesday, July 15, 2014 3:53 PM > To: dime@ietf.org > Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt > > Ulrich, > > Thanks for the comments. Please see my responses inline. > > Regards, > > Steve > On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Hi Steve, >> here are my comments. >> They focus on new text you introduced. I agree that restructuring may re= quire new text, however, I believe that with the new text a new concepts is= introduced which macerates the agreed end-to-end concept and allows all DO= IC agents on the path to do what they wants, so that we end up in a hop-by-= hop concept. > SRD> We have never had an agreement on end-to-end versus hop-by-hop=20 > SRD> and > I believe that we will end up with a hybrid of the two. We have open=20 > issues on agent behavior that Ben and I are attempting to address with=20 > the agent cases draft. > [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop approach = of the roach draft was reason not to proceed with that draft. > > SRD> That said, this type of restructuring of the document is likely=20 > SRD> to > put agreed to behavior in a new light. If there are cases where I=20 > have implied changes to agreed to normative behavior, or if the=20 > informative text is not accurate, then these things need to be corrected. Susan: I support Ulrich's view. In my understanding, the assumption we agre= ed for this basic mechanism is to define an end-to-end approach, not a hop-= by-hop one. I don't see the reason to come back again to this discussion at= this stage. >> >> 1. clause 2.3, second paragraph: >> Should read: "Reacting nodes indicate support for DOIC by including the = OC-Supported-Features AVP into all request messages originated or relayed b= y the Reacting node." > SRD> You mean clause 3.2. > [Wiehe, Ulrich (NSN - DE/Munich)] yes > I agree with the change. >> >> 2. clause 2.3, 3rd paragraph, 1st sentence: >> OC-xxx AVPs must not be included in an answer message when the correspon= ding request did not contain an OC-S-F AVP. > SRD> Agreed. >> >> 3. clause 3.3, 7th paragraph: >> Should read "The reporting node only includes an indication of support f= or one overload abatement algorithm. This is the algorithm that the report= ing node intends to use should it enter an overload condition or requests t= o use while it actually is in an overload condition. Reacting nodes can use= the indicated overload abatement algorithm to prepare for possible overloa= d reports and must use the indicated overload abatement algorithm if traffi= c reduction is actually requested." > SRD. OK. >> >> 4. clause 3.3, 10th paragraph: >> The 1st sentence is misleading. In the general case, agents on the path = between reacting node and reporting node are transparent. I agree that ther= e are exceptions to the general case where an agent on the path is not tran= sparent, but then the agent IS the reporting node (reporting to the sender = of the request) and it also IS the reacting node (reacting on reports recei= ved from the upstream reporting node). >> The first 3 words of the second sentence "in this case" need clarificati= on: "In the case where an agent takes the role of a reporting node (reporti= ng to the downstream reacting node) and at the same time takes the role of = a reacting node (reacting on reports received from an upstream reporting no= de)". >> Last sentence: Its not an update but a replacement. The two DOIC associa= tions are handled independently. > SRD> I don't know what you mean when you say an agent is transparent. > Agents must take an active role in even the most basic case for=20 > overload handling to work, so they cannot be transparent. > [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not supp= ort DOIC are transparent. Agents that support DOIC in most cases behave lik= e non supporting agents. I am towards Ulrich's view here. Even for an agent that understands DOIC it= is up to the local policy whether it is transparent or takes an active rol= e. Susan: Same, agree with Ulrich. Agents may only be non-transparent in case = the agent supports DOIC, and the server or client does not support DOIC or = in case the agent which supports DOIC itself overloads, which is to be addr= essed in another draft. For the basic case, I don't see the need for the ag= ent to do anything related to DOIC if both server and client support DOIC. >> 5. clause 3.3, last paragraph: >> General rules shall be followed for each of the two associations separat= ely. The content of the OC-S-F AVP sent by the agent upstream should reflec= t what the agent is able and willing to support (as always). > SRD> What two associations? Is there one association (end-to-end) or=20 > SRD> is > the an association on both sides of the agent (hop-by-hop)? Or is=20 > there an association that involves three entities, the reporting node,=20 > an agent reacting node for realm-routed requests and a=20 > transaction-client reporting node for handling host-routed requests? > [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, There is=20 > one association between C and A, and one association between A and S. Bot= h associations are "end-to-end" as there may be transparent (supporting or = non-supporting) agents in the middle. >> >> 6. clause 3.4, 2nd paragraph: >> Should read: "The OC-OLR AVP is referred to as an overload report. The = OC-OLR AVP includes the type of report, a sequence number, the length of ti= me that the report is valid and abatement algorithm specific AVPs." > SRD> The sequence number is being used as an overload report ID. I can > make the change but I don't see it as necessary. > [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. OK to do the change. >> 7. clause 3.4, 4th paragraph, 2nd sentence: >> I cannot understand this sentence. Probably only simple typos but I don'= t know. > SRD> Yes, a typo (this instead of the) and awkward wording. How about > "This applies to requests that contain the Destination-Host AVP with a=20 > DiameterIdentity that matches the overload report. > [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that contain= a DiameterIdentity in the Destination-Host AVP that matches the reporting = host's DiameterIdentity" I would be inclined to keep the text Steve proposed. But both are ok actual= ly. >> >> 8. clause 3.4, 4th paragraph last 2 sentences: >> I don't understand and probably do not agree. > SRD> See above. >> >> 9. clause 3.5, 3rd paragraph, last word: >> Should read "communicated" > SRD> Agreed. >> >> 10. clause 3.5, 4th paragraph, 1st sentence: >> I don't understand. I can understand: "Reporting nodes use the OC-OLR AV= P to communicate overload occurances towards reacting nodes." > SRD> Who else would reports be sent to? > [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement algorith= m but the reporting node that uses the OC-OLR AVP to communicate overload o= ccurances. Agree. >> 11. clause 4.1, 3rd paragraph, last 4 words: >> may be misleading. A DOIC supporting agent sitting between DOIC supporti= ng client and DOIC supporting Server is transparent with regard to DOIC. Th= is agent does not indicate DOIC support. > SRD> I disagree. > [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Should = be: ...This agent does not indicate its DOIC support, rather it transparent= ly forwards the client's DOIC support. Agree with Ulrich on the intent of agent behavior but not with the proposed= text change. Susan: Agree with Ulrich. >> 12. clause 4.1, 4th paragraph, 2nd sentence: >> Should read:"If a request message handled by the DOIC agent does not inc= lude the OC-Supported-Features AVP then the DOIC agent inserts the AVP." > SRD> That is what it already says. > [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... OC-Supported-Features can be in both request and answer, thus "If a message= " in that sense is correct. >> 13. clause 4.1, last sentence: >> Should read "If the message already has the AVP then the agent either le= aves it unchanged in the relayed message or replaces it to reflect the feat= ures the agent is able and willing to support." Clarification is needed to = say that strict rules must be followed by the agent to select the correct o= ption. These rules take into account whether the request is host-routed or = relam-routed and whether the agent is configured to select the server for r= ealm-routed requests. > SRD> This is a topic on agent behavior that is addressed in the agent > cases draft. I'll leave the discussion for what the wording should be=20 > to the discussion on that draft. >> >> 14. clause 4.1.2, 2nd paragraph: >> Should read: "Based on the content of the OC-Supported-Features AVP in t= he request message, the reporting node knows what overload control function= ality is supported by the reacting node. The reporting node then acts acco= rdingly for the subsequent answer messages it initiates for the transaction= ." > SRD> It would be easier if you didn't make it difficult to understand > the change you are proposing. I think you are proposing changing > node(s) to node. I don't agree but that will be addressed as part of=20 > the agent cases discussion. > [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing two se= ntences? The proposal is to insert "is" between "functionality" and "suppor= ted", to add "the" between "by" and "reacting", to replace "node(s)" with "= node", and to insert "for the transaction" after "initiates". Agree with the proposed change. >> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >> Should read: "message's" > SRD> I'm assuming you mean section 4.1.2. > [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, and = 19. > I agree to the change. >> >> 16. clause 4.1, 6th paragraph: >> This should be left to the (future) specification that introduces other = DOIC features. >> >> 17. clause 4.1, 7th paragraph, last 6 words: >> should be based on requiements set by the (future) specification that=20 >> introduces other DOIC features > SRD> Again, clause 4.1.2 -- I don't understand the issue when these=20 > SRD> two > paragraphs are taken together. >> >> 18. clause 4.1, 8th paragraph, last sentence: >> Should read: "Lack of the OC-Supported-Features AVP in the request messa= ge indicates that there is no downstream reacting node for the transaction.= " > SRD> I think you mean clause 4.1.2. I don't see the need for the change. > [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not correc= t. It should either read: "Lack of the OC-Supported-Feature AVP in the requ= est message indicates to the reporting node that there is no reacting node = for the transaction" or as proposed above. I don't see a reason for the change. Original text seem correct to me. >> 19. clause 4.1, last sentence: >> Should read: "An agent MAY replace the OC-Supported-Features AVP carried= in answer messages." This replacement must follow general rules. Its not s= o that the agent may do what ever it wants to. The decision must be based o= n whether or not the agent has replaced the OC-S-F in the corresponding req= uest. > SRD> What is the difference between modify and replace? I am ok with > removing this statement until we have the agent behavior discussion. =20 > I thought I had taken the agent specific statements out of this version. > [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with identical = values. You remove what has been received in and insert your own stuff. Agent (proxy) can always do that i.e. modify the APV contents. Obviously if= an agent tampers the OC-Supported-Features AVP it needs to know what it is= doing. In general agree with the clarification but not with the proposed t= ext. Susan: Modify is fine. If it is with identical values, the agent can leave = it unchanged even the agent is going to do something. - Jouni >> 20. clause 5.2, 1st sentence: >> Should read: "A reporting node using the loss algorithm must use the OC-= Reduction-Percentage AVP (Section 6.7) to indicated the desired percentage = of traffic reduction." > SRD> Agreed. >> >> 21. clause 5.2, last sentence: >> Should read: "Editor's note: The above duplicates what is in the OC-Redu= ction-Percentage AVP section and can probably be removed." > SRD> Yes, bad wording. The note will be removed, bad wording and all, > once there is a discussion on if this is redundant. >> >> 22. clause 5.4, 6th paragraph: >> Should read: "If the reacting node does not receive a an OLR in the answ= er that corresponds to the probe request messages sent to the formally over= loaded node then the reacting node should slowly increase the rate of traff= ic sent to the overloaded node." > SRD Agreed, this is more clear. >> >> >> Best regards >> Ulrich >> >> >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve=20 >> Donovan >> Sent: Saturday, July 05, 2014 9:42 PM >> To: dime@ietf.org >> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >> >> All, >> >> This version of the DOIC draft is a restructuring of previously=20 >> agreed to content. >> >> The master plan for the restructuring is in Appendix C. This=20 >> outlines where material from -02 was moved in -03. >> >> For those interested, the work was done in steps, with a snapshot for=20 >> each step available here: >> >> https://github.com/jounikor/draft-docdt-dime-ovli >> >> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >> >> where nn indicates the subversion and "text" indicates the focus for=20 >> that subversion. >> >> The next step will be to resolve open issues already identified and=20 >> those yet those yet to be identified. >> >> Regards, >> >> Steve >> >> >> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >>> This draft is a work item of the Diameter Maintenance and Extension= s Working Group of the IETF. >>> >>> Title : Diameter Overload Indication Conveyance >>> Authors : Jouni Korhonen >>> Steve Donovan >>> Ben Campbell >>> Lionel Morand >>> Filename : draft-ietf-dime-ovli-03.txt >>> Pages : 48 >>> Date : 2014-07-03 >>> >>> Abstract: >>> This specification documents a Diameter Overload Control (DOC) ba= se >>> solution and the dissemination of the overload report information= . >>> >>> Requirements >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-ovli-03 >>> >>> >>> Please note that it may take a couple of minutes from the time of=20 >>> submission until the htmlized version and diff are available at tools.i= etf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Wed Jul 23 06:00:40 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608EA1B279A for ; Wed, 23 Jul 2014 06:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_NEUTRAL=0.779] autolearn=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 hRtNJutZD_m0 for ; Wed, 23 Jul 2014 06:00:32 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 66ED31ABB20 for ; Wed, 23 Jul 2014 06:00:32 -0700 (PDT) Received: from dhcp-a698.meeting.ietf.org ([31.133.166.152]:60372) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X9w9i-0003Mz-Qu for dime@ietf.org; Wed, 23 Jul 2014 06:00:31 -0700 Message-ID: <53CFB1EA.9070008@usdonovans.com> Date: Wed, 23 Jul 2014 09:00:26 -0400 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 CC: "dime@ietf.org" References: <53C6754B.5020600@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF5F51F@SZXEMA512-MBX.china.huawei.com> In-Reply-To: <26C84DFD55BC3040A45BF70926E55F258DF5F51F@SZXEMA512-MBX.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-1.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/jUrmQeFqhtX4RQ1U5pufBT_2aFg Subject: Re: [Dime] DOIC #54: OC-Report-Type as mandatory AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 13:00:37 -0000 Susan, Please see the referenced email. This issue has been closed due to an earlier declaration that rough consensus has been achieved. http://www.ietf.org/mail-archive/web/dime/current/msg07499.html Regards, Steve On 7/22/14, 11:22 PM, Shishufeng (Susan) wrote: > Dear Steve, > > Sorry for late reply due to busy meeting last week. > > Firstly thanks for kicking off the discussion. > > I'm not saying that this AVP will never be used, but I believe it can never be used by a server, e.g. HSS. My understanding is that this AVP is used by the agent which may have the realm knowledge. For the case you mentioned that the HSS has knowledge of the status of all servers for the application, the HSS would be kind of agent, not a pure server. Anyway, with the AVP as an optional, it does not prevent the HSS from using it for this particular case. For all other cases, the AVP is useless for the server, I didn't see benefit to define it as mandatory for the server to always put this AVP into the message. > > Best Regards, > Susan > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, July 16, 2014 10:19 PM > To: Steve Donovan > Cc: dime@ietf.org > Subject: Re: [Dime] DOIC #54: OC-Report-Type as mandatory AVP > > I thought our chairs had declared a rough consensus on this. Do I have that confused with another issue? > > On Jul 16, 2014, at 7:51 AM, Steve Donovan wrote: > >> All, >> >> Now that the restructure of the DOIC specification is complete we need to start resolving open issues. Those that entered the issues are encouraged to work to get them closed. >> >> I'll start on #54 in this email. >> >> The question is whether the OC-Report-Type AVP is required any time that an OC-OLR AVP is sent. >> >> The current version of the draft is the same as the -02 version, showing the AVP as being required. This was based on an earlier attempt to close the issue prior to -02 being published. >> >> Susan has stated that she does not think it should be required. If I understand correctly this is based on the assumption that an HSS would never send an OLR with report-type of any value but host. >> >> Susan, please correct me if I'm mistaken. >> >> I don't believe this is a correct assumption. It is reasonable for an HSS to send an OLR with report-type of realm. This might happen in a non agent based deployment or in a deployment where the HSS (or more generically, server) has knowledge of the status of all servers for the application. >> >> Based on this, I propose that the text be kept as is and that this issue be closed without changes to the specification. >> >> The threshold for changing what is currently in the DOIC specification is rough consensus in the group that it should be changed. Anyone with an opinion is encouraged to state it now. This is not a vote (we don't vote in the IETF...) but an attempt to see if we have consensus to either close the issue without a change in the specification or if we have consensus to change the specification. >> >> Regards, >> >> Steve >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > From nobody Wed Jul 23 09:59:16 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A15A1B2821 for ; Wed, 23 Jul 2014 09:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 s2sl0KUYG9Gf for ; Wed, 23 Jul 2014 09:59:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C1D1B27FB for ; Wed, 23 Jul 2014 09:59:11 -0700 (PDT) Received: from localhost ([::1]:45038 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1X9zsg-0004rh-VE; Wed, 23 Jul 2014 09:59:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, srdonovan@usdonovans.com X-Trac-Project: dime Date: Wed, 23 Jul 2014 16:59:06 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/55#comment:2 Message-ID: <081.982866c57f1fe907678a1137d01461f5@trac.tools.ietf.org> References: <066.8875fa1c8b7c849ad37eea1864d456e0@trac.tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <066.8875fa1c8b7c849ad37eea1864d456e0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-dime-ovli@tools.ietf.org, jouni.nospam@gmail.com, srdonovan@usdonovans.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, lionel.morand@orange.com, srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/EAYqSZ9AiAVxKsvalcLu_D_D6Bo Cc: dime@ietf.org Subject: Re: [Dime] [dime] #55 (draft-ietf-dime-ovli): Lack of overload control for realm overload condition X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2014 16:59:14 -0000 #55: Lack of overload control for realm overload condition Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => wontfix Comment: The consensus of the group is to address the requirement to be able to send an overload report that controls the amount of traffic sent to a realm, independent of the type of request, in a future extension to the DOIC specification. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-dime- srdonovan@usdonovans.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: draft-ietf-dime-ovli | Version: Severity: Active WG Document | Resolution: wontfix Keywords: | -------------------------------------+------------------------------------- Ticket URL: dime From nobody Wed Jul 23 18:10:30 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD461A03C0 for ; Wed, 23 Jul 2014 18:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 BGYKIIqyec0m for ; Wed, 23 Jul 2014 18:10:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE41B1A0381 for ; Wed, 23 Jul 2014 18:10:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHN63184; Thu, 24 Jul 2014 01:10:24 +0000 (GMT) Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Jul 2014 02:10:23 +0100 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.49]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Thu, 24 Jul 2014 09:10:17 +0800 From: "Shishufeng (Susan)" To: Steve Donovan Thread-Topic: [Dime] DOIC #54: OC-Report-Type as mandatory AVP Thread-Index: AQHPomk6cevUvjwKcEWz/JbjZMq6hpuuaSxw Date: Thu, 24 Jul 2014 01:10:16 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F258DF5F88A@SZXEMA512-MBX.china.huawei.com> References: <53C6754B.5020600@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF5F51F@SZXEMA512-MBX.china.huawei.com> <53CFB1EA.9070008@usdonovans.com> In-Reply-To: <53CFB1EA.9070008@usdonovans.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.62.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7U61j6HzPwXgMhgqVQGaOVMFpBY Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC #54: OC-Report-Type as mandatory AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 01:10:28 -0000 Hello Steve, I don't think so. If it is closed, it should be reopened. I ever raised twice regarding this issue before version 02 and version 03 a= nd no one replied. It was strange to close an issue people still have conce= rn and not convinced. Lionel please clarify how the consensus was reached, = on which I really don't understand. Though IETF may not be the same as 3GPP= , while I still think you should have some fair ways to reach consensus, no= t like this. It is obvious that almost all 3GPP colleagues think there is n= o reason to have this AVP as mandatory, except Lionel maybe. Best Regards, Susan -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Wednesday, July 23, 2014 9:00 PM Cc: dime@ietf.org Subject: Re: [Dime] DOIC #54: OC-Report-Type as mandatory AVP Susan, Please see the referenced email. This issue has been closed due to an earl= ier declaration that rough consensus has been achieved. http://www.ietf.org/mail-archive/web/dime/current/msg07499.html Regards, Steve On 7/22/14, 11:22 PM, Shishufeng (Susan) wrote: > Dear Steve, > > Sorry for late reply due to busy meeting last week. > > Firstly thanks for kicking off the discussion. > > I'm not saying that this AVP will never be used, but I believe it can nev= er be used by a server, e.g. HSS. My understanding is that this AVP is used= by the agent which may have the realm knowledge. For the case you mentione= d that the HSS has knowledge of the status of all servers for the applicati= on, the HSS would be kind of agent, not a pure server. Anyway, with the AVP= as an optional, it does not prevent the HSS from using it for this particu= lar case. For all other cases, the AVP is useless for the server, I didn't = see benefit to define it as mandatory for the server to always put this AVP= into the message. > > Best Regards, > Susan > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, July 16, 2014 10:19 PM > To: Steve Donovan > Cc: dime@ietf.org > Subject: Re: [Dime] DOIC #54: OC-Report-Type as mandatory AVP > > I thought our chairs had declared a rough consensus on this. Do I have th= at confused with another issue? > > On Jul 16, 2014, at 7:51 AM, Steve Donovan wro= te: > >> All, >> >> Now that the restructure of the DOIC specification is complete we need t= o start resolving open issues. Those that entered the issues are encourage= d to work to get them closed. >> >> I'll start on #54 in this email. >> >> The question is whether the OC-Report-Type AVP is required any time that= an OC-OLR AVP is sent. >> >> The current version of the draft is the same as the -02 version, showing= the AVP as being required. This was based on an earlier attempt to close = the issue prior to -02 being published. >> >> Susan has stated that she does not think it should be required. If I un= derstand correctly this is based on the assumption that an HSS would never = send an OLR with report-type of any value but host. >> >> Susan, please correct me if I'm mistaken. >> >> I don't believe this is a correct assumption. It is reasonable for an H= SS to send an OLR with report-type of realm. This might happen in a non ag= ent based deployment or in a deployment where the HSS (or more generically,= server) has knowledge of the status of all servers for the application. >> >> Based on this, I propose that the text be kept as is and that this issue= be closed without changes to the specification. >> >> The threshold for changing what is currently in the DOIC specification i= s rough consensus in the group that it should be changed. Anyone with an o= pinion is encouraged to state it now. This is not a vote (we don't vote in = the IETF...) but an attempt to see if we have consensus to either close the= issue without a change in the specification or if we have consensus to cha= nge the specification. >> >> Regards, >> >> Steve >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > From nobody Thu Jul 24 11:17:55 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457BD1B27B5 for ; Thu, 24 Jul 2014 11:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 pvHw1d5qQBwt for ; Thu, 24 Jul 2014 11:17:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5E2061B27B8 for ; Thu, 24 Jul 2014 11:17:39 -0700 (PDT) Received: from [10.0.1.4] (dhcp-8c60.meeting.ietf.org [31.133.140.96]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6OIHVSo002024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Jul 2014 13:17:34 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host dhcp-8c60.meeting.ietf.org [31.133.140.96] claimed to be [10.0.1.4] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53CC5DC3.4050507@gmail.com> Date: Thu, 24 Jul 2014 14:17:30 -0400 X-Mao-Original-Outgoing-Id: 427918650.542312-2ac21c9ba671ec735b963d5166825ce2 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CC28C1.50102@usdonovans.com> <53CC5DC3.4050507@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/BR_Dlf8pPRp_hgiwMPMk60KeMaA Cc: "dime@ietf.org" Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:17:50 -0000 On Jul 20, 2014, at 8:24 PM, Jouni Korhonen = wrote: >>> I am towards Ulrich's view here. Even for an agent that understands >>> DOIC it is up to the local policy whether it is transparent or takes >>> an active role. >>>=20 >> I think I agree with Jouni's statement that whether a DOIC agent is >> "transparent" is up to local policy. I need someone to formally = define >> transparent before I can fully agree. If transparent means = equivalent >> in behavior to a non DOIC agent, which I think Ulrich is implying, = then >> I do not agree. >=20 > Agree that "transparent" is a bit bad wording here, because for me at = least "transparent proxies" have a strong existing behavioral model = (from HTTP proxies that is..). >=20 > For me the DOIC agent behaviour should be the following (by local = configuration etc): >=20 > 1) the DOIC feature is turned off. The agent behaves like > non-DOIC enabled agent. For specification purposes, I think we can consider a DOIC node with = DOIC turned off to be the same thing as a non-supporting node. We don't = care if they _can_ support DOIC, only if they _do_. >=20 > 2) the DOIC feature is on and the local policy says the agent > check every message to apply the DOIC thing. This could > be e.g. behaving as an endpoint for non-supporting nodes. I think it's important an agent (including a relay) is allowed to do = this. I gather from the thread so far that some think it should not be = allowed to do so. >=20 > 3) the DOIC feature is on but the local policy selectively > picks up the messages it needs to apply the DOIC thing > (this could be handled e.g. based on ACLs on both IP > and Diameter level). Otherwise the same as 2) This is an interesting case. As others have noted, there is no = externally visible difference (on a given transaction) between a = DOIC-supporting agent that forwards OC-S-F unchanged, and an = non-supporting agent. That brings up an important question that we = discussed a little bit in the working group meeting: Do we need the = ability to tell if a peer agent supports DOIC? I _think_ we do. I think the same arguments we used on whether a client = or server being able to tell if the server or client supported DOIC = apply here. Peer nodes need to be able to apply local policy in ways = that may be different depending on whether the immediate peer (including = a peer which is an agent) supports DOIC or not. For an example (a simplified version of the use case I showed in the wg = meeting), consider that an operator only wants to send OLRs to nodes = that are authorized to receive it. It might trust a DOIC-supporting = agent to enforce that policy, but not trust a non-supporting agent to do = it. In the former case, it includes the OLR, in the later case, it does = not. But it can't make that distinction without knowledge of whether the = agent supports DOIC. From nobody Thu Jul 24 11:23:32 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB5E1A033C for ; Thu, 24 Jul 2014 11:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 s7AVpe9BDJxM for ; Thu, 24 Jul 2014 11:23:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 444EC1A00DC for ; Thu, 24 Jul 2014 11:23:29 -0700 (PDT) Received: from [10.0.1.4] (dhcp-8c60.meeting.ietf.org [31.133.140.96]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6OIMXkS002459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Jul 2014 13:22:35 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host dhcp-8c60.meeting.ietf.org [31.133.140.96] claimed to be [10.0.1.4] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <26C84DFD55BC3040A45BF70926E55F258DF5F542@SZXEMA512-MBX.china.huawei.com> Date: Thu, 24 Jul 2014 14:22:32 -0400 X-Mao-Original-Outgoing-Id: 427918952.734932-27b782237a1ae7d8d2e866c2d1473dd9 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <26C84DFD55BC3040A45BF70926E55F258DF5F542@SZXEMA512-MBX.china.huawei.com> To: "Shishufeng (Susan)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/6-9p5IRVQYRIpEstcLQh_DWWNnA Cc: "dime@ietf.org" Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:23:30 -0000 On Jul 23, 2014, at 12:12 AM, Shishufeng (Susan) = wrote: >> SRD> That said, this type of restructuring of the document is likely=20= >> SRD> to >> put agreed to behavior in a new light. If there are cases where I=20 >> have implied changes to agreed to normative behavior, or if the=20 >> informative text is not accurate, then these things need to be = corrected. >=20 > Susan: I support Ulrich's view. In my understanding, the assumption we = agreed for this basic mechanism is to define an end-to-end approach, not = a hop-by-hop one. I don't see the reason to come back again to this = discussion at this stage. I don't recall any consensus in the DIME working group that DOIC was = limited to end-to-end reporting of overload. I agree that it should be = _possible_ to report overload end-to-end, but also possible to do = otherwise. It's entirely reasonable that 3GPP could then agree to limit some = applications to using DOIC end-to-end. But we should be careful not to = build that limitation into the mechanism in the IETF.= From nobody Thu Jul 24 11:33:38 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1AC11B27E8 for ; Thu, 24 Jul 2014 11:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ysIYiis5p3oh for ; Thu, 24 Jul 2014 11:33:35 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 893031B27E9 for ; Thu, 24 Jul 2014 11:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1860; q=dns/txt; s=iport; t=1406226812; x=1407436412; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OexGhBx1IuT5hdbY+W1zA9q7eHzqLao1JqSeuOYsrDM=; b=Hko0HSkdH1lJ9rUp54YArh5iV/UHkFBdfPr7ZKBn5ojaTqh58fnCrERf MDyQJt4182GztQYIlnuFeUNm1ZvCZ7bLHcNAYm+6b1nRWMbeFQ45tHhXv eF6XMO5CAFKyMeduWPjoPmRz9O3H90dIxHAeTSfmwqOYyAIdFnOJ1QZ2R o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAO9Q0VOtJA2J/2dsb2JhbABYgw5SVwTJLAqHRQGBDRZ3hAMBAQEDAQEBATc0BgUMBAIBCBEEAQELFAkHJwsUCQgCBAENBQiIMggNvzsTBI5zASYxBwaDKIEYAQSve4NIbIEDAR8i X-IronPort-AV: E=Sophos;i="5.01,725,1400025600"; d="scan'208";a="63770991" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP; 24 Jul 2014 18:33:32 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6OIXVJr016405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jul 2014 18:33:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 13:33:05 -0500 From: "Nirav Salot (nsalot)" To: Ben Campbell , "Shishufeng (Susan)" Thread-Topic: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt Thread-Index: AQHPlvYBG7pdMU8lTkq6F2nWhP/TapuSOEoAgA4zSQCAASJ2AIAF3kMAgAJR9gCAA8A1gIACf+YA//+t6pA= Date: Thu, 24 Jul 2014 18:33:31 +0000 Message-ID: References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <26C84DFD55BC3040A45BF70926E55F258DF5F542@SZXEMA512-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.77.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/pCYm6xEgJ9Ojz024OTMWzN_PCRw Cc: "dime@ietf.org" Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:33:38 -0000 Even I thought that we agreed end-to-end approach as compared to hop-by-hop= approach at the beginning of working on this draft.=20 In that context the endpoints are the reacting and reporting node between w= hich Overload association is established.=20 So I am also bit puzzled that we are talking about the possibility of hop-b= y-hop approach as part of this draft. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell Sent: Thursday, July 24, 2014 11:53 PM To: Shishufeng (Susan) Cc: dime@ietf.org Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt On Jul 23, 2014, at 12:12 AM, Shishufeng (Susan) wrote: >> SRD> That said, this type of restructuring of the document is likely=20 >> SRD> to >> put agreed to behavior in a new light. If there are cases where I=20 >> have implied changes to agreed to normative behavior, or if the=20 >> informative text is not accurate, then these things need to be corrected= . >=20 > Susan: I support Ulrich's view. In my understanding, the assumption we ag= reed for this basic mechanism is to define an end-to-end approach, not a ho= p-by-hop one. I don't see the reason to come back again to this discussion = at this stage. I don't recall any consensus in the DIME working group that DOIC was limite= d to end-to-end reporting of overload. I agree that it should be _possible_= to report overload end-to-end, but also possible to do otherwise. It's entirely reasonable that 3GPP could then agree to limit some applicati= ons to using DOIC end-to-end. But we should be careful not to build that li= mitation into the mechanism in the IETF. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Thu Jul 24 11:50:12 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802231A0194 for ; Thu, 24 Jul 2014 11:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 TtjYxZ2_QbJL for ; Thu, 24 Jul 2014 11:50:06 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 56D9C1A0AE0 for ; Thu, 24 Jul 2014 11:50:05 -0700 (PDT) Received: from [10.0.1.4] (dhcp-8c60.meeting.ietf.org [31.133.140.96]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6OInqfI004853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Jul 2014 13:49:54 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host dhcp-8c60.meeting.ietf.org [31.133.140.96] claimed to be [10.0.1.4] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: Date: Thu, 24 Jul 2014 14:49:51 -0400 X-Mao-Original-Outgoing-Id: 427920591.575152-fb7e769b23d95cf668a5776613112891 Content-Transfer-Encoding: quoted-printable Message-Id: <7337A70F-9C98-49EE-8DB8-2A656AFDD17A@nostrum.com> References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <26C84DFD55BC3040A45BF70926E55F258DF5F542@SZXEMA512-MBX.china.huawei.com> To: "Nirav Salot (nsalot)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/VWsW8rAC9kxPxtk3xuuR9KMHrD4 Cc: "Shishufeng \(Susan\)" , "dime@ietf.org" Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:50:08 -0000 On Jul 24, 2014, at 2:33 PM, Nirav Salot (nsalot) = wrote: > Even I thought that we agreed end-to-end approach as compared to = hop-by-hop approach at the beginning of working on this draft.=20 > In that context the endpoints are the reacting and reporting node = between which Overload association is established.=20 >=20 > So I am also bit puzzled that we are talking about the possibility of = hop-by-hop approach as part of this draft. I am also a bit puzzled. DOIC endpoints were never assumed to only be = DIameter clients and servers. This was true even of the picture Jouni = drew on the board in Porto. I have never supported a solution that only = allowed end-to-end reporting where the "ends" could only be Diameter = clients and servers. Such a solution would preclude a _lot_ of real = world use cases. Is it possible we are getting wrapped around terminology of what = constitutes a DOIC endpoint? I am okay with an end-to-end approach = between DOIC endpoints, as long as an agent can be a DOIC endpoint. = (But really, we are getting into the realm of philosophy here.) >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: Thursday, July 24, 2014 11:53 PM > To: Shishufeng (Susan) > Cc: dime@ietf.org > Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >=20 >=20 > On Jul 23, 2014, at 12:12 AM, Shishufeng (Susan) = wrote: >=20 >>> SRD> That said, this type of restructuring of the document is likely=20= >>> SRD> to >>> put agreed to behavior in a new light. If there are cases where I=20= >>> have implied changes to agreed to normative behavior, or if the=20 >>> informative text is not accurate, then these things need to be = corrected. >>=20 >> Susan: I support Ulrich's view. In my understanding, the assumption = we agreed for this basic mechanism is to define an end-to-end approach, = not a hop-by-hop one. I don't see the reason to come back again to this = discussion at this stage. >=20 > I don't recall any consensus in the DIME working group that DOIC was = limited to end-to-end reporting of overload. I agree that it should be = _possible_ to report overload end-to-end, but also possible to do = otherwise. >=20 > It's entirely reasonable that 3GPP could then agree to limit some = applications to using DOIC end-to-end. But we should be careful not to = build that limitation into the mechanism in the IETF. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Thu Jul 24 12:55:22 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87ED01A0ADD for ; Thu, 24 Jul 2014 12:55:17 -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, SPF_NEUTRAL=0.779] autolearn=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 WcOM328oC_0o for ; Thu, 24 Jul 2014 12:55:16 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 E5B081A0AAD for ; Thu, 24 Jul 2014 12:55:14 -0700 (PDT) Received: from dhcp-a211.meeting.ietf.org ([31.133.162.17]:53345) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XAP6d-0004FJ-BN for dime@ietf.org; Thu, 24 Jul 2014 12:55:13 -0700 Message-ID: <53D1649F.1010606@usdonovans.com> Date: Thu, 24 Jul 2014 15:55:11 -0400 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <26C84DFD55BC3040A45BF70926E55F258DF5F542@SZXEMA512-MBX.china.huawei.com> <7337A70F-9C98-49EE-8DB8-2A656AFDD17A@nostrum.com> In-Reply-To: <7337A70F-9C98-49EE-8DB8-2A656AFDD17A@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Dthw08J-QM2rBI4st6nciUdFo9U Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 19:55:18 -0000 I believe that the job we have here is to define a set of AVPs and behaviors associated with those AVPs that will allow operators to manage overload in their Diameter networks. I'm not sure where the assumption that moving away from the Roach draft meant there could be no hop-by-hop aspects to the solution. I do think this whole conversation is a red herring, meaning that it is not adding to completing the DOIC solution. We don't have a hop-by-hop solution in what is in the DOIC draft today. We also do not have an pure end-to-end solution. We have a solution where Diameter Clients, Diameter Agents and Diameter Servers do DOIC things. What DOIC things they do depends on the specific scenario. The most basic case that involves agents requires all three types of Diameter nodes to do DOIC things when a server sends a host report. This is shown in the first use case in the agent cases draft. Does the fact that both the client and the agent are reacting nodes make this a hop-by-hop solution? Does it matter? My plan over the next few weeks is to propose detailed text to close the current open issues. I suggest that we keep our focus on whether that text addresses our agreed to requirements. I also remind everyone that we are trying very hard to have this draft ready for IETF working group last call prior to the November IETF meeting. We will need to be aggressive in agreeing to text and closing those issues. To say it another way, let's move on from the hop-by-hop/end-to-end discussion. Regards, Steve On 7/24/14, 2:49 PM, Ben Campbell wrote: > On Jul 24, 2014, at 2:33 PM, Nirav Salot (nsalot) wrote: > >> Even I thought that we agreed end-to-end approach as compared to hop-by-hop approach at the beginning of working on this draft. >> In that context the endpoints are the reacting and reporting node between which Overload association is established. >> >> So I am also bit puzzled that we are talking about the possibility of hop-by-hop approach as part of this draft. > I am also a bit puzzled. DOIC endpoints were never assumed to only be DIameter clients and servers. This was true even of the picture Jouni drew on the board in Porto. I have never supported a solution that only allowed end-to-end reporting where the "ends" could only be Diameter clients and servers. Such a solution would preclude a _lot_ of real world use cases. > > Is it possible we are getting wrapped around terminology of what constitutes a DOIC endpoint? I am okay with an end-to-end approach between DOIC endpoints, as long as an agent can be a DOIC endpoint. (But really, we are getting into the realm of philosophy here.) > >> Regards, >> Nirav. >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell >> Sent: Thursday, July 24, 2014 11:53 PM >> To: Shishufeng (Susan) >> Cc: dime@ietf.org >> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >> >> >> On Jul 23, 2014, at 12:12 AM, Shishufeng (Susan) wrote: >> >>>> SRD> That said, this type of restructuring of the document is likely >>>> SRD> to >>>> put agreed to behavior in a new light. If there are cases where I >>>> have implied changes to agreed to normative behavior, or if the >>>> informative text is not accurate, then these things need to be corrected. >>> Susan: I support Ulrich's view. In my understanding, the assumption we agreed for this basic mechanism is to define an end-to-end approach, not a hop-by-hop one. I don't see the reason to come back again to this discussion at this stage. >> I don't recall any consensus in the DIME working group that DOIC was limited to end-to-end reporting of overload. I agree that it should be _possible_ to report overload end-to-end, but also possible to do otherwise. >> >> It's entirely reasonable that 3GPP could then agree to limit some applications to using DOIC end-to-end. But we should be careful not to build that limitation into the mechanism in the IETF. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Thu Jul 24 15:24:28 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278041A052E for ; Thu, 24 Jul 2014 15:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 VYiU5rqtBMJc for ; Thu, 24 Jul 2014 15:24:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9058F1A01E8 for ; Thu, 24 Jul 2014 15:24:16 -0700 (PDT) Received: from [10.0.1.4] (dhcp-8c60.meeting.ietf.org [31.133.140.96]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6OMODIq023023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Jul 2014 17:24:15 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host dhcp-8c60.meeting.ietf.org [31.133.140.96] claimed to be [10.0.1.4] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53D1649F.1010606@usdonovans.com> Date: Thu, 24 Jul 2014 18:24:12 -0400 X-Mao-Original-Outgoing-Id: 427933452.754784-3252cfdd3797102339e8ac7a66780e6f Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <26C84DFD55BC3040A45BF70926E55F258DF5F542@SZXEMA512-MBX.china.huawei.com> <7337A70F-9C98-49EE-8DB8-2A656AFDD17A@nostrum.com> <53D1649F.1010606@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5M-Bzl9NdAgOeDVk3mS3rXkFp-s Cc: dime@ietf.org Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 22:24:23 -0000 I mostly agree. In fact, I may over-agree, in that I think that people = have it in their minds to say too much, especially in regards to agents. = Almost none of this discussion should result in normative language. = Basically, I think we should allow pretty much any agent behavior that = doesn't break things*, and leave it to the market (and client SDOs) to = decide what's important. (* Where I define "break things" to mean "making things worse than if = the agent did not support DOIC at all".) More inline: On Jul 24, 2014, at 3:55 PM, Steve Donovan = wrote: > I believe that the job we have here is to define a set of AVPs and = behaviors associated with those AVPs that will allow operators to manage = overload in their Diameter networks. >=20 > I'm not sure where the assumption that moving away from the Roach = draft meant there could be no hop-by-hop aspects to the solution. >=20 > I do think this whole conversation is a red herring, meaning that it = is not adding to completing the DOIC solution. >=20 > We don't have a hop-by-hop solution in what is in the DOIC draft = today. We also do not have an pure end-to-end solution. We have a = solution where Diameter Clients, Diameter Agents and Diameter Servers do = DOIC things. What DOIC things they do depends on the specific scenario. I concur, but would go on to say "depends on the specific scenario, = network configuration, and local policy." >=20 > The most basic case that involves agents requires all three types of = Diameter nodes to do DOIC things when a server sends a host report. I disagree that it _requires_ it. I agree that you get better behavior = if you do it, and deployments should be allowed to operate that way. But = if people want to build networks where the agent doesn't do anything = most of the time, they should also be able to do so. For example, they = might have so few realm-routed requests that the extra complexity is not = worth it. (I'm ignoring the question about whether such an agent = supports DOIC at all--let's pretend for the sake of argument it at least = occasionally does something DOICish.) > This is shown in the first use case in the agent cases draft. Does = the fact that both the client and the agent are reacting nodes make this = a hop-by-hop solution? Not at all, but again with the caveat that this is _one_ way of doing = it. > Does it matter? No. >=20 > My plan over the next few weeks is to propose detailed text to close = the current open issues. I suggest that we keep our focus on whether = that text addresses our agreed to requirements. I also remind everyone = that we are trying very hard to have this draft ready for IETF working = group last call prior to the November IETF meeting. We will need to be = aggressive in agreeing to text and closing those issues. >=20 > To say it another way, let's move on from the hop-by-hop/end-to-end = discussion. From nobody Thu Jul 24 21:21:49 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91101A0AE2 for ; Thu, 24 Jul 2014 21:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 DZwwp_arDfGM for ; Thu, 24 Jul 2014 21:21:43 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4DDD1A0ADC for ; Thu, 24 Jul 2014 21:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3367; q=dns/txt; s=iport; t=1406262103; x=1407471703; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SPd0QuxVgTx5OX5o4AOtJNGwF6JawE7jpsFDeInMtzY=; b=l0cutM5j3O4UvAkx6lIayGkmzJtGTWEC1t3WtD+Sf0lIo0qpwu9qH3K1 dud+qByeOnwaFmyXybJA+YtaoDRNXwIsavPQ16INKVEw48mFpFe8izMgE fILypUytwBJOa9v3e5+aotLK8xcpvgGKtZXSi+eCZbeJTGz40FOPw0uls M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMFAL7a0VOtJV2a/2dsb2JhbABZgw5SVwTJRQqHRQGBEhZ3hAMBAQEDAQEBATc0BgUFBwQCAQgRBAEBAQoUCQcnCxQJCAIEDgUIE4gfCA2/VBMEjnMBJjEHBoMogRkFsAWDSGyBAwEfIg X-IronPort-AV: E=Sophos;i="5.01,728,1400025600"; d="scan'208";a="339617324" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 25 Jul 2014 04:21:42 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s6P4LgWx021251 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jul 2014 04:21:42 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 23:21:42 -0500 From: "Nirav Salot (nsalot)" To: Ben Campbell Thread-Topic: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt Thread-Index: AQHPlvYBG7pdMU8lTkq6F2nWhP/TapuSOEoAgA4zSQCAASJ2AIAF3kMAgAJR9gCAA8A1gIACf+YA//+t6pCAAFm4gIAASyug Date: Fri, 25 Jul 2014 04:21:41 +0000 Message-ID: References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <26C84DFD55BC3040A45BF70926E55F258DF5F542@SZXEMA512-MBX.china.huawei.com> <7337A70F-9C98-49EE-8DB8-2A656AFDD17A@nostrum.com> In-Reply-To: <7337A70F-9C98-49EE-8DB8-2A656AFDD17A@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.77.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/pmz9Twf_ExGSp3mW4Mj1qLu80gE Cc: "Shishufeng \(Susan\)" , "dime@ietf.org" Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 04:21:47 -0000 Ben, Are you reading too much between the lines since I never mentioned "client"= or "server" in my e-mail below. End-to-end approach can become hope-by-hop depending upon the network topol= ogy and which nodes are acting as reporting and reacting nodes. But it is s= till not "hop-by-hop" approach since in that case the overload control is s= trictly performed between the nodes sharing the transport connection. Regards, Nirav. -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Friday, July 25, 2014 12:20 AM To: Nirav Salot (nsalot) Cc: Shishufeng (Susan); dime@ietf.org Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt On Jul 24, 2014, at 2:33 PM, Nirav Salot (nsalot) wrote: > Even I thought that we agreed end-to-end approach as compared to hop-by-h= op approach at the beginning of working on this draft.=20 > In that context the endpoints are the reacting and reporting node between= which Overload association is established.=20 >=20 > So I am also bit puzzled that we are talking about the possibility of hop= -by-hop approach as part of this draft. I am also a bit puzzled. DOIC endpoints were never assumed to only be DIame= ter clients and servers. This was true even of the picture Jouni drew on th= e board in Porto. I have never supported a solution that only allowed end-t= o-end reporting where the "ends" could only be Diameter clients and servers= . Such a solution would preclude a _lot_ of real world use cases. Is it possible we are getting wrapped around terminology of what constitute= s a DOIC endpoint? I am okay with an end-to-end approach between DOIC endpo= ints, as long as an agent can be a DOIC endpoint. (But really, we are gett= ing into the realm of philosophy here.) >=20 > Regards, > Nirav. >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: Thursday, July 24, 2014 11:53 PM > To: Shishufeng (Susan) > Cc: dime@ietf.org > Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >=20 >=20 > On Jul 23, 2014, at 12:12 AM, Shishufeng (Susan) wrote: >=20 >>> SRD> That said, this type of restructuring of the document is likely=20 >>> SRD> to >>> put agreed to behavior in a new light. If there are cases where I=20 >>> have implied changes to agreed to normative behavior, or if the=20 >>> informative text is not accurate, then these things need to be correcte= d. >>=20 >> Susan: I support Ulrich's view. In my understanding, the assumption we a= greed for this basic mechanism is to define an end-to-end approach, not a h= op-by-hop one. I don't see the reason to come back again to this discussion= at this stage. >=20 > I don't recall any consensus in the DIME working group that DOIC was limi= ted to end-to-end reporting of overload. I agree that it should be _possibl= e_ to report overload end-to-end, but also possible to do otherwise. >=20 > It's entirely reasonable that 3GPP could then agree to limit some applica= tions to using DOIC end-to-end. But we should be careful not to build that = limitation into the mechanism in the IETF. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Thu Jul 24 21:56:09 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980B01A0ABF for ; Thu, 24 Jul 2014 21:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 dFEqNaKIyF8C for ; Thu, 24 Jul 2014 21:56:06 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2D5DA1A0AD6 for ; Thu, 24 Jul 2014 21:56:06 -0700 (PDT) Received: from [10.0.1.2] (dhcp-8c60.meeting.ietf.org [31.133.140.96]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6P4tuKP069113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 24 Jul 2014 23:55:59 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host dhcp-8c60.meeting.ietf.org [31.133.140.96] claimed to be [10.0.1.2] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ben Campbell X-Mailer: iPad Mail (11D257) In-Reply-To: Date: Fri, 25 Jul 2014 00:55:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <26C84DFD55BC3040A45BF70926E55F258DF5F542@SZXEMA512-MBX.china.huawei.com> <7337A70F-9C98-49EE-8DB8-2A656AFDD17A@nostrum.com> To: "Nirav Salot (nsalot)" Archived-At: http://mailarchive.ietf.org/arch/msg/dime/AtOQmJJQJx0Wif-Gm4TZIAekGl0 Cc: "Shishufeng \(Susan\)" , "dime@ietf.org" Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 04:56:07 -0000 > On Jul 25, 2014, at 12:21 AM, "Nirav Salot (nsalot)" wr= ote: >=20 > Ben, >=20 > Are you reading too much between the lines since I never mentioned "client= " or "server" in my e-mail below. >=20 > End-to-end approach can become hope-by-hop depending upon the network topo= logy and which nodes are acting as reporting and reacting nodes. But it is s= till not "hop-by-hop" approach since in that case the overload control is st= rictly performed between the nodes sharing the transport connection. This appears to be true, and I agree with that characterization.=20 Apologies for the confusion. I was reacting to comments from further down t= he thread that I took to mean people only wanted to allow DOIC to operate be= tween client and server, except for some strictly limited circumstances. I m= ay have misread those as well. Thanks, Ben. From nobody Fri Jul 25 11:48:18 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC851A03E7 for ; Fri, 25 Jul 2014 11:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 l75hAzHXiaj2 for ; Fri, 25 Jul 2014 11:48:12 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5941A03BE for ; Fri, 25 Jul 2014 11:48:12 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id l13so1230768iga.4 for ; Fri, 25 Jul 2014 11:48:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=v2l5jNCzk9Gw0sKrX5A4Dk4aYeO96DEQ5ZBrAhtbbMw=; b=PUaIxhb6+gA9GNVQoL2JA/ec+EYTYFS75SdBkeO4nnPowFUjIF7YnOXx7YfxCtmsW+ BKyiJnXpAZYqt92YwB/nADDEUnHzhyYLwXswqsyDm/LRjQBwvPeyp0k7poyXhY1FgED7 SppYg8wfEN3hRrxOVzioVRECDK1ABN/Vl2OeUtzQjCvGhsb8zewEMdcERv0s7/QYmnoZ k9iEZ1CoV6iaDdI3Uh1Rq2vXT+bvQ1pE71AbIsctalgWH2M95R+7NfD4pzpfmYTGCmgU +3j13oq+SxKrclzH/1oglkEIrRb9kpwKrfeENQ5ujO6XnVodIGq8GjDxkZi6St3Eg4g4 IWgA== X-Received: by 10.50.67.51 with SMTP id k19mr8247503igt.39.1406314091739; Fri, 25 Jul 2014 11:48:11 -0700 (PDT) Received: from [192.168.11.218] ([66.78.101.1]) by mx.google.com with ESMTPSA id x3sm6976318igl.7.2014.07.25.11.48.10 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Jul 2014 11:48:11 -0700 (PDT) Message-ID: <53D2A667.40701@gmail.com> Date: Fri, 25 Jul 2014 14:48:07 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "dime@ietf.org" References: <20140725184327.20047.67976.idtracker@ietfa.amsl.com> In-Reply-To: <20140725184327.20047.67976.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140725184327.20047.67976.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Lo3nmpYQXkETIbKqE40jMbMAnqc Subject: [Dime] Fwd: New Version Notification for draft-taylor-dime-addressorprefix-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 18:48:14 -0000 As suggested in the meeting, I split out the definition of the AddressOrPrefix AVP derived data format into a separate draft. I've marked it as "Updates RFC6733". Comments are welcome. Looking to make this a WG work item. Tom Taylor -------- Forwarded Message -------- Subject: New Version Notification for draft-taylor-dime-addressorprefix-00.txt Date: Fri, 25 Jul 2014 11:43:27 -0700 From: internet-drafts@ietf.org To: Tom Taylor , Tom Taylor A new version of I-D, draft-taylor-dime-addressorprefix-00.txt has been successfully submitted by Tom Taylor and posted to the IETF repository. Name: draft-taylor-dime-addressorprefix Revision: 00 Title: The AddressOrPrefix Derived AVP Data Format For Diameter Document date: 2014-07-25 Group: Individual Submission Pages: 4 URL: http://www.ietf.org/internet-drafts/draft-taylor-dime-addressorprefix-00.txt Status: https://datatracker.ietf.org/doc/draft-taylor-dime-addressorprefix/ Htmlized: http://tools.ietf.org/html/draft-taylor-dime-addressorprefix-00 Abstract: Section 4.3.1 of the Diameter base specification [RFC6733] defines a number of derived AVP data formats. This collection includes the Address format, which is suitable for encoding complete addresses. In some potential applications, however, there is a requirement to encode a prefix rather than a complete address. This document defines the AddressOrPrefix derived AVP data format, modelled after the Address format defined in [RFC6733], but allowing the same AVP to represent a prefix of any length up to a full address. This document updates RFC 6733. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Jul 28 05:24:30 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191211A0174 for ; Mon, 28 Jul 2014 05:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 JPbLVoFkRi0M for ; Mon, 28 Jul 2014 05:24:26 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E07C1A0377 for ; Mon, 28 Jul 2014 05:24:26 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id e16so5387754lan.31 for ; Mon, 28 Jul 2014 05:24:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=mda0hGug+khGy5L0xxd1zumsTab3JLn0zs87oyTzzf0=; b=aKXXnZ2sSeTecI5O3BhEErKtDBlP6RdpYi62lc0OSpQwvyA4Pps4wI2xjQ8cyRhDZ4 oJZbXvXm0pcRm+zUcB2SKwpYJ4uJJnbsdIrUq6EySIga71/mcq+Rk1D70wIywN+/dgu3 wu2lNwujdESLmBgw+wYF9GNvNrps46z2OgyQ9d4IjzU1GcWgm6NTF1g9VkUQ62anKch4 +M7kA+kUoQbTvqWhFtNkPrTSrVIUAzHAzft7fJt4nSoKr4iHnvKU8uYvdkh+uerTt8GK CRpJa/Rz34gDZB3k3YS9A3v1MFZrZNEiCCZq/6kKlk7wZlD6HeZopNCGb46MDqdGwMrK R+hw== X-Received: by 10.112.159.200 with SMTP id xe8mr33292380lbb.55.1406550264769; Mon, 28 Jul 2014 05:24:24 -0700 (PDT) Received: from [192.168.250.37] ([194.100.71.98]) by mx.google.com with ESMTPSA id g8sm12272642lam.23.2014.07.28.05.24.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 05:24:23 -0700 (PDT) Message-ID: <53D640F6.5080502@gmail.com> Date: Mon, 28 Jul 2014 15:24:22 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/QKTG9U0V1ZCDtlFokaG6WMyWg84 Subject: [Dime] meeting minutes uploada X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 12:24:28 -0000 Thanks to Jean for extensive minutes & notes: http://tools.ietf.org/wg/dime/minutes?item=minutes-90-dime.html - Jouni From nobody Tue Jul 29 00:29:16 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4961A009E for ; Tue, 29 Jul 2014 00:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 MMGHJoNukdvm for ; Tue, 29 Jul 2014 00:29:10 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3293F1A026A for ; Tue, 29 Jul 2014 00:29:10 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s6T7T8ow007979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Jul 2014 07:29:08 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s6T7T4Kh006640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 09:29:04 +0200 Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 29 Jul 2014 09:29:04 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0195.001; Tue, 29 Jul 2014 09:29:04 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) Thread-Index: AQHPpPA/36IwRToz/kGtAPmPhYVJupuqvVow Date: Tue, 29 Jul 2014 07:29:03 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> In-Reply-To: <53CD23BD.8010906@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 24175 X-purgate-ID: 151667::1406618948-00007A71-ABC1AEB9/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/CvGb8fpOERfSHYhU6TB3zxfytpQ Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 07:29:16 -0000 Steve, I can agree with most of your statements. A DOICable agent needs to determine in which scenario it actually is. This = decision must be based on presence/absence of OC-S-F-AVP in the received re= quests, presence/absence of Destination-Host AVP in the received request an= d configuration data (configured to select/not to select the server for rea= lm routed requests). Once this decision is taken the agent a) inserts an OC-S-F to the request, or b) transparently forwards the request (i.e. does not remove or add an OC-S-= F AVP), or c) removes the received OC-S-F AVP and inserts its own OC-S-F AVP note that c) includes the case where the removed AVP and the inserted AVP a= re identical. Case b) is the transparent case where the agent - although it supports DOIC= (and DOIC is not turned off) - from an external point of view behaves like= a non-DOICable node. See also inline. Regards, Ulrich (still trying to catch up with lots of mails) -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Monday, July 21, 2014 4:29 PM To: dime@ietf.org Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime= -ovli-03.txt) Ulrich, I am not arguing that all agents should take an active role in the=20 handling of all overload reports. What I am arguing is that there are=20 scenarios where an agent must take an active role in DOIC to ensure that=20 a requested reduction in traffic an be achieved. For DOIC to work a carrier cannot turn off all DOIC behavior in agents,=20 as suggested by Jouni. I agree that in your scenario below, a1 does not need to take an active=20 role in reducing traffic when c supports DOIC. a1 should take an active=20 role when c does not support DOIC. The problem is that a1 does not know=20 in advance whether c supports DOIC so it will need to inspect all=20 transactions for the presence of OC-S-F to determine if it needs to=20 handle overload reports for a non supporting client. I agree Does that mean a1 is transparent if it inspects all requests and does=20 nothing in the case where there is c supports DOIC? yes Does transparent mean that there is no observable difference in the DOIC=20 AVPs that pass through the agent yes or does it mean that there is no=20 observable difference in how transactions are handled by the DOIC agent? no I'm guessing that we have multiple assumptions on what transparent means=20 and, if we are going to continue saying agents should be transparent=20 then we need a definition of transparent. I think for this use case, we need the following normative statements in=20 the draft for handling of abatement of realm-routed requests? I think=20 this is general behavior and should go in the section on handling of=20 overload reports. "DOIC nodes with a direct transport connection to a reporting node that=20 has an active overload report must handle abatement of realm-routed=20 requests. The preferred method for handling abatement of realm-routed=20 requests is diversion, where the node with the direct transport=20 connection routes the request to an alternative server that is able to=20 handle the request. If there is no alternative server with the needed=20 capacity to handle the request then the DOIC node must/should throttle=20 the necessary requests to meet the requested reduction in traffic." My proposal: "A DOIC node with performs server selection for realm routed requests that= =20 has active overload reports from servers it potentially selects, must handle abatement of realm-routed=20 requests. The preferred method for handling abatement of realm-routed=20 requests is diversion, where the node selecting the server routes the request to an alternative server that is able to=20 handle the request. If there is no alternative server with the needed=20 capacity to handle the request then the DOIC node must/should preferrably delegate abatement (of realm routed requests) towards a downstream reacting node or otherwise throttle=20 the necessary requests to meet the requested reduction in traffic." If we can agree on this then we can move on to the next agent based use=20 case. Regards, Steve On 7/21/14, 9:47 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > The example you show is absolutely valid and 100% inline with A) to F) - = (assuming that all servers can serve any request). > However, there are other scenarios like: > > > =20 > +--+ > /--|s1| > +-+ +--+ +--+ / +--+ > |c|--- |a1|--|a2|=3D=3D ... > +-+ +--+ +--+ \ +--+ > \--|sn| > +--+ > > Here I think a1 should be transparent even when DOICable. > a1 does not take the role of a reacting node since c supports DOIC. > a1 does not perform server selection and therefore does not take the role= of a reporting node (for realm-reports). > > Ulrich > > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Monday, July 21, 2014 3:16 PM > To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich)= ; dime@ietf.org > Subject: Transparent agents (was Re: [Dime] I-D Action: draft-ietf-dime-o= vli-03.txt) > > Ok, let's see if it's possible to completely turn off all DOIC behavior > in agents and still be able to reduce traffic to a server that sends a > host overload report. > > Assume the following agent based deployment: > > +--+ > /--|s1| > +-+ +-+ / +--+ > |c|--|a|=3D=3D ... > +-+ +-+ \ +--+ > \--|sn| > +--+ > > Assume that there is a large number of servers, say 50. > > Now, assume that the Diameter application in question exclusively uses > realm-routed requests - 100% of requests sent by the client do NOT have > a destination-host AVP. > > Now assume that server s1 sends an host type overload report requesting > a reduction of 20% using the loss algorithm. > > Also assume that the unused capacity in servers s2 through s50 is > sufficient to handle the traffic that would have been sent to s1. As > such, there is no reason to throttle any requests. > > There are no host routed requests for this application and the client > does not have a direct transport connection to server s1. The only > option a client has is to hand the request off to the agent for routing. > > The proposal in the agent cases draft is that the agent diverts 20% of > the realm routed requests that would have been sent to server s1 to > servers s2 through s50. > > If DOIC behavior is turned off in the agent then how will the traffic > routed to s1 be reduced? > > Steve > > On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote: >> +1 for the following aspect. >> >>>>> Agents must take an active role in even the most basic case for >>>>> overload handling to work, so they cannot be transparent. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not s= upport DOIC are transparent. Agents that support DOIC in most cases behave = like non supporting agents. >>> I am towards Ulrich's view here. Even for an agent that understands DOI= C it is up to the local policy whether it is transparent or takes an active= role. >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >> Sent: Monday, July 21, 2014 12:26 AM >> To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org >> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >> >> Some comments inline.. >> >> 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >>> Steve, >>> please see my response inline. >>> >>> Regards >>> Ulrich >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>> Donovan >>> Sent: Tuesday, July 15, 2014 3:53 PM >>> To: dime@ietf.org >>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>> >>> Ulrich, >>> >>> Thanks for the comments. Please see my responses inline. >>> >>> Regards, >>> >>> Steve >>> On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>> Hi Steve, >>>> here are my comments. >>>> They focus on new text you introduced. I agree that restructuring may = require new text, however, I believe that with the new text a new concepts = is introduced which macerates the agreed end-to-end concept and allows all = DOIC agents on the path to do what they wants, so that we end up in a hop-b= y-hop concept. >>> SRD> We have never had an agreement on end-to-end versus hop-by-hop >>> SRD> and >>> I believe that we will end up with a hybrid of the two. We have open >>> issues on agent behavior that Ben and I are attempting to address with >>> the agent cases draft. >>> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop approac= h of the roach draft was reason not to proceed with that draft. >>> >>> SRD> That said, this type of restructuring of the document is likely >>> SRD> to >>> put agreed to behavior in a new light. If there are cases where I >>> have implied changes to agreed to normative behavior, or if the >>> informative text is not accurate, then these things need to be correcte= d. >>>> 1. clause 2.3, second paragraph: >>>> Should read: "Reacting nodes indicate support for DOIC by including th= e OC-Supported-Features AVP into all request messages originated or relayed= by the Reacting node." >>> SRD> You mean clause 3.2. >>> [Wiehe, Ulrich (NSN - DE/Munich)] yes >>> I agree with the change. >>>> 2. clause 2.3, 3rd paragraph, 1st sentence: >>>> OC-xxx AVPs must not be included in an answer message when the corresp= onding request did not contain an OC-S-F AVP. >>> SRD> Agreed. >>>> 3. clause 3.3, 7th paragraph: >>>> Should read "The reporting node only includes an indication of support= for one overload abatement algorithm. This is the algorithm that the repo= rting node intends to use should it enter an overload condition or requests= to use while it actually is in an overload condition. Reacting nodes can u= se the indicated overload abatement algorithm to prepare for possible overl= oad reports and must use the indicated overload abatement algorithm if traf= fic reduction is actually requested." >>> SRD. OK. >>>> 4. clause 3.3, 10th paragraph: >>>> The 1st sentence is misleading. In the general case, agents on the pat= h between reacting node and reporting node are transparent. I agree that th= ere are exceptions to the general case where an agent on the path is not tr= ansparent, but then the agent IS the reporting node (reporting to the sende= r of the request) and it also IS the reacting node (reacting on reports rec= eived from the upstream reporting node). >>>> The first 3 words of the second sentence "in this case" need clarifica= tion: "In the case where an agent takes the role of a reporting node (repor= ting to the downstream reacting node) and at the same time takes the role o= f a reacting node (reacting on reports received from an upstream reporting = node)". >>>> Last sentence: Its not an update but a replacement. The two DOIC assoc= iations are handled independently. >>> SRD> I don't know what you mean when you say an agent is transparent. >>> Agents must take an active role in even the most basic case for >>> overload handling to work, so they cannot be transparent. >>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not su= pport DOIC are transparent. Agents that support DOIC in most cases behave l= ike non supporting agents. >> I am towards Ulrich's view here. Even for an agent that understands DOIC= it is up to the local policy whether it is transparent or takes an active = role. >> >>>> 5. clause 3.3, last paragraph: >>>> General rules shall be followed for each of the two associations separ= ately. The content of the OC-S-F AVP sent by the agent upstream should refl= ect what the agent is able and willing to support (as always). >>> SRD> What two associations? Is there one association (end-to-end) or >>> SRD> is >>> the an association on both sides of the agent (hop-by-hop)? Or is >>> there an association that involves three entities, the reporting node, >>> an agent reacting node for realm-routed requests and a >>> transaction-client reporting node for handling host-routed requests? >>> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, There is >>> one association between C and A, and one association between A and S. B= oth associations are "end-to-end" as there may be transparent (supporting o= r non-supporting) agents in the middle. >>>> 6. clause 3.4, 2nd paragraph: >>>> Should read: "The OC-OLR AVP is referred to as an overload report. Th= e OC-OLR AVP includes the type of report, a sequence number, the length of = time that the report is valid and abatement algorithm specific AVPs." >>> SRD> The sequence number is being used as an overload report ID. I can >>> make the change but I don't see it as necessary. >>> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. >> OK to do the change. >> >>>> 7. clause 3.4, 4th paragraph, 2nd sentence: >>>> I cannot understand this sentence. Probably only simple typos but I do= n't know. >>> SRD> Yes, a typo (this instead of the) and awkward wording. How about >>> "This applies to requests that contain the Destination-Host AVP with a >>> DiameterIdentity that matches the overload report. >>> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that conta= in a DiameterIdentity in the Destination-Host AVP that matches the reportin= g host's DiameterIdentity" >> I would be inclined to keep the text Steve proposed. But both are ok act= ually. >> >>>> 8. clause 3.4, 4th paragraph last 2 sentences: >>>> I don't understand and probably do not agree. >>> SRD> See above. >>>> 9. clause 3.5, 3rd paragraph, last word: >>>> Should read "communicated" >>> SRD> Agreed. >>>> 10. clause 3.5, 4th paragraph, 1st sentence: >>>> I don't understand. I can understand: "Reporting nodes use the OC-OLR = AVP to communicate overload occurances towards reacting nodes." >>> SRD> Who else would reports be sent to? >>> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement algori= thm but the reporting node that uses the OC-OLR AVP to communicate overload= occurances. >> Agree. >> >>>> 11. clause 4.1, 3rd paragraph, last 4 words: >>>> may be misleading. A DOIC supporting agent sitting between DOIC suppor= ting client and DOIC supporting Server is transparent with regard to DOIC. = This agent does not indicate DOIC support. >>> SRD> I disagree. >>> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Shoul= d be: ...This agent does not indicate its DOIC support, rather it transpare= ntly forwards the client's DOIC support. >> Agree with Ulrich on the intent of agent behavior but not with the propo= sed text change. >> >>>> 12. clause 4.1, 4th paragraph, 2nd sentence: >>>> Should read:"If a request message handled by the DOIC agent does not i= nclude the OC-Supported-Features AVP then the DOIC agent inserts the AVP." >>> SRD> That is what it already says. >>> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... >> OC-Supported-Features can be in both request and answer, thus "If a mess= age" in that sense is correct. >> >>>> 13. clause 4.1, last sentence: >>>> Should read "If the message already has the AVP then the agent either = leaves it unchanged in the relayed message or replaces it to reflect the fe= atures the agent is able and willing to support." Clarification is needed t= o say that strict rules must be followed by the agent to select the correct= option. These rules take into account whether the request is host-routed o= r relam-routed and whether the agent is configured to select the server for= realm-routed requests. >>> SRD> This is a topic on agent behavior that is addressed in the agent >>> cases draft. I'll leave the discussion for what the wording should be >>> to the discussion on that draft. >>>> 14. clause 4.1.2, 2nd paragraph: >>>> Should read: "Based on the content of the OC-Supported-Features AVP in= the request message, the reporting node knows what overload control functi= onality is supported by the reacting node. The reporting node then acts ac= cordingly for the subsequent answer messages it initiates for the transacti= on." >>> SRD> It would be easier if you didn't make it difficult to understand >>> the change you are proposing. I think you are proposing changing >>> node(s) to node. I don't agree but that will be addressed as part of >>> the agent cases discussion. >>> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing two = sentences? The proposal is to insert "is" between "functionality" and "supp= orted", to add "the" between "by" and "reacting", to replace "node(s)" with= "node", and to insert "for the transaction" after "initiates". >> Agree with the proposed change. >> >>>> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >>>> Should read: "message's" >>> SRD> I'm assuming you mean section 4.1.2. >>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, an= d 19. >>> I agree to the change. >>>> 16. clause 4.1, 6th paragraph: >>>> This should be left to the (future) specification that introduces othe= r DOIC features. >>>> >>>> 17. clause 4.1, 7th paragraph, last 6 words: >>>> should be based on requiements set by the (future) specification that >>>> introduces other DOIC features >>> SRD> Again, clause 4.1.2 -- I don't understand the issue when these >>> SRD> two >>> paragraphs are taken together. >>>> 18. clause 4.1, 8th paragraph, last sentence: >>>> Should read: "Lack of the OC-Supported-Features AVP in the request mes= sage indicates that there is no downstream reacting node for the transactio= n." >>> SRD> I think you mean clause 4.1.2. I don't see the need for the chang= e. >>> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not corr= ect. It should either read: "Lack of the OC-Supported-Feature AVP in the re= quest message indicates to the reporting node that there is no reacting nod= e for the transaction" or as proposed above. >> I don't see a reason for the change. Original text seem correct to me. >> >>>> 19. clause 4.1, last sentence: >>>> Should read: "An agent MAY replace the OC-Supported-Features AVP carri= ed in answer messages." This replacement must follow general rules. Its not= so that the agent may do what ever it wants to. The decision must be based= on whether or not the agent has replaced the OC-S-F in the corresponding r= equest. >>> SRD> What is the difference between modify and replace? I am ok with >>> removing this statement until we have the agent behavior discussion. >>> I thought I had taken the agent specific statements out of this version= . >>> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with identica= l values. You remove what has been received in and insert your own stuff. >> Agent (proxy) can always do that i.e. modify the APV contents. Obviously= if an agent tampers the OC-Supported-Features AVP it needs to know what it= is doing. In general agree with the clarification but not with the propose= d text. >> >> - Jouni >> >>>> 20. clause 5.2, 1st sentence: >>>> Should read: "A reporting node using the loss algorithm must use the O= C-Reduction-Percentage AVP (Section 6.7) to indicated the desired percentag= e of traffic reduction." >>> SRD> Agreed. >>>> 21. clause 5.2, last sentence: >>>> Should read: "Editor's note: The above duplicates what is in the OC-Re= duction-Percentage AVP section and can probably be removed." >>> SRD> Yes, bad wording. The note will be removed, bad wording and all, >>> once there is a discussion on if this is redundant. >>>> 22. clause 5.4, 6th paragraph: >>>> Should read: "If the reacting node does not receive a an OLR in the an= swer that corresponds to the probe request messages sent to the formally ov= erloaded node then the reacting node should slowly increase the rate of tra= ffic sent to the overloaded node." >>> SRD Agreed, this is more clear. >>>> Best regards >>>> Ulrich >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>> Donovan >>>> Sent: Saturday, July 05, 2014 9:42 PM >>>> To: dime@ietf.org >>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>> >>>> All, >>>> >>>> This version of the DOIC draft is a restructuring of previously >>>> agreed to content. >>>> >>>> The master plan for the restructuring is in Appendix C. This >>>> outlines where material from -02 was moved in -03. >>>> >>>> For those interested, the work was done in steps, with a snapshot for >>>> each step available here: >>>> >>>> https://github.com/jounikor/draft-docdt-dime-ovli >>>> >>>> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >>>> >>>> where nn indicates the subversion and "text" indicates the focus for >>>> that subversion. >>>> >>>> The next step will be to resolve open issues already identified and >>>> those yet those yet to be identified. >>>> >>>> Regards, >>>> >>>> Steve >>>> >>>> >>>> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>>>> A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. >>>>> This draft is a work item of the Diameter Maintenance and Exten= sions Working Group of the IETF. >>>>> >>>>> Title : Diameter Overload Indication Conveyanc= e >>>>> Authors : Jouni Korhonen >>>>> Steve Donovan >>>>> Ben Campbell >>>>> Lionel Morand >>>>> Filename : draft-ietf-dime-ovli-03.txt >>>>> Pages : 48 >>>>> Date : 2014-07-03 >>>>> >>>>> Abstract: >>>>> This specification documents a Diameter Overload Control (DOC= ) base >>>>> solution and the dissemination of the overload report informa= tion. >>>>> >>>>> Requirements >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>>>> >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-ovli-03 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission until the htmlized version and diff are available at tools= .ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Tue Jul 29 06:29:30 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DFF21A02DC for ; Tue, 29 Jul 2014 06:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 bMvuSK3tjrdE for ; Tue, 29 Jul 2014 06:29:25 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 164EE1B2873 for ; Tue, 29 Jul 2014 06:29:25 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0195.001; Tue, 29 Jul 2014 09:29:24 -0400 From: Dave Dolson To: Jouni Korhonen , "dime@ietf.org" Thread-Topic: [Dime] meeting minutes uploada Thread-Index: AQHPql8P1AoWBbdpA0eRQspB9QqiG5u3CP7g Date: Tue, 29 Jul 2014 13:29:24 +0000 Message-ID: References: <53D640F6.5080502@gmail.com> In-Reply-To: <53D640F6.5080502@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.111] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/mncgl7UbEjkOznwuvA7zNuRCeoo Subject: Re: [Dime] meeting minutes uploada X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 13:29:27 -0000 I'm the "Dave" (Dolson, Dawson, etc.) in the minutes. My understanding in the meeting discussion about DOIC was that the DOIC AVP= s will have to be added to application protocols.=20 In other words, NOT added to the base protocol, and no existing Diameter ag= ents or end-points will be expected to understand it. My reasoning was that abatement is always application-specific, requiring k= nowledge of message semantics. But from the minutes, that conclusion isn't clear. I may have heard what I = wanted to hear rather than what was actually said... So, is the intent to define a new mechanism that may be used with new proto= cols and protocol updates, or is the intent to put DOIC in the base such th= at all protocols automatically inherit it? > Dave - You will get the doc through quicker if you don't explain the > approaches when you get the AVP. 4006 type applications - sessi= on-based > applications. Here's one for stateless. My point here is, just define the AVP and indicate how it should be used, i= n the sense of providing design patterns (for stateless, online charging, o= ffline charging, etc). Then we don't have to debate the corner-cases of the= abatement algorithms of all applications; we just need to agree on the wir= e format. Then applications can start to reference it, one by one. David Dolson Senior Software Architect, Sandvine Inc. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Monday, July 28, 2014 8:24 AM To: dime@ietf.org Subject: [Dime] meeting minutes uploada Thanks to Jean for extensive minutes & notes: http://tools.ietf.org/wg/dime/minutes?item=3Dminutes-90-dime.html - Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Tue Jul 29 07:05:52 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE9E1A01C6 for ; Tue, 29 Jul 2014 07:05:50 -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, SPF_NEUTRAL=0.779] autolearn=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 rZm1DLp8pZLS for ; Tue, 29 Jul 2014 07:05:46 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 86ECF1B2889 for ; Tue, 29 Jul 2014 07:05:46 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62419 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XC824-0002pX-Fz; Tue, 29 Jul 2014 07:05:44 -0700 Message-ID: <53D7AA31.3070908@usdonovans.com> Date: Tue, 29 Jul 2014 09:05:37 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/jNzHDVOQO2U1boGVDIvXqzNs3Bo Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 14:05:51 -0000 Ulrich, Thanks for the detailed response. I think we are very close to being in agreement. The area I'm not sure about yet is using the wording "A DOIC node that does server selection" versus "A DOIC node with a direct transport connection". A client might think it is doing server selection even when it is connecting to an agent. That is why I used the "direct transport connection" wording to make it more explicit. What is the objection to this wording? This could also be solved by adding a definition of server selection, but it would need to be done in a way that also addresses transactions that flow from a Diameter server to a Diameter client. Regards. Steve On 7/29/14, 2:29 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > I can agree with most of your statements. > > A DOICable agent needs to determine in which scenario it actually is. This decision must be based on presence/absence of OC-S-F-AVP in the received requests, presence/absence of Destination-Host AVP in the received request and configuration data (configured to select/not to select the server for realm routed requests). > > Once this decision is taken the agent > a) inserts an OC-S-F to the request, or > b) transparently forwards the request (i.e. does not remove or add an OC-S-F AVP), or > c) removes the received OC-S-F AVP and inserts its own OC-S-F AVP > > note that c) includes the case where the removed AVP and the inserted AVP are identical. > > Case b) is the transparent case where the agent - although it supports DOIC (and DOIC is not turned off) - from an external point of view behaves like a non-DOICable node. > > See also inline. > > Regards, > Ulrich > (still trying to catch up with lots of mails) > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan > Sent: Monday, July 21, 2014 4:29 PM > To: dime@ietf.org > Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) > > Ulrich, > > I am not arguing that all agents should take an active role in the > handling of all overload reports. What I am arguing is that there are > scenarios where an agent must take an active role in DOIC to ensure that > a requested reduction in traffic an be achieved. > > For DOIC to work a carrier cannot turn off all DOIC behavior in agents, > as suggested by Jouni. > > I agree that in your scenario below, a1 does not need to take an active > role in reducing traffic when c supports DOIC. a1 should take an active > role when c does not support DOIC. The problem is that a1 does not know > in advance whether c supports DOIC so it will need to inspect all > transactions for the presence of OC-S-F to determine if it needs to > handle overload reports for a non supporting client. > I agree > > Does that mean a1 is transparent if it inspects all requests and does > nothing in the case where there is c supports DOIC? > yes > > Does transparent mean that there is no observable difference in the DOIC > AVPs that pass through the agent > yes or does it mean that there is no > observable difference in how transactions are handled by the DOIC agent? > no > > I'm guessing that we have multiple assumptions on what transparent means > and, if we are going to continue saying agents should be transparent > then we need a definition of transparent. > > I think for this use case, we need the following normative statements in > the draft for handling of abatement of realm-routed requests? I think > this is general behavior and should go in the section on handling of > overload reports. > > "DOIC nodes with a direct transport connection to a reporting node that > has an active overload report must handle abatement of realm-routed > requests. The preferred method for handling abatement of realm-routed > requests is diversion, where the node with the direct transport > connection routes the request to an alternative server that is able to > handle the request. If there is no alternative server with the needed > capacity to handle the request then the DOIC node must/should throttle > the necessary requests to meet the requested reduction in traffic." > My proposal: > "A DOIC node with performs server selection for realm routed requests that > has active overload reports from servers it potentially selects, must > handle abatement of realm-routed > requests. The preferred method for handling abatement of realm-routed > requests is diversion, where the node selecting the server routes the > request to an alternative server that is able to > handle the request. If there is no alternative server with the needed > capacity to handle the request then the DOIC node must/should preferrably > delegate abatement (of realm routed requests) towards a downstream reacting > node or otherwise throttle > the necessary requests to meet the requested reduction in traffic." > > > > If we can agree on this then we can move on to the next agent based use > case. > > Regards, > > Steve > > On 7/21/14, 9:47 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Steve, >> >> The example you show is absolutely valid and 100% inline with A) to F) - (assuming that all servers can serve any request). >> However, there are other scenarios like: >> >> >> >> +--+ >> /--|s1| >> +-+ +--+ +--+ / +--+ >> |c|--- |a1|--|a2|== ... >> +-+ +--+ +--+ \ +--+ >> \--|sn| >> +--+ >> >> Here I think a1 should be transparent even when DOICable. >> a1 does not take the role of a reacting node since c supports DOIC. >> a1 does not perform server selection and therefore does not take the role of a reporting node (for realm-reports). >> >> Ulrich >> >> >> -----Original Message----- >> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Monday, July 21, 2014 3:16 PM >> To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org >> Subject: Transparent agents (was Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt) >> >> Ok, let's see if it's possible to completely turn off all DOIC behavior >> in agents and still be able to reduce traffic to a server that sends a >> host overload report. >> >> Assume the following agent based deployment: >> >> +--+ >> /--|s1| >> +-+ +-+ / +--+ >> |c|--|a|== ... >> +-+ +-+ \ +--+ >> \--|sn| >> +--+ >> >> Assume that there is a large number of servers, say 50. >> >> Now, assume that the Diameter application in question exclusively uses >> realm-routed requests - 100% of requests sent by the client do NOT have >> a destination-host AVP. >> >> Now assume that server s1 sends an host type overload report requesting >> a reduction of 20% using the loss algorithm. >> >> Also assume that the unused capacity in servers s2 through s50 is >> sufficient to handle the traffic that would have been sent to s1. As >> such, there is no reason to throttle any requests. >> >> There are no host routed requests for this application and the client >> does not have a direct transport connection to server s1. The only >> option a client has is to hand the request off to the agent for routing. >> >> The proposal in the agent cases draft is that the agent diverts 20% of >> the realm routed requests that would have been sent to server s1 to >> servers s2 through s50. >> >> If DOIC behavior is turned off in the agent then how will the traffic >> routed to s1 be reduced? >> >> Steve >> >> On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote: >>> +1 for the following aspect. >>> >>>>>> Agents must take an active role in even the most basic case for >>>>>> overload handling to work, so they cannot be transparent. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not support DOIC are transparent. Agents that support DOIC in most cases behave like non supporting agents. >>>> I am towards Ulrich's view here. Even for an agent that understands DOIC it is up to the local policy whether it is transparent or takes an active role. >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >>> Sent: Monday, July 21, 2014 12:26 AM >>> To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org >>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>> >>> Some comments inline.. >>> >>> 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >>>> Steve, >>>> please see my response inline. >>>> >>>> Regards >>>> Ulrich >>>> >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>> Donovan >>>> Sent: Tuesday, July 15, 2014 3:53 PM >>>> To: dime@ietf.org >>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>> >>>> Ulrich, >>>> >>>> Thanks for the comments. Please see my responses inline. >>>> >>>> Regards, >>>> >>>> Steve >>>> On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>>> Hi Steve, >>>>> here are my comments. >>>>> They focus on new text you introduced. I agree that restructuring may require new text, however, I believe that with the new text a new concepts is introduced which macerates the agreed end-to-end concept and allows all DOIC agents on the path to do what they wants, so that we end up in a hop-by-hop concept. >>>> SRD> We have never had an agreement on end-to-end versus hop-by-hop >>>> SRD> and >>>> I believe that we will end up with a hybrid of the two. We have open >>>> issues on agent behavior that Ben and I are attempting to address with >>>> the agent cases draft. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop approach of the roach draft was reason not to proceed with that draft. >>>> >>>> SRD> That said, this type of restructuring of the document is likely >>>> SRD> to >>>> put agreed to behavior in a new light. If there are cases where I >>>> have implied changes to agreed to normative behavior, or if the >>>> informative text is not accurate, then these things need to be corrected. >>>>> 1. clause 2.3, second paragraph: >>>>> Should read: "Reacting nodes indicate support for DOIC by including the OC-Supported-Features AVP into all request messages originated or relayed by the Reacting node." >>>> SRD> You mean clause 3.2. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes >>>> I agree with the change. >>>>> 2. clause 2.3, 3rd paragraph, 1st sentence: >>>>> OC-xxx AVPs must not be included in an answer message when the corresponding request did not contain an OC-S-F AVP. >>>> SRD> Agreed. >>>>> 3. clause 3.3, 7th paragraph: >>>>> Should read "The reporting node only includes an indication of support for one overload abatement algorithm. This is the algorithm that the reporting node intends to use should it enter an overload condition or requests to use while it actually is in an overload condition. Reacting nodes can use the indicated overload abatement algorithm to prepare for possible overload reports and must use the indicated overload abatement algorithm if traffic reduction is actually requested." >>>> SRD. OK. >>>>> 4. clause 3.3, 10th paragraph: >>>>> The 1st sentence is misleading. In the general case, agents on the path between reacting node and reporting node are transparent. I agree that there are exceptions to the general case where an agent on the path is not transparent, but then the agent IS the reporting node (reporting to the sender of the request) and it also IS the reacting node (reacting on reports received from the upstream reporting node). >>>>> The first 3 words of the second sentence "in this case" need clarification: "In the case where an agent takes the role of a reporting node (reporting to the downstream reacting node) and at the same time takes the role of a reacting node (reacting on reports received from an upstream reporting node)". >>>>> Last sentence: Its not an update but a replacement. The two DOIC associations are handled independently. >>>> SRD> I don't know what you mean when you say an agent is transparent. >>>> Agents must take an active role in even the most basic case for >>>> overload handling to work, so they cannot be transparent. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not support DOIC are transparent. Agents that support DOIC in most cases behave like non supporting agents. >>> I am towards Ulrich's view here. Even for an agent that understands DOIC it is up to the local policy whether it is transparent or takes an active role. >>> >>>>> 5. clause 3.3, last paragraph: >>>>> General rules shall be followed for each of the two associations separately. The content of the OC-S-F AVP sent by the agent upstream should reflect what the agent is able and willing to support (as always). >>>> SRD> What two associations? Is there one association (end-to-end) or >>>> SRD> is >>>> the an association on both sides of the agent (hop-by-hop)? Or is >>>> there an association that involves three entities, the reporting node, >>>> an agent reacting node for realm-routed requests and a >>>> transaction-client reporting node for handling host-routed requests? >>>> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, There is >>>> one association between C and A, and one association between A and S. Both associations are "end-to-end" as there may be transparent (supporting or non-supporting) agents in the middle. >>>>> 6. clause 3.4, 2nd paragraph: >>>>> Should read: "The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP includes the type of report, a sequence number, the length of time that the report is valid and abatement algorithm specific AVPs." >>>> SRD> The sequence number is being used as an overload report ID. I can >>>> make the change but I don't see it as necessary. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. >>> OK to do the change. >>> >>>>> 7. clause 3.4, 4th paragraph, 2nd sentence: >>>>> I cannot understand this sentence. Probably only simple typos but I don't know. >>>> SRD> Yes, a typo (this instead of the) and awkward wording. How about >>>> "This applies to requests that contain the Destination-Host AVP with a >>>> DiameterIdentity that matches the overload report. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that contain a DiameterIdentity in the Destination-Host AVP that matches the reporting host's DiameterIdentity" >>> I would be inclined to keep the text Steve proposed. But both are ok actually. >>> >>>>> 8. clause 3.4, 4th paragraph last 2 sentences: >>>>> I don't understand and probably do not agree. >>>> SRD> See above. >>>>> 9. clause 3.5, 3rd paragraph, last word: >>>>> Should read "communicated" >>>> SRD> Agreed. >>>>> 10. clause 3.5, 4th paragraph, 1st sentence: >>>>> I don't understand. I can understand: "Reporting nodes use the OC-OLR AVP to communicate overload occurances towards reacting nodes." >>>> SRD> Who else would reports be sent to? >>>> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement algorithm but the reporting node that uses the OC-OLR AVP to communicate overload occurances. >>> Agree. >>> >>>>> 11. clause 4.1, 3rd paragraph, last 4 words: >>>>> may be misleading. A DOIC supporting agent sitting between DOIC supporting client and DOIC supporting Server is transparent with regard to DOIC. This agent does not indicate DOIC support. >>>> SRD> I disagree. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Should be: ...This agent does not indicate its DOIC support, rather it transparently forwards the client's DOIC support. >>> Agree with Ulrich on the intent of agent behavior but not with the proposed text change. >>> >>>>> 12. clause 4.1, 4th paragraph, 2nd sentence: >>>>> Should read:"If a request message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent inserts the AVP." >>>> SRD> That is what it already says. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... >>> OC-Supported-Features can be in both request and answer, thus "If a message" in that sense is correct. >>> >>>>> 13. clause 4.1, last sentence: >>>>> Should read "If the message already has the AVP then the agent either leaves it unchanged in the relayed message or replaces it to reflect the features the agent is able and willing to support." Clarification is needed to say that strict rules must be followed by the agent to select the correct option. These rules take into account whether the request is host-routed or relam-routed and whether the agent is configured to select the server for realm-routed requests. >>>> SRD> This is a topic on agent behavior that is addressed in the agent >>>> cases draft. I'll leave the discussion for what the wording should be >>>> to the discussion on that draft. >>>>> 14. clause 4.1.2, 2nd paragraph: >>>>> Should read: "Based on the content of the OC-Supported-Features AVP in the request message, the reporting node knows what overload control functionality is supported by the reacting node. The reporting node then acts accordingly for the subsequent answer messages it initiates for the transaction." >>>> SRD> It would be easier if you didn't make it difficult to understand >>>> the change you are proposing. I think you are proposing changing >>>> node(s) to node. I don't agree but that will be addressed as part of >>>> the agent cases discussion. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing two sentences? The proposal is to insert "is" between "functionality" and "supported", to add "the" between "by" and "reacting", to replace "node(s)" with "node", and to insert "for the transaction" after "initiates". >>> Agree with the proposed change. >>> >>>>> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >>>>> Should read: "message's" >>>> SRD> I'm assuming you mean section 4.1.2. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, and 19. >>>> I agree to the change. >>>>> 16. clause 4.1, 6th paragraph: >>>>> This should be left to the (future) specification that introduces other DOIC features. >>>>> >>>>> 17. clause 4.1, 7th paragraph, last 6 words: >>>>> should be based on requiements set by the (future) specification that >>>>> introduces other DOIC features >>>> SRD> Again, clause 4.1.2 -- I don't understand the issue when these >>>> SRD> two >>>> paragraphs are taken together. >>>>> 18. clause 4.1, 8th paragraph, last sentence: >>>>> Should read: "Lack of the OC-Supported-Features AVP in the request message indicates that there is no downstream reacting node for the transaction." >>>> SRD> I think you mean clause 4.1.2. I don't see the need for the change. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not correct. It should either read: "Lack of the OC-Supported-Feature AVP in the request message indicates to the reporting node that there is no reacting node for the transaction" or as proposed above. >>> I don't see a reason for the change. Original text seem correct to me. >>> >>>>> 19. clause 4.1, last sentence: >>>>> Should read: "An agent MAY replace the OC-Supported-Features AVP carried in answer messages." This replacement must follow general rules. Its not so that the agent may do what ever it wants to. The decision must be based on whether or not the agent has replaced the OC-S-F in the corresponding request. >>>> SRD> What is the difference between modify and replace? I am ok with >>>> removing this statement until we have the agent behavior discussion. >>>> I thought I had taken the agent specific statements out of this version. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with identical values. You remove what has been received in and insert your own stuff. >>> Agent (proxy) can always do that i.e. modify the APV contents. Obviously if an agent tampers the OC-Supported-Features AVP it needs to know what it is doing. In general agree with the clarification but not with the proposed text. >>> >>> - Jouni >>> >>>>> 20. clause 5.2, 1st sentence: >>>>> Should read: "A reporting node using the loss algorithm must use the OC-Reduction-Percentage AVP (Section 6.7) to indicated the desired percentage of traffic reduction." >>>> SRD> Agreed. >>>>> 21. clause 5.2, last sentence: >>>>> Should read: "Editor's note: The above duplicates what is in the OC-Reduction-Percentage AVP section and can probably be removed." >>>> SRD> Yes, bad wording. The note will be removed, bad wording and all, >>>> once there is a discussion on if this is redundant. >>>>> 22. clause 5.4, 6th paragraph: >>>>> Should read: "If the reacting node does not receive a an OLR in the answer that corresponds to the probe request messages sent to the formally overloaded node then the reacting node should slowly increase the rate of traffic sent to the overloaded node." >>>> SRD Agreed, this is more clear. >>>>> Best regards >>>>> Ulrich >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>> Donovan >>>>> Sent: Saturday, July 05, 2014 9:42 PM >>>>> To: dime@ietf.org >>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>> >>>>> All, >>>>> >>>>> This version of the DOIC draft is a restructuring of previously >>>>> agreed to content. >>>>> >>>>> The master plan for the restructuring is in Appendix C. This >>>>> outlines where material from -02 was moved in -03. >>>>> >>>>> For those interested, the work was done in steps, with a snapshot for >>>>> each step available here: >>>>> >>>>> https://github.com/jounikor/draft-docdt-dime-ovli >>>>> >>>>> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >>>>> >>>>> where nn indicates the subversion and "text" indicates the focus for >>>>> that subversion. >>>>> >>>>> The next step will be to resolve open issues already identified and >>>>> those yet those yet to be identified. >>>>> >>>>> Regards, >>>>> >>>>> Steve >>>>> >>>>> >>>>> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>>> This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. >>>>>> >>>>>> Title : Diameter Overload Indication Conveyance >>>>>> Authors : Jouni Korhonen >>>>>> Steve Donovan >>>>>> Ben Campbell >>>>>> Lionel Morand >>>>>> Filename : draft-ietf-dime-ovli-03.txt >>>>>> Pages : 48 >>>>>> Date : 2014-07-03 >>>>>> >>>>>> Abstract: >>>>>> This specification documents a Diameter Overload Control (DOC) base >>>>>> solution and the dissemination of the overload report information. >>>>>> >>>>>> Requirements >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-03 >>>>>> >>>>>> >>>>>> Please note that it may take a couple of minutes from the time of >>>>>> submission until the htmlized version and diff are available at tools.ietf.org. >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Tue Jul 29 08:43:40 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00AD1B29A8 for ; Tue, 29 Jul 2014 08:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 DE0Vwlw3gpMx for ; Tue, 29 Jul 2014 08:43:31 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2F51B29BF for ; Tue, 29 Jul 2014 08:41:23 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s6TFfLMO004253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 29 Jul 2014 15:41:21 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s6TFfKLt008083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jul 2014 17:41:21 +0200 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 29 Jul 2014 17:41:20 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0195.001; Tue, 29 Jul 2014 17:41:20 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) Thread-Index: AQHPpPA/36IwRToz/kGtAPmPhYVJupuqvVowgAxDloCAACTwUA== Date: Tue, 29 Jul 2014 15:41:19 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681520806A@DEMUMBX014.nsn-intra.net> References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> <53D7AA31.3070908@usdonovans.com> In-Reply-To: <53D7AA31.3070908@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.109] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 27115 X-purgate-ID: 151667::1406648481-00007A71-7D0D8AD2/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/sm5vIoXqPSSggm1T2xSkJCYeTU8 Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 15:43:37 -0000 Steve, It is my understanding that the node (client or agent) which performs serve= r selection (e.g. selects server S) needs to make sure that any upstream ag= ent will not undo the selection (e.g. by selecting another server Z). This = can be ensured by inserting a Destination-Host AVP containing S's DiameterI= dentity to the request. Inserting the Destinatio-Host AVP is not needed whe= n there are no upstream agents i.e. when there is a "direct transport conne= ction" to the selected server. The case where the node that selects the ser= ver for a realm-routed request has a direct transport connection to the sel= ected server is not the general case. =20 A DOICable node (client or agent) may face the situation where it has to se= nd out a realm-routed request. Before sending the request it may detect tha= t it (the node) is configured to perform server selection. The node selects= server S. Now (still before sending the request out) the node detects (fro= m checking overload states) that S is overloaded therefore it performs abat= ement (diversion to Z). Now the node may either have a direct transport con= nection to Z in which case it sends the request to Z (this is the case you = covered), or it does not have a direct transport connetion to Z in which ca= se it inserts the Destination-Host AVP with Z's Diameter Identity and sends= the request to the next hop. Ulrich -----Original Message----- From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Tuesday, July 29, 2014 4:06 PM To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime= -ovli-03.txt) Ulrich, Thanks for the detailed response. I think we are very close to being in=20 agreement. The area I'm not sure about yet is using the wording "A DOIC node that=20 does server selection" versus "A DOIC node with a direct transport=20 connection". A client might think it is doing server selection even when it is=20 connecting to an agent. That is why I used the "direct transport=20 connection" wording to make it more explicit. What is the objection to this wording? This could also be solved by adding a definition of server selection,=20 but it would need to be done in a way that also addresses transactions=20 that flow from a Diameter server to a Diameter client. Regards. Steve On 7/29/14, 2:29 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > I can agree with most of your statements. > > A DOICable agent needs to determine in which scenario it actually is. Thi= s decision must be based on presence/absence of OC-S-F-AVP in the received = requests, presence/absence of Destination-Host AVP in the received request = and configuration data (configured to select/not to select the server for r= ealm routed requests). > > Once this decision is taken the agent > a) inserts an OC-S-F to the request, or > b) transparently forwards the request (i.e. does not remove or add an OC-= S-F AVP), or > c) removes the received OC-S-F AVP and inserts its own OC-S-F AVP > > note that c) includes the case where the removed AVP and the inserted AVP= are identical. > > Case b) is the transparent case where the agent - although it supports DO= IC (and DOIC is not turned off) - from an external point of view behaves li= ke a non-DOICable node. > > See also inline. > > Regards, > Ulrich > (still trying to catch up with lots of mails) > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan > Sent: Monday, July 21, 2014 4:29 PM > To: dime@ietf.org > Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-di= me-ovli-03.txt) > > Ulrich, > > I am not arguing that all agents should take an active role in the > handling of all overload reports. What I am arguing is that there are > scenarios where an agent must take an active role in DOIC to ensure that > a requested reduction in traffic an be achieved. > > For DOIC to work a carrier cannot turn off all DOIC behavior in agents, > as suggested by Jouni. > > I agree that in your scenario below, a1 does not need to take an active > role in reducing traffic when c supports DOIC. a1 should take an active > role when c does not support DOIC. The problem is that a1 does not know > in advance whether c supports DOIC so it will need to inspect all > transactions for the presence of OC-S-F to determine if it needs to > handle overload reports for a non supporting client. > I agree > > Does that mean a1 is transparent if it inspects all requests and does > nothing in the case where there is c supports DOIC? > yes > > Does transparent mean that there is no observable difference in the DOIC > AVPs that pass through the agent > yes or does it mean that there is no > observable difference in how transactions are handled by the DOIC agent? > no > > I'm guessing that we have multiple assumptions on what transparent means > and, if we are going to continue saying agents should be transparent > then we need a definition of transparent. > > I think for this use case, we need the following normative statements in > the draft for handling of abatement of realm-routed requests? I think > this is general behavior and should go in the section on handling of > overload reports. > > "DOIC nodes with a direct transport connection to a reporting node that > has an active overload report must handle abatement of realm-routed > requests. The preferred method for handling abatement of realm-routed > requests is diversion, where the node with the direct transport > connection routes the request to an alternative server that is able to > handle the request. If there is no alternative server with the needed > capacity to handle the request then the DOIC node must/should throttle > the necessary requests to meet the requested reduction in traffic." > My proposal: > "A DOIC node with performs server selection for realm routed requests tha= t > has active overload reports from servers it potentially selects, must > handle abatement of realm-routed > requests. The preferred method for handling abatement of realm-routed > requests is diversion, where the node selecting the server routes the > request to an alternative server that is able to > handle the request. If there is no alternative server with the needed > capacity to handle the request then the DOIC node must/should preferrably > delegate abatement (of realm routed requests) towards a downstream reacti= ng > node or otherwise throttle > the necessary requests to meet the requested reduction in traffic." > > > > If we can agree on this then we can move on to the next agent based use > case. > > Regards, > > Steve > > On 7/21/14, 9:47 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Steve, >> >> The example you show is absolutely valid and 100% inline with A) to F) -= (assuming that all servers can serve any request). >> However, there are other scenarios like: >> >> >> =20 >> +--+ >> /--|s1| >> +-+ +--+ +--+ / +--+ >> |c|--- |a1|--|a2|=3D=3D ... >> +-+ +--+ +--+ \ +--+ >> \--|sn| >> +--+ >> >> Here I think a1 should be transparent even when DOICable. >> a1 does not take the role of a reacting node since c supports DOIC. >> a1 does not perform server selection and therefore does not take the rol= e of a reporting node (for realm-reports). >> >> Ulrich >> >> >> -----Original Message----- >> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Monday, July 21, 2014 3:16 PM >> To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich= ); dime@ietf.org >> Subject: Transparent agents (was Re: [Dime] I-D Action: draft-ietf-dime-= ovli-03.txt) >> >> Ok, let's see if it's possible to completely turn off all DOIC behavior >> in agents and still be able to reduce traffic to a server that sends a >> host overload report. >> >> Assume the following agent based deployment: >> >> +--+ >> /--|s1| >> +-+ +-+ / +--+ >> |c|--|a|=3D=3D ... >> +-+ +-+ \ +--+ >> \--|sn| >> +--+ >> >> Assume that there is a large number of servers, say 50. >> >> Now, assume that the Diameter application in question exclusively uses >> realm-routed requests - 100% of requests sent by the client do NOT have >> a destination-host AVP. >> >> Now assume that server s1 sends an host type overload report requesting >> a reduction of 20% using the loss algorithm. >> >> Also assume that the unused capacity in servers s2 through s50 is >> sufficient to handle the traffic that would have been sent to s1. As >> such, there is no reason to throttle any requests. >> >> There are no host routed requests for this application and the client >> does not have a direct transport connection to server s1. The only >> option a client has is to hand the request off to the agent for routing. >> >> The proposal in the agent cases draft is that the agent diverts 20% of >> the realm routed requests that would have been sent to server s1 to >> servers s2 through s50. >> >> If DOIC behavior is turned off in the agent then how will the traffic >> routed to s1 be reduced? >> >> Steve >> >> On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote: >>> +1 for the following aspect. >>> >>>>>> Agents must take an active role in even the most basic case for >>>>>> overload handling to work, so they cannot be transparent. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not = support DOIC are transparent. Agents that support DOIC in most cases behave= like non supporting agents. >>>> I am towards Ulrich's view here. Even for an agent that understands DO= IC it is up to the local policy whether it is transparent or takes an activ= e role. >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >>> Sent: Monday, July 21, 2014 12:26 AM >>> To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org >>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>> >>> Some comments inline.. >>> >>> 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >>>> Steve, >>>> please see my response inline. >>>> >>>> Regards >>>> Ulrich >>>> >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>> Donovan >>>> Sent: Tuesday, July 15, 2014 3:53 PM >>>> To: dime@ietf.org >>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>> >>>> Ulrich, >>>> >>>> Thanks for the comments. Please see my responses inline. >>>> >>>> Regards, >>>> >>>> Steve >>>> On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>>> Hi Steve, >>>>> here are my comments. >>>>> They focus on new text you introduced. I agree that restructuring may= require new text, however, I believe that with the new text a new concepts= is introduced which macerates the agreed end-to-end concept and allows all= DOIC agents on the path to do what they wants, so that we end up in a hop-= by-hop concept. >>>> SRD> We have never had an agreement on end-to-end versus hop-by-hop >>>> SRD> and >>>> I believe that we will end up with a hybrid of the two. We have open >>>> issues on agent behavior that Ben and I are attempting to address with >>>> the agent cases draft. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop approa= ch of the roach draft was reason not to proceed with that draft. >>>> >>>> SRD> That said, this type of restructuring of the document is likely >>>> SRD> to >>>> put agreed to behavior in a new light. If there are cases where I >>>> have implied changes to agreed to normative behavior, or if the >>>> informative text is not accurate, then these things need to be correct= ed. >>>>> 1. clause 2.3, second paragraph: >>>>> Should read: "Reacting nodes indicate support for DOIC by including t= he OC-Supported-Features AVP into all request messages originated or relaye= d by the Reacting node." >>>> SRD> You mean clause 3.2. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes >>>> I agree with the change. >>>>> 2. clause 2.3, 3rd paragraph, 1st sentence: >>>>> OC-xxx AVPs must not be included in an answer message when the corres= ponding request did not contain an OC-S-F AVP. >>>> SRD> Agreed. >>>>> 3. clause 3.3, 7th paragraph: >>>>> Should read "The reporting node only includes an indication of suppor= t for one overload abatement algorithm. This is the algorithm that the rep= orting node intends to use should it enter an overload condition or request= s to use while it actually is in an overload condition. Reacting nodes can = use the indicated overload abatement algorithm to prepare for possible over= load reports and must use the indicated overload abatement algorithm if tra= ffic reduction is actually requested." >>>> SRD. OK. >>>>> 4. clause 3.3, 10th paragraph: >>>>> The 1st sentence is misleading. In the general case, agents on the pa= th between reacting node and reporting node are transparent. I agree that t= here are exceptions to the general case where an agent on the path is not t= ransparent, but then the agent IS the reporting node (reporting to the send= er of the request) and it also IS the reacting node (reacting on reports re= ceived from the upstream reporting node). >>>>> The first 3 words of the second sentence "in this case" need clarific= ation: "In the case where an agent takes the role of a reporting node (repo= rting to the downstream reacting node) and at the same time takes the role = of a reacting node (reacting on reports received from an upstream reporting= node)". >>>>> Last sentence: Its not an update but a replacement. The two DOIC asso= ciations are handled independently. >>>> SRD> I don't know what you mean when you say an agent is transparent. >>>> Agents must take an active role in even the most basic case for >>>> overload handling to work, so they cannot be transparent. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not s= upport DOIC are transparent. Agents that support DOIC in most cases behave = like non supporting agents. >>> I am towards Ulrich's view here. Even for an agent that understands DOI= C it is up to the local policy whether it is transparent or takes an active= role. >>> >>>>> 5. clause 3.3, last paragraph: >>>>> General rules shall be followed for each of the two associations sepa= rately. The content of the OC-S-F AVP sent by the agent upstream should ref= lect what the agent is able and willing to support (as always). >>>> SRD> What two associations? Is there one association (end-to-end) or >>>> SRD> is >>>> the an association on both sides of the agent (hop-by-hop)? Or is >>>> there an association that involves three entities, the reporting node, >>>> an agent reacting node for realm-routed requests and a >>>> transaction-client reporting node for handling host-routed requests? >>>> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, There is >>>> one association between C and A, and one association between A and S. = Both associations are "end-to-end" as there may be transparent (supporting = or non-supporting) agents in the middle. >>>>> 6. clause 3.4, 2nd paragraph: >>>>> Should read: "The OC-OLR AVP is referred to as an overload report. T= he OC-OLR AVP includes the type of report, a sequence number, the length of= time that the report is valid and abatement algorithm specific AVPs." >>>> SRD> The sequence number is being used as an overload report ID. I can >>>> make the change but I don't see it as necessary. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. >>> OK to do the change. >>> >>>>> 7. clause 3.4, 4th paragraph, 2nd sentence: >>>>> I cannot understand this sentence. Probably only simple typos but I d= on't know. >>>> SRD> Yes, a typo (this instead of the) and awkward wording. How about >>>> "This applies to requests that contain the Destination-Host AVP with a >>>> DiameterIdentity that matches the overload report. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that cont= ain a DiameterIdentity in the Destination-Host AVP that matches the reporti= ng host's DiameterIdentity" >>> I would be inclined to keep the text Steve proposed. But both are ok ac= tually. >>> >>>>> 8. clause 3.4, 4th paragraph last 2 sentences: >>>>> I don't understand and probably do not agree. >>>> SRD> See above. >>>>> 9. clause 3.5, 3rd paragraph, last word: >>>>> Should read "communicated" >>>> SRD> Agreed. >>>>> 10. clause 3.5, 4th paragraph, 1st sentence: >>>>> I don't understand. I can understand: "Reporting nodes use the OC-OLR= AVP to communicate overload occurances towards reacting nodes." >>>> SRD> Who else would reports be sent to? >>>> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement algor= ithm but the reporting node that uses the OC-OLR AVP to communicate overloa= d occurances. >>> Agree. >>> >>>>> 11. clause 4.1, 3rd paragraph, last 4 words: >>>>> may be misleading. A DOIC supporting agent sitting between DOIC suppo= rting client and DOIC supporting Server is transparent with regard to DOIC.= This agent does not indicate DOIC support. >>>> SRD> I disagree. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Shou= ld be: ...This agent does not indicate its DOIC support, rather it transpar= ently forwards the client's DOIC support. >>> Agree with Ulrich on the intent of agent behavior but not with the prop= osed text change. >>> >>>>> 12. clause 4.1, 4th paragraph, 2nd sentence: >>>>> Should read:"If a request message handled by the DOIC agent does not = include the OC-Supported-Features AVP then the DOIC agent inserts the AVP." >>>> SRD> That is what it already says. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... >>> OC-Supported-Features can be in both request and answer, thus "If a mes= sage" in that sense is correct. >>> >>>>> 13. clause 4.1, last sentence: >>>>> Should read "If the message already has the AVP then the agent either= leaves it unchanged in the relayed message or replaces it to reflect the f= eatures the agent is able and willing to support." Clarification is needed = to say that strict rules must be followed by the agent to select the correc= t option. These rules take into account whether the request is host-routed = or relam-routed and whether the agent is configured to select the server fo= r realm-routed requests. >>>> SRD> This is a topic on agent behavior that is addressed in the agent >>>> cases draft. I'll leave the discussion for what the wording should be >>>> to the discussion on that draft. >>>>> 14. clause 4.1.2, 2nd paragraph: >>>>> Should read: "Based on the content of the OC-Supported-Features AVP i= n the request message, the reporting node knows what overload control funct= ionality is supported by the reacting node. The reporting node then acts a= ccordingly for the subsequent answer messages it initiates for the transact= ion." >>>> SRD> It would be easier if you didn't make it difficult to understand >>>> the change you are proposing. I think you are proposing changing >>>> node(s) to node. I don't agree but that will be addressed as part of >>>> the agent cases discussion. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing two= sentences? The proposal is to insert "is" between "functionality" and "sup= ported", to add "the" between "by" and "reacting", to replace "node(s)" wit= h "node", and to insert "for the transaction" after "initiates". >>> Agree with the proposed change. >>> >>>>> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >>>>> Should read: "message's" >>>> SRD> I'm assuming you mean section 4.1.2. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, a= nd 19. >>>> I agree to the change. >>>>> 16. clause 4.1, 6th paragraph: >>>>> This should be left to the (future) specification that introduces oth= er DOIC features. >>>>> >>>>> 17. clause 4.1, 7th paragraph, last 6 words: >>>>> should be based on requiements set by the (future) specification that >>>>> introduces other DOIC features >>>> SRD> Again, clause 4.1.2 -- I don't understand the issue when these >>>> SRD> two >>>> paragraphs are taken together. >>>>> 18. clause 4.1, 8th paragraph, last sentence: >>>>> Should read: "Lack of the OC-Supported-Features AVP in the request me= ssage indicates that there is no downstream reacting node for the transacti= on." >>>> SRD> I think you mean clause 4.1.2. I don't see the need for the chan= ge. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not cor= rect. It should either read: "Lack of the OC-Supported-Feature AVP in the r= equest message indicates to the reporting node that there is no reacting no= de for the transaction" or as proposed above. >>> I don't see a reason for the change. Original text seem correct to me. >>> >>>>> 19. clause 4.1, last sentence: >>>>> Should read: "An agent MAY replace the OC-Supported-Features AVP carr= ied in answer messages." This replacement must follow general rules. Its no= t so that the agent may do what ever it wants to. The decision must be base= d on whether or not the agent has replaced the OC-S-F in the corresponding = request. >>>> SRD> What is the difference between modify and replace? I am ok with >>>> removing this statement until we have the agent behavior discussion. >>>> I thought I had taken the agent specific statements out of this versio= n. >>>> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with identic= al values. You remove what has been received in and insert your own stuff. >>> Agent (proxy) can always do that i.e. modify the APV contents. Obviousl= y if an agent tampers the OC-Supported-Features AVP it needs to know what i= t is doing. In general agree with the clarification but not with the propos= ed text. >>> >>> - Jouni >>> >>>>> 20. clause 5.2, 1st sentence: >>>>> Should read: "A reporting node using the loss algorithm must use the = OC-Reduction-Percentage AVP (Section 6.7) to indicated the desired percenta= ge of traffic reduction." >>>> SRD> Agreed. >>>>> 21. clause 5.2, last sentence: >>>>> Should read: "Editor's note: The above duplicates what is in the OC-R= eduction-Percentage AVP section and can probably be removed." >>>> SRD> Yes, bad wording. The note will be removed, bad wording and all, >>>> once there is a discussion on if this is redundant. >>>>> 22. clause 5.4, 6th paragraph: >>>>> Should read: "If the reacting node does not receive a an OLR in the a= nswer that corresponds to the probe request messages sent to the formally o= verloaded node then the reacting node should slowly increase the rate of tr= affic sent to the overloaded node." >>>> SRD Agreed, this is more clear. >>>>> Best regards >>>>> Ulrich >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>> Donovan >>>>> Sent: Saturday, July 05, 2014 9:42 PM >>>>> To: dime@ietf.org >>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>> >>>>> All, >>>>> >>>>> This version of the DOIC draft is a restructuring of previously >>>>> agreed to content. >>>>> >>>>> The master plan for the restructuring is in Appendix C. This >>>>> outlines where material from -02 was moved in -03. >>>>> >>>>> For those interested, the work was done in steps, with a snapshot for >>>>> each step available here: >>>>> >>>>> https://github.com/jounikor/draft-docdt-dime-ovli >>>>> >>>>> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >>>>> >>>>> where nn indicates the subversion and "text" indicates the focus for >>>>> that subversion. >>>>> >>>>> The next step will be to resolve open issues already identified and >>>>> those yet those yet to be identified. >>>>> >>>>> Regards, >>>>> >>>>> Steve >>>>> >>>>> >>>>> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts d= irectories. >>>>>> This draft is a work item of the Diameter Maintenance and Ext= ensions Working Group of the IETF. >>>>>> >>>>>> Title : Diameter Overload Indication Conveya= nce >>>>>> Authors : Jouni Korhonen >>>>>> Steve Donovan >>>>>> Ben Campbell >>>>>> Lionel Morand >>>>>> Filename : draft-ietf-dime-ovli-03.txt >>>>>> Pages : 48 >>>>>> Date : 2014-07-03 >>>>>> >>>>>> Abstract: >>>>>> This specification documents a Diameter Overload Control (D= OC) base >>>>>> solution and the dissemination of the overload report infor= mation. >>>>>> >>>>>> Requirements >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-ovli-03 >>>>>> >>>>>> >>>>>> Please note that it may take a couple of minutes from the time of >>>>>> submission until the htmlized version and diff are available at tool= s.ietf.org. >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Tue Jul 29 09:51:38 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4C01A0364 for ; Tue, 29 Jul 2014 09:51:36 -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, SPF_NEUTRAL=0.779] autolearn=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 rersd_ZcPucD for ; Tue, 29 Jul 2014 09:51:33 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 EA5B61A032A for ; Tue, 29 Jul 2014 09:51:32 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:63558 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XCAcY-0005SV-A8; Tue, 29 Jul 2014 09:51:31 -0700 Message-ID: <53D7D10F.6030208@usdonovans.com> Date: Tue, 29 Jul 2014 11:51:27 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> <53D7AA31.3070908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520806A@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681520806A@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/X_qpnRY5_sjUu6tiIbaVlUCIolU Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 16:51:36 -0000 Ulrich, Thanks for the clarification. I agree, if the DOIC node that does server selection on a realm-routed request includes the destination-host after selecting the server then I'm good with your wording, modulo some cleanup. After we've seen if anyone objects to the wording, I'll come back with a detailed proposal for where the wording should go into the -04 version. Steve On 7/29/14, 10:41 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > It is my understanding that the node (client or agent) which performs server selection (e.g. selects server S) needs to make sure that any upstream agent will not undo the selection (e.g. by selecting another server Z). This can be ensured by inserting a Destination-Host AVP containing S's DiameterIdentity to the request. Inserting the Destinatio-Host AVP is not needed when there are no upstream agents i.e. when there is a "direct transport connection" to the selected server. The case where the node that selects the server for a realm-routed request has a direct transport connection to the selected server is not the general case. > > A DOICable node (client or agent) may face the situation where it has to send out a realm-routed request. Before sending the request it may detect that it (the node) is configured to perform server selection. The node selects server S. Now (still before sending the request out) the node detects (from checking overload states) that S is overloaded therefore it performs abatement (diversion to Z). Now the node may either have a direct transport connection to Z in which case it sends the request to Z (this is the case you covered), or it does not have a direct transport connetion to Z in which case it inserts the Destination-Host AVP with Z's Diameter Identity and sends the request to the next hop. > > > Ulrich > > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Tuesday, July 29, 2014 4:06 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org > Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) > > Ulrich, > > Thanks for the detailed response. I think we are very close to being in > agreement. > > The area I'm not sure about yet is using the wording "A DOIC node that > does server selection" versus "A DOIC node with a direct transport > connection". > > A client might think it is doing server selection even when it is > connecting to an agent. That is why I used the "direct transport > connection" wording to make it more explicit. > > What is the objection to this wording? > > This could also be solved by adding a definition of server selection, > but it would need to be done in a way that also addresses transactions > that flow from a Diameter server to a Diameter client. > > Regards. > > Steve > > On 7/29/14, 2:29 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Steve, >> >> I can agree with most of your statements. >> >> A DOICable agent needs to determine in which scenario it actually is. This decision must be based on presence/absence of OC-S-F-AVP in the received requests, presence/absence of Destination-Host AVP in the received request and configuration data (configured to select/not to select the server for realm routed requests). >> >> Once this decision is taken the agent >> a) inserts an OC-S-F to the request, or >> b) transparently forwards the request (i.e. does not remove or add an OC-S-F AVP), or >> c) removes the received OC-S-F AVP and inserts its own OC-S-F AVP >> >> note that c) includes the case where the removed AVP and the inserted AVP are identical. >> >> Case b) is the transparent case where the agent - although it supports DOIC (and DOIC is not turned off) - from an external point of view behaves like a non-DOICable node. >> >> See also inline. >> >> Regards, >> Ulrich >> (still trying to catch up with lots of mails) >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan >> Sent: Monday, July 21, 2014 4:29 PM >> To: dime@ietf.org >> Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) >> >> Ulrich, >> >> I am not arguing that all agents should take an active role in the >> handling of all overload reports. What I am arguing is that there are >> scenarios where an agent must take an active role in DOIC to ensure that >> a requested reduction in traffic an be achieved. >> >> For DOIC to work a carrier cannot turn off all DOIC behavior in agents, >> as suggested by Jouni. >> >> I agree that in your scenario below, a1 does not need to take an active >> role in reducing traffic when c supports DOIC. a1 should take an active >> role when c does not support DOIC. The problem is that a1 does not know >> in advance whether c supports DOIC so it will need to inspect all >> transactions for the presence of OC-S-F to determine if it needs to >> handle overload reports for a non supporting client. >> I agree >> >> Does that mean a1 is transparent if it inspects all requests and does >> nothing in the case where there is c supports DOIC? >> yes >> >> Does transparent mean that there is no observable difference in the DOIC >> AVPs that pass through the agent >> yes or does it mean that there is no >> observable difference in how transactions are handled by the DOIC agent? >> no >> >> I'm guessing that we have multiple assumptions on what transparent means >> and, if we are going to continue saying agents should be transparent >> then we need a definition of transparent. >> >> I think for this use case, we need the following normative statements in >> the draft for handling of abatement of realm-routed requests? I think >> this is general behavior and should go in the section on handling of >> overload reports. >> >> "DOIC nodes with a direct transport connection to a reporting node that >> has an active overload report must handle abatement of realm-routed >> requests. The preferred method for handling abatement of realm-routed >> requests is diversion, where the node with the direct transport >> connection routes the request to an alternative server that is able to >> handle the request. If there is no alternative server with the needed >> capacity to handle the request then the DOIC node must/should throttle >> the necessary requests to meet the requested reduction in traffic." >> My proposal: >> "A DOIC node with performs server selection for realm routed requests that >> has active overload reports from servers it potentially selects, must >> handle abatement of realm-routed >> requests. The preferred method for handling abatement of realm-routed >> requests is diversion, where the node selecting the server routes the >> request to an alternative server that is able to >> handle the request. If there is no alternative server with the needed >> capacity to handle the request then the DOIC node must/should preferrably >> delegate abatement (of realm routed requests) towards a downstream reacting >> node or otherwise throttle >> the necessary requests to meet the requested reduction in traffic." >> >> >> >> If we can agree on this then we can move on to the next agent based use >> case. >> >> Regards, >> >> Steve >> >> On 7/21/14, 9:47 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>> Steve, >>> >>> The example you show is absolutely valid and 100% inline with A) to F) - (assuming that all servers can serve any request). >>> However, there are other scenarios like: >>> >>> >>> >>> +--+ >>> /--|s1| >>> +-+ +--+ +--+ / +--+ >>> |c|--- |a1|--|a2|== ... >>> +-+ +--+ +--+ \ +--+ >>> \--|sn| >>> +--+ >>> >>> Here I think a1 should be transparent even when DOICable. >>> a1 does not take the role of a reacting node since c supports DOIC. >>> a1 does not perform server selection and therefore does not take the role of a reporting node (for realm-reports). >>> >>> Ulrich >>> >>> >>> -----Original Message----- >>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] >>> Sent: Monday, July 21, 2014 3:16 PM >>> To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org >>> Subject: Transparent agents (was Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt) >>> >>> Ok, let's see if it's possible to completely turn off all DOIC behavior >>> in agents and still be able to reduce traffic to a server that sends a >>> host overload report. >>> >>> Assume the following agent based deployment: >>> >>> +--+ >>> /--|s1| >>> +-+ +-+ / +--+ >>> |c|--|a|== ... >>> +-+ +-+ \ +--+ >>> \--|sn| >>> +--+ >>> >>> Assume that there is a large number of servers, say 50. >>> >>> Now, assume that the Diameter application in question exclusively uses >>> realm-routed requests - 100% of requests sent by the client do NOT have >>> a destination-host AVP. >>> >>> Now assume that server s1 sends an host type overload report requesting >>> a reduction of 20% using the loss algorithm. >>> >>> Also assume that the unused capacity in servers s2 through s50 is >>> sufficient to handle the traffic that would have been sent to s1. As >>> such, there is no reason to throttle any requests. >>> >>> There are no host routed requests for this application and the client >>> does not have a direct transport connection to server s1. The only >>> option a client has is to hand the request off to the agent for routing. >>> >>> The proposal in the agent cases draft is that the agent diverts 20% of >>> the realm routed requests that would have been sent to server s1 to >>> servers s2 through s50. >>> >>> If DOIC behavior is turned off in the agent then how will the traffic >>> routed to s1 be reduced? >>> >>> Steve >>> >>> On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote: >>>> +1 for the following aspect. >>>> >>>>>>> Agents must take an active role in even the most basic case for >>>>>>> overload handling to work, so they cannot be transparent. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not support DOIC are transparent. Agents that support DOIC in most cases behave like non supporting agents. >>>>> I am towards Ulrich's view here. Even for an agent that understands DOIC it is up to the local policy whether it is transparent or takes an active role. >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >>>> Sent: Monday, July 21, 2014 12:26 AM >>>> To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org >>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>> >>>> Some comments inline.. >>>> >>>> 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >>>>> Steve, >>>>> please see my response inline. >>>>> >>>>> Regards >>>>> Ulrich >>>>> >>>>> -----Original Message----- >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>> Donovan >>>>> Sent: Tuesday, July 15, 2014 3:53 PM >>>>> To: dime@ietf.org >>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>> >>>>> Ulrich, >>>>> >>>>> Thanks for the comments. Please see my responses inline. >>>>> >>>>> Regards, >>>>> >>>>> Steve >>>>> On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>>>> Hi Steve, >>>>>> here are my comments. >>>>>> They focus on new text you introduced. I agree that restructuring may require new text, however, I believe that with the new text a new concepts is introduced which macerates the agreed end-to-end concept and allows all DOIC agents on the path to do what they wants, so that we end up in a hop-by-hop concept. >>>>> SRD> We have never had an agreement on end-to-end versus hop-by-hop >>>>> SRD> and >>>>> I believe that we will end up with a hybrid of the two. We have open >>>>> issues on agent behavior that Ben and I are attempting to address with >>>>> the agent cases draft. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop approach of the roach draft was reason not to proceed with that draft. >>>>> >>>>> SRD> That said, this type of restructuring of the document is likely >>>>> SRD> to >>>>> put agreed to behavior in a new light. If there are cases where I >>>>> have implied changes to agreed to normative behavior, or if the >>>>> informative text is not accurate, then these things need to be corrected. >>>>>> 1. clause 2.3, second paragraph: >>>>>> Should read: "Reacting nodes indicate support for DOIC by including the OC-Supported-Features AVP into all request messages originated or relayed by the Reacting node." >>>>> SRD> You mean clause 3.2. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes >>>>> I agree with the change. >>>>>> 2. clause 2.3, 3rd paragraph, 1st sentence: >>>>>> OC-xxx AVPs must not be included in an answer message when the corresponding request did not contain an OC-S-F AVP. >>>>> SRD> Agreed. >>>>>> 3. clause 3.3, 7th paragraph: >>>>>> Should read "The reporting node only includes an indication of support for one overload abatement algorithm. This is the algorithm that the reporting node intends to use should it enter an overload condition or requests to use while it actually is in an overload condition. Reacting nodes can use the indicated overload abatement algorithm to prepare for possible overload reports and must use the indicated overload abatement algorithm if traffic reduction is actually requested." >>>>> SRD. OK. >>>>>> 4. clause 3.3, 10th paragraph: >>>>>> The 1st sentence is misleading. In the general case, agents on the path between reacting node and reporting node are transparent. I agree that there are exceptions to the general case where an agent on the path is not transparent, but then the agent IS the reporting node (reporting to the sender of the request) and it also IS the reacting node (reacting on reports received from the upstream reporting node). >>>>>> The first 3 words of the second sentence "in this case" need clarification: "In the case where an agent takes the role of a reporting node (reporting to the downstream reacting node) and at the same time takes the role of a reacting node (reacting on reports received from an upstream reporting node)". >>>>>> Last sentence: Its not an update but a replacement. The two DOIC associations are handled independently. >>>>> SRD> I don't know what you mean when you say an agent is transparent. >>>>> Agents must take an active role in even the most basic case for >>>>> overload handling to work, so they cannot be transparent. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not support DOIC are transparent. Agents that support DOIC in most cases behave like non supporting agents. >>>> I am towards Ulrich's view here. Even for an agent that understands DOIC it is up to the local policy whether it is transparent or takes an active role. >>>> >>>>>> 5. clause 3.3, last paragraph: >>>>>> General rules shall be followed for each of the two associations separately. The content of the OC-S-F AVP sent by the agent upstream should reflect what the agent is able and willing to support (as always). >>>>> SRD> What two associations? Is there one association (end-to-end) or >>>>> SRD> is >>>>> the an association on both sides of the agent (hop-by-hop)? Or is >>>>> there an association that involves three entities, the reporting node, >>>>> an agent reacting node for realm-routed requests and a >>>>> transaction-client reporting node for handling host-routed requests? >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, There is >>>>> one association between C and A, and one association between A and S. Both associations are "end-to-end" as there may be transparent (supporting or non-supporting) agents in the middle. >>>>>> 6. clause 3.4, 2nd paragraph: >>>>>> Should read: "The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP includes the type of report, a sequence number, the length of time that the report is valid and abatement algorithm specific AVPs." >>>>> SRD> The sequence number is being used as an overload report ID. I can >>>>> make the change but I don't see it as necessary. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. >>>> OK to do the change. >>>> >>>>>> 7. clause 3.4, 4th paragraph, 2nd sentence: >>>>>> I cannot understand this sentence. Probably only simple typos but I don't know. >>>>> SRD> Yes, a typo (this instead of the) and awkward wording. How about >>>>> "This applies to requests that contain the Destination-Host AVP with a >>>>> DiameterIdentity that matches the overload report. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that contain a DiameterIdentity in the Destination-Host AVP that matches the reporting host's DiameterIdentity" >>>> I would be inclined to keep the text Steve proposed. But both are ok actually. >>>> >>>>>> 8. clause 3.4, 4th paragraph last 2 sentences: >>>>>> I don't understand and probably do not agree. >>>>> SRD> See above. >>>>>> 9. clause 3.5, 3rd paragraph, last word: >>>>>> Should read "communicated" >>>>> SRD> Agreed. >>>>>> 10. clause 3.5, 4th paragraph, 1st sentence: >>>>>> I don't understand. I can understand: "Reporting nodes use the OC-OLR AVP to communicate overload occurances towards reacting nodes." >>>>> SRD> Who else would reports be sent to? >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement algorithm but the reporting node that uses the OC-OLR AVP to communicate overload occurances. >>>> Agree. >>>> >>>>>> 11. clause 4.1, 3rd paragraph, last 4 words: >>>>>> may be misleading. A DOIC supporting agent sitting between DOIC supporting client and DOIC supporting Server is transparent with regard to DOIC. This agent does not indicate DOIC support. >>>>> SRD> I disagree. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Should be: ...This agent does not indicate its DOIC support, rather it transparently forwards the client's DOIC support. >>>> Agree with Ulrich on the intent of agent behavior but not with the proposed text change. >>>> >>>>>> 12. clause 4.1, 4th paragraph, 2nd sentence: >>>>>> Should read:"If a request message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent inserts the AVP." >>>>> SRD> That is what it already says. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... >>>> OC-Supported-Features can be in both request and answer, thus "If a message" in that sense is correct. >>>> >>>>>> 13. clause 4.1, last sentence: >>>>>> Should read "If the message already has the AVP then the agent either leaves it unchanged in the relayed message or replaces it to reflect the features the agent is able and willing to support." Clarification is needed to say that strict rules must be followed by the agent to select the correct option. These rules take into account whether the request is host-routed or relam-routed and whether the agent is configured to select the server for realm-routed requests. >>>>> SRD> This is a topic on agent behavior that is addressed in the agent >>>>> cases draft. I'll leave the discussion for what the wording should be >>>>> to the discussion on that draft. >>>>>> 14. clause 4.1.2, 2nd paragraph: >>>>>> Should read: "Based on the content of the OC-Supported-Features AVP in the request message, the reporting node knows what overload control functionality is supported by the reacting node. The reporting node then acts accordingly for the subsequent answer messages it initiates for the transaction." >>>>> SRD> It would be easier if you didn't make it difficult to understand >>>>> the change you are proposing. I think you are proposing changing >>>>> node(s) to node. I don't agree but that will be addressed as part of >>>>> the agent cases discussion. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing two sentences? The proposal is to insert "is" between "functionality" and "supported", to add "the" between "by" and "reacting", to replace "node(s)" with "node", and to insert "for the transaction" after "initiates". >>>> Agree with the proposed change. >>>> >>>>>> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >>>>>> Should read: "message's" >>>>> SRD> I'm assuming you mean section 4.1.2. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, and 19. >>>>> I agree to the change. >>>>>> 16. clause 4.1, 6th paragraph: >>>>>> This should be left to the (future) specification that introduces other DOIC features. >>>>>> >>>>>> 17. clause 4.1, 7th paragraph, last 6 words: >>>>>> should be based on requiements set by the (future) specification that >>>>>> introduces other DOIC features >>>>> SRD> Again, clause 4.1.2 -- I don't understand the issue when these >>>>> SRD> two >>>>> paragraphs are taken together. >>>>>> 18. clause 4.1, 8th paragraph, last sentence: >>>>>> Should read: "Lack of the OC-Supported-Features AVP in the request message indicates that there is no downstream reacting node for the transaction." >>>>> SRD> I think you mean clause 4.1.2. I don't see the need for the change. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not correct. It should either read: "Lack of the OC-Supported-Feature AVP in the request message indicates to the reporting node that there is no reacting node for the transaction" or as proposed above. >>>> I don't see a reason for the change. Original text seem correct to me. >>>> >>>>>> 19. clause 4.1, last sentence: >>>>>> Should read: "An agent MAY replace the OC-Supported-Features AVP carried in answer messages." This replacement must follow general rules. Its not so that the agent may do what ever it wants to. The decision must be based on whether or not the agent has replaced the OC-S-F in the corresponding request. >>>>> SRD> What is the difference between modify and replace? I am ok with >>>>> removing this statement until we have the agent behavior discussion. >>>>> I thought I had taken the agent specific statements out of this version. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with identical values. You remove what has been received in and insert your own stuff. >>>> Agent (proxy) can always do that i.e. modify the APV contents. Obviously if an agent tampers the OC-Supported-Features AVP it needs to know what it is doing. In general agree with the clarification but not with the proposed text. >>>> >>>> - Jouni >>>> >>>>>> 20. clause 5.2, 1st sentence: >>>>>> Should read: "A reporting node using the loss algorithm must use the OC-Reduction-Percentage AVP (Section 6.7) to indicated the desired percentage of traffic reduction." >>>>> SRD> Agreed. >>>>>> 21. clause 5.2, last sentence: >>>>>> Should read: "Editor's note: The above duplicates what is in the OC-Reduction-Percentage AVP section and can probably be removed." >>>>> SRD> Yes, bad wording. The note will be removed, bad wording and all, >>>>> once there is a discussion on if this is redundant. >>>>>> 22. clause 5.4, 6th paragraph: >>>>>> Should read: "If the reacting node does not receive a an OLR in the answer that corresponds to the probe request messages sent to the formally overloaded node then the reacting node should slowly increase the rate of traffic sent to the overloaded node." >>>>> SRD Agreed, this is more clear. >>>>>> Best regards >>>>>> Ulrich >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>>> Donovan >>>>>> Sent: Saturday, July 05, 2014 9:42 PM >>>>>> To: dime@ietf.org >>>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>> >>>>>> All, >>>>>> >>>>>> This version of the DOIC draft is a restructuring of previously >>>>>> agreed to content. >>>>>> >>>>>> The master plan for the restructuring is in Appendix C. This >>>>>> outlines where material from -02 was moved in -03. >>>>>> >>>>>> For those interested, the work was done in steps, with a snapshot for >>>>>> each step available here: >>>>>> >>>>>> https://github.com/jounikor/draft-docdt-dime-ovli >>>>>> >>>>>> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >>>>>> >>>>>> where nn indicates the subversion and "text" indicates the focus for >>>>>> that subversion. >>>>>> >>>>>> The next step will be to resolve open issues already identified and >>>>>> those yet those yet to be identified. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>>>> This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. >>>>>>> >>>>>>> Title : Diameter Overload Indication Conveyance >>>>>>> Authors : Jouni Korhonen >>>>>>> Steve Donovan >>>>>>> Ben Campbell >>>>>>> Lionel Morand >>>>>>> Filename : draft-ietf-dime-ovli-03.txt >>>>>>> Pages : 48 >>>>>>> Date : 2014-07-03 >>>>>>> >>>>>>> Abstract: >>>>>>> This specification documents a Diameter Overload Control (DOC) base >>>>>>> solution and the dissemination of the overload report information. >>>>>>> >>>>>>> Requirements >>>>>>> >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>>>>>> >>>>>>> There's also a htmlized version available at: >>>>>>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-03 >>>>>>> >>>>>>> >>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>> submission until the htmlized version and diff are available at tools.ietf.org. >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>> DiME@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > From nobody Tue Jul 29 12:22:29 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98671A02D8 for ; Tue, 29 Jul 2014 12:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=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 N4-GX9ZLbAIF for ; Tue, 29 Jul 2014 12:22:25 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 1A0AA1A01CB for ; Tue, 29 Jul 2014 12:22:25 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:65069 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XCCyd-0004tM-0N for dime@ietf.org; Tue, 29 Jul 2014 12:22:23 -0700 Message-ID: <53D7F470.3090500@usdonovans.com> Date: Tue, 29 Jul 2014 14:22:24 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/jnUHKgIYzZGp9UwUp5yqIct19eE Subject: [Dime] Issue #23 - Proposed resolution X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 19:22:25 -0000 Issue @23 points out that there are two interpretations of the realm overload report in the current text. One implies that a realm report applies to all requests sent to the realm, the other implies that it only applies to requests sent to the realm that does not contain a destination-host AVP. I believe we have consensus to use the second definition. There was also a proposal, made by me, to change the name of the report to something like "realm-routed-request" to be more accurate in defining what the scope of the overload report. I no longer think this is necessary and am happy with the "realm" name for the report. If we have agreement on the direction then I will identify the text that needs to be changed to remove the conflicting definitions of the report type. I will send it to the list for review before incorporating it into the -04 version of the draft and closing the issue. Please let me know if there are issues with this proposal. Regards, Steve From nobody Tue Jul 29 12:33:59 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F291A0453 for ; Tue, 29 Jul 2014 12:33:57 -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, SPF_NEUTRAL=0.779] autolearn=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 wY5SyDc9otlK for ; Tue, 29 Jul 2014 12:33:56 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 44AA11A0356 for ; Tue, 29 Jul 2014 12:33:56 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:65105 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XCD9j-0000e3-58 for dime@ietf.org; Tue, 29 Jul 2014 12:33:54 -0700 Message-ID: <53D7F720.90503@usdonovans.com> Date: Tue, 29 Jul 2014 14:33:52 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <53D640F6.5080502@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/w4nBovwFIsAV3GzlA6NlncQvXI0 Subject: Re: [Dime] meeting minutes uploada X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 19:33:57 -0000 Dave, My take is that it is clear the DOIC AVPs and behaviors will not be incorporated into the base protocol. I was a little loose in my terminology during the meeting. The goal, at least for me, has been to define a common mechanism for Diameter nodes to exchange Diameter Overload related AVPs, with the necessary behavior defined for the handling of those AVPs. Application specifications will then be updated to reference the DOIC specification. This process has already started in 3GPP, with updates to many of the 3GPP specification already made. It is a measure of our success in defining a common mechanism that can be reused unchanged by Diameter applications that the updates to the application specifications has been a very straight forward process. This has consisted primarily of adding the AVPs to the list of application AVPs and referencing of the DOIC specification for behavior associated with those AVPs. Regards, Steve On 7/29/14, 8:29 AM, Dave Dolson wrote: > I'm the "Dave" (Dolson, Dawson, etc.) in the minutes. > > My understanding in the meeting discussion about DOIC was that the DOIC AVPs will have to be added to application protocols. > In other words, NOT added to the base protocol, and no existing Diameter agents or end-points will be expected to understand it. > > My reasoning was that abatement is always application-specific, requiring knowledge of message semantics. > > But from the minutes, that conclusion isn't clear. I may have heard what I wanted to hear rather than what was actually said... > > So, is the intent to define a new mechanism that may be used with new protocols and protocol updates, or is the intent to put DOIC in the base such that all protocols automatically inherit it? > > >> Dave - You will get the doc through quicker if you don't explain the >> approaches when you get the AVP. 4006 type applications - session-based >> applications. Here's one for stateless. > My point here is, just define the AVP and indicate how it should be used, in the sense of providing design patterns (for stateless, online charging, offline charging, etc). Then we don't have to debate the corner-cases of the abatement algorithms of all applications; we just need to agree on the wire format. Then applications can start to reference it, one by one. > > > David Dolson > Senior Software Architect, Sandvine Inc. > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Monday, July 28, 2014 8:24 AM > To: dime@ietf.org > Subject: [Dime] meeting minutes uploada > > Thanks to Jean for extensive minutes & notes: > http://tools.ietf.org/wg/dime/minutes?item=minutes-90-dime.html > > - Jouni > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Tue Jul 29 12:55:10 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EAC1B27DC for ; Tue, 29 Jul 2014 12:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=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 3lFovWWgXtJg for ; Tue, 29 Jul 2014 12:55:08 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 A47CF1ABB22 for ; Tue, 29 Jul 2014 12:55:08 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:65198 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XCDUI-0006Yv-4o for dime@ietf.org; Tue, 29 Jul 2014 12:55:07 -0700 Message-ID: <53D7FC1B.8070708@usdonovans.com> Date: Tue, 29 Jul 2014 14:55:07 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/8Weoxrqarc0Vp_zlK77HSjQ_4iM Subject: [Dime] Issue #26 proposed resolution X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jul 2014 19:55:09 -0000 All, Issue #26 - Overload control endpoints under specified. During the DIME meeting in Toronto the proposal was made to remove the concept of Endpoints and Associations. These concepts were helpful getting the specification to where it is now but a number of us consider the concepts to be confusing at best and potentially misleading. The high level proposal is to remove section 3.1 that talks about Overload Control Endpoints and DOIC Associations. The remainder of the document would then be updated to handle any references to that section and to the concepts of endpoint and association. I've done a quick review of the document and there are a number of places where the term "overload control endpoint" is used. I think most of these can be changed to "overload control node" or "DOIC node" with no additional change needed (other than to define these terms in the terminology section). I want to see if there are any objections to this potential change before doing the work to propose specific wording changes. If there is general agreement then I will come back to the list with detailed proposal for wording changes that would be reflected in the -04 version of the draft. The other option would be to rewrite section 3.1 to have a more concise definition of endpoint, most likely removing the concept of DOIC association. Regards, Steve From nobody Tue Jul 29 21:34:46 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923EA1A0658 for ; Tue, 29 Jul 2014 21:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 zi-VvyOEQyFg for ; Tue, 29 Jul 2014 21:34:42 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D09D1A02CB for ; Tue, 29 Jul 2014 21:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3938; q=dns/txt; s=iport; t=1406694882; x=1407904482; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=BpvBLNA2d+YiaFmR6JjUgHMJBXXNJHxa7NPseUToh7I=; b=JOdivsd2NFWrIE1sv1kUttVN0ZHQvkMob0Gs1poH7+CuowFlUss/+tP+ B0fwPDxaw8as4meksxPCw2gua1YVuzRZac9+/nn5Y3oRmxK9j44hdr77L n1IrE6W5JJLcx5a3ZB9mJcnaekc5W5gkw1kUR5EdHsA9pK/50xrCpHu1M o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFABN12FOtJA2H/2dsb2JhbABagw5SVwTLcgqHSwGBERZ3hAMBAQEEAQEBNzQXBAIBCA4DBAEBAQoLCQkHJwsUCQgCBAESCBOIJw3AGRePGzgGBIMlgRsFjlqOTJJ+g0lsAYFE X-IronPort-AV: E=Sophos;i="5.01,762,1400025600"; d="scan'208";a="65063991" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP; 30 Jul 2014 04:34:41 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s6U4Yfs2030129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jul 2014 04:34:41 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 29 Jul 2014 23:34:41 -0500 From: "Nirav Salot (nsalot)" To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] meeting minutes uploada Thread-Index: AQHPql7lctlX7jEClkid0vIIiCw9x5u3YU0AgABl1ACAAEI+QA== Date: Wed, 30 Jul 2014 04:34:40 +0000 Message-ID: References: <53D640F6.5080502@gmail.com> <53D7F720.90503@usdonovans.com> In-Reply-To: <53D7F720.90503@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.140.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kLSwPoa5KUBtNS0TZFFGo_n3ddc Subject: Re: [Dime] meeting minutes uploada X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 04:34:44 -0000 I agree with Steve. Additionally, just defining the wire format of the AVP does not suffice sin= ce we have to provide guidelines/information on how to generate those AVPs = and how to use those AVPs. This requires taking of different types/categories of the application into = account and coming up with a general solution which works across all the ap= plications. In my view, the current state of the draft is successful in achieving the s= ame. Regards, Nirav. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, July 30, 2014 1:04 AM To: dime@ietf.org Subject: Re: [Dime] meeting minutes uploada Dave, My take is that it is clear the DOIC AVPs and behaviors will not be incorpo= rated into the base protocol. I was a little loose in my terminology durin= g the meeting. The goal, at least for me, has been to define a common mechanism for Diamet= er nodes to exchange Diameter Overload related AVPs, with the necessary beh= avior defined for the handling of those AVPs. Application specifications will then be updated to reference the DOIC speci= fication. This process has already started in 3GPP, with updates to many o= f the 3GPP specification already made. It is a measure of our success in defining a common mechanism that can be r= eused unchanged by Diameter applications that the updates to the applicatio= n specifications has been a very straight forward process. =20 This has consisted primarily of adding the AVPs to the list of application = AVPs and referencing of the DOIC specification for behavior associated with= those AVPs. Regards, Steve On 7/29/14, 8:29 AM, Dave Dolson wrote: > I'm the "Dave" (Dolson, Dawson, etc.) in the minutes. > > My understanding in the meeting discussion about DOIC was that the DOIC A= VPs will have to be added to application protocols. > In other words, NOT added to the base protocol, and no existing Diameter = agents or end-points will be expected to understand it. > > My reasoning was that abatement is always application-specific, requiring= knowledge of message semantics. > > But from the minutes, that conclusion isn't clear. I may have heard what = I wanted to hear rather than what was actually said... > > So, is the intent to define a new mechanism that may be used with new pro= tocols and protocol updates, or is the intent to put DOIC in the base such = that all protocols automatically inherit it? > > >> Dave - You will get the doc through quicker if you don't explain the >> approaches when you get the AVP. 4006 type applications - ses= sion-based >> applications. Here's one for stateless. > My point here is, just define the AVP and indicate how it should be used,= in the sense of providing design patterns (for stateless, online charging,= offline charging, etc). Then we don't have to debate the corner-cases of t= he abatement algorithms of all applications; we just need to agree on the w= ire format. Then applications can start to reference it, one by one. > > > David Dolson > Senior Software Architect, Sandvine Inc. > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Monday, July 28, 2014 8:24 AM > To: dime@ietf.org > Subject: [Dime] meeting minutes uploada > > Thanks to Jean for extensive minutes & notes: > http://tools.ietf.org/wg/dime/minutes?item=3Dminutes-90-dime.html > > - Jouni > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Wed Jul 30 01:41:36 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B293E1A00C5 for ; Wed, 30 Jul 2014 01:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 6qtyXxsTc0g8 for ; Wed, 30 Jul 2014 01:41:32 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1521A002D for ; Wed, 30 Jul 2014 01:41:31 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s6U8fTh0015610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Jul 2014 08:41:29 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s6U8fSaV006687 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jul 2014 10:41:29 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0195.001; Wed, 30 Jul 2014 10:41:28 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Issue #26 proposed resolution Thread-Index: AQHPq2cEyZmPqkOA/ESTMznzMpqHQJu4P67w Date: Wed, 30 Jul 2014 08:41:28 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681520812B@DEMUMBX014.nsn-intra.net> References: <53D7FC1B.8070708@usdonovans.com> In-Reply-To: <53D7FC1B.8070708@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2604 X-purgate-ID: 151667::1406709689-00007A71-0FF41D14/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/_t2DIl7w4WoIXQaLUy2X08EsYjs Subject: Re: [Dime] Issue #26 proposed resolution X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 08:41:34 -0000 Steve, I find the concept of DOIC End Points (and DOIC associations between DOIC E= nd Points) helpful; especially the figures in section 3.1 are useful as the= y show valid scenarios. I, however, agree that more clarifying text is needed to say how nodes dete= ct in wich scenario they actually are. E.g. with regard to figure 2, current text says "... there is an agent that is not participating directly in the exchange = of overload reports." but it is not said how the agent determines that it should/must be transpar= ent. Similarly for other figures. Rather than deleting clause 3.1, I would prefer to add text providing rules= for nodes to detect which of the valid scenarios is actually applicable. P= lease see my proposal of rules A) to F) sent on July 11th. Regards, Ulrich =20 -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Tuesday, July 29, 2014 9:55 PM To: dime@ietf.org Subject: [Dime] Issue #26 proposed resolution All, Issue #26 - Overload control endpoints under specified. During the DIME meeting in Toronto the proposal was made to remove the=20 concept of Endpoints and Associations. These concepts were helpful getting the specification to where it is now=20 but a number of us consider the concepts to be confusing at best and=20 potentially misleading. The high level proposal is to remove section 3.1 that talks about=20 Overload Control Endpoints and DOIC Associations. The remainder of the=20 document would then be updated to handle any references to that section=20 and to the concepts of endpoint and association. I've done a quick review of the document and there are a number of=20 places where the term "overload control endpoint" is used. I think most=20 of these can be changed to "overload control node" or "DOIC node" with=20 no additional change needed (other than to define these terms in the=20 terminology section). I want to see if there are any objections to this potential change=20 before doing the work to propose specific wording changes. If there is=20 general agreement then I will come back to the list with detailed=20 proposal for wording changes that would be reflected in the -04 version=20 of the draft. The other option would be to rewrite section 3.1 to have a more concise=20 definition of endpoint, most likely removing the concept of DOIC=20 association. Regards, Steve _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Wed Jul 30 05:01:22 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FD71B27AC for ; Wed, 30 Jul 2014 05:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 SAqzbXUxzyAI for ; Wed, 30 Jul 2014 05:01:15 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAEA01B27B1 for ; Wed, 30 Jul 2014 05:01:14 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id e16so812159lan.11 for ; Wed, 30 Jul 2014 05:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=1y2EZv1LTbkFHidtDBkrzYs8+K0gXTdGY/qY9ldY38E=; b=ugDpWnb4ClBhheyTjknVRoTxPIQY6TkNe3P/PAql2nttmd2qmvrvS/U97iZNaFu3wq i9jTBW8XGkRsoXzLBYIXhSb1PFbgJPC6VEuqhjVgT+nd5KNe+WzFfpPZfwxvG2BJNWnN 6arCC9+b7uS3eu/Wjl+cNIHIuf5svWTLzXytX3jtJGnClQjej2CO10BFDG8+jyKSW+y+ 0BActTlyRH5A82mEsB69n3J/6FacMPym6GA3GxC6vRuVe5wRlHoa21yaXy/NhroFQJvN 6q/cyJEiI98QB3zHwme6sYBy+/LS5qHgMJXUG6NoPTqUWtzwCJs/l4hNnpZtbsdRTESm IM5g== X-Received: by 10.112.52.225 with SMTP id w1mr3993810lbo.44.1406721673042; Wed, 30 Jul 2014 05:01:13 -0700 (PDT) Received: from [192.168.250.216] ([194.100.71.98]) by mx.google.com with ESMTPSA id h3sm1132393lah.20.2014.07.30.05.01.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 05:01:12 -0700 (PDT) Message-ID: <53D8DE85.5040201@gmail.com> Date: Wed, 30 Jul 2014 15:01:09 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , ext Steve Donovan , "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> <53D7AA31.3070908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520806A@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681520806A@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Rdb7tv4LVy0opq2rq7vg46P0W_c Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 12:01:21 -0000 Few comments inline.. 7/29/2014 6:41 PM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: > Steve, > > It is my understanding that the node (client or agent) which performs server selection (e.g. selects server S) needs to make sure that any upstream agent will not undo the selection (e.g. by selecting another server Z). This can be ensured by inserting a Destination-Host AVP containing S's DiameterIdentity to the request. Inserting the Destinatio-Host AVP is not needed when there are no upstream agents i.e. when there is a "direct transport connection" to the selected server. The case where the node that selects the server for a realm-routed request has a direct transport connection to the selected server is not the general case. > > A DOICable node (client or agent) may face the situation where it has to send out a realm-routed request. Before sending the request it may detect that it (the node) is configured to perform server selection. The node selects server S. Now (still before sending the request out) the node detects (from checking overload states) that S is overloaded therefore it performs abatement (diversion to Z). Now the node may either have a direct transport connection to Z in which case it sends the request to Z (this is the case you covered), or it does not have a direct transport connetion to Z in which case it inserts the Destination-Host AVP with Z's Diameter Identity and sends the request to the next hop. I have a problem with this. My understanding is that the server selection does not imply intermediate nodes inserting Destination-Host into the request independent there is direct transport connection or not.. Or am I reading the intention of this paragraph wrong? Up to the point the realm routed (Destination-Realm only case) request reaches the "server" it is pure routing & forwarding of the request. The insertion of the Destination-Host is done by the client when it has learned the used server (from the Origin-Host). If the client has the desination host information already it may or may not insert Destination-Host into request.. depending of its needs. - Jouni > > > Ulrich > > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Tuesday, July 29, 2014 4:06 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org > Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) > > Ulrich, > > Thanks for the detailed response. I think we are very close to being in > agreement. > > The area I'm not sure about yet is using the wording "A DOIC node that > does server selection" versus "A DOIC node with a direct transport > connection". > > A client might think it is doing server selection even when it is > connecting to an agent. That is why I used the "direct transport > connection" wording to make it more explicit. > > What is the objection to this wording? > > This could also be solved by adding a definition of server selection, > but it would need to be done in a way that also addresses transactions > that flow from a Diameter server to a Diameter client. > > Regards. > > Steve > > On 7/29/14, 2:29 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Steve, >> >> I can agree with most of your statements. >> >> A DOICable agent needs to determine in which scenario it actually is. This decision must be based on presence/absence of OC-S-F-AVP in the received requests, presence/absence of Destination-Host AVP in the received request and configuration data (configured to select/not to select the server for realm routed requests). >> >> Once this decision is taken the agent >> a) inserts an OC-S-F to the request, or >> b) transparently forwards the request (i.e. does not remove or add an OC-S-F AVP), or >> c) removes the received OC-S-F AVP and inserts its own OC-S-F AVP >> >> note that c) includes the case where the removed AVP and the inserted AVP are identical. >> >> Case b) is the transparent case where the agent - although it supports DOIC (and DOIC is not turned off) - from an external point of view behaves like a non-DOICable node. >> >> See also inline. >> >> Regards, >> Ulrich >> (still trying to catch up with lots of mails) >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan >> Sent: Monday, July 21, 2014 4:29 PM >> To: dime@ietf.org >> Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) >> >> Ulrich, >> >> I am not arguing that all agents should take an active role in the >> handling of all overload reports. What I am arguing is that there are >> scenarios where an agent must take an active role in DOIC to ensure that >> a requested reduction in traffic an be achieved. >> >> For DOIC to work a carrier cannot turn off all DOIC behavior in agents, >> as suggested by Jouni. >> >> I agree that in your scenario below, a1 does not need to take an active >> role in reducing traffic when c supports DOIC. a1 should take an active >> role when c does not support DOIC. The problem is that a1 does not know >> in advance whether c supports DOIC so it will need to inspect all >> transactions for the presence of OC-S-F to determine if it needs to >> handle overload reports for a non supporting client. >> I agree >> >> Does that mean a1 is transparent if it inspects all requests and does >> nothing in the case where there is c supports DOIC? >> yes >> >> Does transparent mean that there is no observable difference in the DOIC >> AVPs that pass through the agent >> yes or does it mean that there is no >> observable difference in how transactions are handled by the DOIC agent? >> no >> >> I'm guessing that we have multiple assumptions on what transparent means >> and, if we are going to continue saying agents should be transparent >> then we need a definition of transparent. >> >> I think for this use case, we need the following normative statements in >> the draft for handling of abatement of realm-routed requests? I think >> this is general behavior and should go in the section on handling of >> overload reports. >> >> "DOIC nodes with a direct transport connection to a reporting node that >> has an active overload report must handle abatement of realm-routed >> requests. The preferred method for handling abatement of realm-routed >> requests is diversion, where the node with the direct transport >> connection routes the request to an alternative server that is able to >> handle the request. If there is no alternative server with the needed >> capacity to handle the request then the DOIC node must/should throttle >> the necessary requests to meet the requested reduction in traffic." >> My proposal: >> "A DOIC node with performs server selection for realm routed requests that >> has active overload reports from servers it potentially selects, must >> handle abatement of realm-routed >> requests. The preferred method for handling abatement of realm-routed >> requests is diversion, where the node selecting the server routes the >> request to an alternative server that is able to >> handle the request. If there is no alternative server with the needed >> capacity to handle the request then the DOIC node must/should preferrably >> delegate abatement (of realm routed requests) towards a downstream reacting >> node or otherwise throttle >> the necessary requests to meet the requested reduction in traffic." >> >> >> >> If we can agree on this then we can move on to the next agent based use >> case. >> >> Regards, >> >> Steve >> >> On 7/21/14, 9:47 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>> Steve, >>> >>> The example you show is absolutely valid and 100% inline with A) to F) - (assuming that all servers can serve any request). >>> However, there are other scenarios like: >>> >>> >>> >>> +--+ >>> /--|s1| >>> +-+ +--+ +--+ / +--+ >>> |c|--- |a1|--|a2|== ... >>> +-+ +--+ +--+ \ +--+ >>> \--|sn| >>> +--+ >>> >>> Here I think a1 should be transparent even when DOICable. >>> a1 does not take the role of a reacting node since c supports DOIC. >>> a1 does not perform server selection and therefore does not take the role of a reporting node (for realm-reports). >>> >>> Ulrich >>> >>> >>> -----Original Message----- >>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] >>> Sent: Monday, July 21, 2014 3:16 PM >>> To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org >>> Subject: Transparent agents (was Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt) >>> >>> Ok, let's see if it's possible to completely turn off all DOIC behavior >>> in agents and still be able to reduce traffic to a server that sends a >>> host overload report. >>> >>> Assume the following agent based deployment: >>> >>> +--+ >>> /--|s1| >>> +-+ +-+ / +--+ >>> |c|--|a|== ... >>> +-+ +-+ \ +--+ >>> \--|sn| >>> +--+ >>> >>> Assume that there is a large number of servers, say 50. >>> >>> Now, assume that the Diameter application in question exclusively uses >>> realm-routed requests - 100% of requests sent by the client do NOT have >>> a destination-host AVP. >>> >>> Now assume that server s1 sends an host type overload report requesting >>> a reduction of 20% using the loss algorithm. >>> >>> Also assume that the unused capacity in servers s2 through s50 is >>> sufficient to handle the traffic that would have been sent to s1. As >>> such, there is no reason to throttle any requests. >>> >>> There are no host routed requests for this application and the client >>> does not have a direct transport connection to server s1. The only >>> option a client has is to hand the request off to the agent for routing. >>> >>> The proposal in the agent cases draft is that the agent diverts 20% of >>> the realm routed requests that would have been sent to server s1 to >>> servers s2 through s50. >>> >>> If DOIC behavior is turned off in the agent then how will the traffic >>> routed to s1 be reduced? >>> >>> Steve >>> >>> On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote: >>>> +1 for the following aspect. >>>> >>>>>>> Agents must take an active role in even the most basic case for >>>>>>> overload handling to work, so they cannot be transparent. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not support DOIC are transparent. Agents that support DOIC in most cases behave like non supporting agents. >>>>> I am towards Ulrich's view here. Even for an agent that understands DOIC it is up to the local policy whether it is transparent or takes an active role. >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >>>> Sent: Monday, July 21, 2014 12:26 AM >>>> To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org >>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>> >>>> Some comments inline.. >>>> >>>> 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >>>>> Steve, >>>>> please see my response inline. >>>>> >>>>> Regards >>>>> Ulrich >>>>> >>>>> -----Original Message----- >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>> Donovan >>>>> Sent: Tuesday, July 15, 2014 3:53 PM >>>>> To: dime@ietf.org >>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>> >>>>> Ulrich, >>>>> >>>>> Thanks for the comments. Please see my responses inline. >>>>> >>>>> Regards, >>>>> >>>>> Steve >>>>> On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>>>> Hi Steve, >>>>>> here are my comments. >>>>>> They focus on new text you introduced. I agree that restructuring may require new text, however, I believe that with the new text a new concepts is introduced which macerates the agreed end-to-end concept and allows all DOIC agents on the path to do what they wants, so that we end up in a hop-by-hop concept. >>>>> SRD> We have never had an agreement on end-to-end versus hop-by-hop >>>>> SRD> and >>>>> I believe that we will end up with a hybrid of the two. We have open >>>>> issues on agent behavior that Ben and I are attempting to address with >>>>> the agent cases draft. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop approach of the roach draft was reason not to proceed with that draft. >>>>> >>>>> SRD> That said, this type of restructuring of the document is likely >>>>> SRD> to >>>>> put agreed to behavior in a new light. If there are cases where I >>>>> have implied changes to agreed to normative behavior, or if the >>>>> informative text is not accurate, then these things need to be corrected. >>>>>> 1. clause 2.3, second paragraph: >>>>>> Should read: "Reacting nodes indicate support for DOIC by including the OC-Supported-Features AVP into all request messages originated or relayed by the Reacting node." >>>>> SRD> You mean clause 3.2. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes >>>>> I agree with the change. >>>>>> 2. clause 2.3, 3rd paragraph, 1st sentence: >>>>>> OC-xxx AVPs must not be included in an answer message when the corresponding request did not contain an OC-S-F AVP. >>>>> SRD> Agreed. >>>>>> 3. clause 3.3, 7th paragraph: >>>>>> Should read "The reporting node only includes an indication of support for one overload abatement algorithm. This is the algorithm that the reporting node intends to use should it enter an overload condition or requests to use while it actually is in an overload condition. Reacting nodes can use the indicated overload abatement algorithm to prepare for possible overload reports and must use the indicated overload abatement algorithm if traffic reduction is actually requested." >>>>> SRD. OK. >>>>>> 4. clause 3.3, 10th paragraph: >>>>>> The 1st sentence is misleading. In the general case, agents on the path between reacting node and reporting node are transparent. I agree that there are exceptions to the general case where an agent on the path is not transparent, but then the agent IS the reporting node (reporting to the sender of the request) and it also IS the reacting node (reacting on reports received from the upstream reporting node). >>>>>> The first 3 words of the second sentence "in this case" need clarification: "In the case where an agent takes the role of a reporting node (reporting to the downstream reacting node) and at the same time takes the role of a reacting node (reacting on reports received from an upstream reporting node)". >>>>>> Last sentence: Its not an update but a replacement. The two DOIC associations are handled independently. >>>>> SRD> I don't know what you mean when you say an agent is transparent. >>>>> Agents must take an active role in even the most basic case for >>>>> overload handling to work, so they cannot be transparent. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not support DOIC are transparent. Agents that support DOIC in most cases behave like non supporting agents. >>>> I am towards Ulrich's view here. Even for an agent that understands DOIC it is up to the local policy whether it is transparent or takes an active role. >>>> >>>>>> 5. clause 3.3, last paragraph: >>>>>> General rules shall be followed for each of the two associations separately. The content of the OC-S-F AVP sent by the agent upstream should reflect what the agent is able and willing to support (as always). >>>>> SRD> What two associations? Is there one association (end-to-end) or >>>>> SRD> is >>>>> the an association on both sides of the agent (hop-by-hop)? Or is >>>>> there an association that involves three entities, the reporting node, >>>>> an agent reacting node for realm-routed requests and a >>>>> transaction-client reporting node for handling host-routed requests? >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, There is >>>>> one association between C and A, and one association between A and S. Both associations are "end-to-end" as there may be transparent (supporting or non-supporting) agents in the middle. >>>>>> 6. clause 3.4, 2nd paragraph: >>>>>> Should read: "The OC-OLR AVP is referred to as an overload report. The OC-OLR AVP includes the type of report, a sequence number, the length of time that the report is valid and abatement algorithm specific AVPs." >>>>> SRD> The sequence number is being used as an overload report ID. I can >>>>> make the change but I don't see it as necessary. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. >>>> OK to do the change. >>>> >>>>>> 7. clause 3.4, 4th paragraph, 2nd sentence: >>>>>> I cannot understand this sentence. Probably only simple typos but I don't know. >>>>> SRD> Yes, a typo (this instead of the) and awkward wording. How about >>>>> "This applies to requests that contain the Destination-Host AVP with a >>>>> DiameterIdentity that matches the overload report. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that contain a DiameterIdentity in the Destination-Host AVP that matches the reporting host's DiameterIdentity" >>>> I would be inclined to keep the text Steve proposed. But both are ok actually. >>>> >>>>>> 8. clause 3.4, 4th paragraph last 2 sentences: >>>>>> I don't understand and probably do not agree. >>>>> SRD> See above. >>>>>> 9. clause 3.5, 3rd paragraph, last word: >>>>>> Should read "communicated" >>>>> SRD> Agreed. >>>>>> 10. clause 3.5, 4th paragraph, 1st sentence: >>>>>> I don't understand. I can understand: "Reporting nodes use the OC-OLR AVP to communicate overload occurances towards reacting nodes." >>>>> SRD> Who else would reports be sent to? >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement algorithm but the reporting node that uses the OC-OLR AVP to communicate overload occurances. >>>> Agree. >>>> >>>>>> 11. clause 4.1, 3rd paragraph, last 4 words: >>>>>> may be misleading. A DOIC supporting agent sitting between DOIC supporting client and DOIC supporting Server is transparent with regard to DOIC. This agent does not indicate DOIC support. >>>>> SRD> I disagree. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Should be: ...This agent does not indicate its DOIC support, rather it transparently forwards the client's DOIC support. >>>> Agree with Ulrich on the intent of agent behavior but not with the proposed text change. >>>> >>>>>> 12. clause 4.1, 4th paragraph, 2nd sentence: >>>>>> Should read:"If a request message handled by the DOIC agent does not include the OC-Supported-Features AVP then the DOIC agent inserts the AVP." >>>>> SRD> That is what it already says. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... >>>> OC-Supported-Features can be in both request and answer, thus "If a message" in that sense is correct. >>>> >>>>>> 13. clause 4.1, last sentence: >>>>>> Should read "If the message already has the AVP then the agent either leaves it unchanged in the relayed message or replaces it to reflect the features the agent is able and willing to support." Clarification is needed to say that strict rules must be followed by the agent to select the correct option. These rules take into account whether the request is host-routed or relam-routed and whether the agent is configured to select the server for realm-routed requests. >>>>> SRD> This is a topic on agent behavior that is addressed in the agent >>>>> cases draft. I'll leave the discussion for what the wording should be >>>>> to the discussion on that draft. >>>>>> 14. clause 4.1.2, 2nd paragraph: >>>>>> Should read: "Based on the content of the OC-Supported-Features AVP in the request message, the reporting node knows what overload control functionality is supported by the reacting node. The reporting node then acts accordingly for the subsequent answer messages it initiates for the transaction." >>>>> SRD> It would be easier if you didn't make it difficult to understand >>>>> the change you are proposing. I think you are proposing changing >>>>> node(s) to node. I don't agree but that will be addressed as part of >>>>> the agent cases discussion. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing two sentences? The proposal is to insert "is" between "functionality" and "supported", to add "the" between "by" and "reacting", to replace "node(s)" with "node", and to insert "for the transaction" after "initiates". >>>> Agree with the proposed change. >>>> >>>>>> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >>>>>> Should read: "message's" >>>>> SRD> I'm assuming you mean section 4.1.2. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, and 19. >>>>> I agree to the change. >>>>>> 16. clause 4.1, 6th paragraph: >>>>>> This should be left to the (future) specification that introduces other DOIC features. >>>>>> >>>>>> 17. clause 4.1, 7th paragraph, last 6 words: >>>>>> should be based on requiements set by the (future) specification that >>>>>> introduces other DOIC features >>>>> SRD> Again, clause 4.1.2 -- I don't understand the issue when these >>>>> SRD> two >>>>> paragraphs are taken together. >>>>>> 18. clause 4.1, 8th paragraph, last sentence: >>>>>> Should read: "Lack of the OC-Supported-Features AVP in the request message indicates that there is no downstream reacting node for the transaction." >>>>> SRD> I think you mean clause 4.1.2. I don't see the need for the change. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not correct. It should either read: "Lack of the OC-Supported-Feature AVP in the request message indicates to the reporting node that there is no reacting node for the transaction" or as proposed above. >>>> I don't see a reason for the change. Original text seem correct to me. >>>> >>>>>> 19. clause 4.1, last sentence: >>>>>> Should read: "An agent MAY replace the OC-Supported-Features AVP carried in answer messages." This replacement must follow general rules. Its not so that the agent may do what ever it wants to. The decision must be based on whether or not the agent has replaced the OC-S-F in the corresponding request. >>>>> SRD> What is the difference between modify and replace? I am ok with >>>>> removing this statement until we have the agent behavior discussion. >>>>> I thought I had taken the agent specific statements out of this version. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with identical values. You remove what has been received in and insert your own stuff. >>>> Agent (proxy) can always do that i.e. modify the APV contents. Obviously if an agent tampers the OC-Supported-Features AVP it needs to know what it is doing. In general agree with the clarification but not with the proposed text. >>>> >>>> - Jouni >>>> >>>>>> 20. clause 5.2, 1st sentence: >>>>>> Should read: "A reporting node using the loss algorithm must use the OC-Reduction-Percentage AVP (Section 6.7) to indicated the desired percentage of traffic reduction." >>>>> SRD> Agreed. >>>>>> 21. clause 5.2, last sentence: >>>>>> Should read: "Editor's note: The above duplicates what is in the OC-Reduction-Percentage AVP section and can probably be removed." >>>>> SRD> Yes, bad wording. The note will be removed, bad wording and all, >>>>> once there is a discussion on if this is redundant. >>>>>> 22. clause 5.4, 6th paragraph: >>>>>> Should read: "If the reacting node does not receive a an OLR in the answer that corresponds to the probe request messages sent to the formally overloaded node then the reacting node should slowly increase the rate of traffic sent to the overloaded node." >>>>> SRD Agreed, this is more clear. >>>>>> Best regards >>>>>> Ulrich >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>>> Donovan >>>>>> Sent: Saturday, July 05, 2014 9:42 PM >>>>>> To: dime@ietf.org >>>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>> >>>>>> All, >>>>>> >>>>>> This version of the DOIC draft is a restructuring of previously >>>>>> agreed to content. >>>>>> >>>>>> The master plan for the restructuring is in Appendix C. This >>>>>> outlines where material from -02 was moved in -03. >>>>>> >>>>>> For those interested, the work was done in steps, with a snapshot for >>>>>> each step available here: >>>>>> >>>>>> https://github.com/jounikor/draft-docdt-dime-ovli >>>>>> >>>>>> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >>>>>> >>>>>> where nn indicates the subversion and "text" indicates the focus for >>>>>> that subversion. >>>>>> >>>>>> The next step will be to resolve open issues already identified and >>>>>> those yet those yet to be identified. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>>>> This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. >>>>>>> >>>>>>> Title : Diameter Overload Indication Conveyance >>>>>>> Authors : Jouni Korhonen >>>>>>> Steve Donovan >>>>>>> Ben Campbell >>>>>>> Lionel Morand >>>>>>> Filename : draft-ietf-dime-ovli-03.txt >>>>>>> Pages : 48 >>>>>>> Date : 2014-07-03 >>>>>>> >>>>>>> Abstract: >>>>>>> This specification documents a Diameter Overload Control (DOC) base >>>>>>> solution and the dissemination of the overload report information. >>>>>>> >>>>>>> Requirements >>>>>>> >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>>>>>> >>>>>>> There's also a htmlized version available at: >>>>>>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-03 >>>>>>> >>>>>>> >>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>> submission until the htmlized version and diff are available at tools.ietf.org. >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>> DiME@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Wed Jul 30 06:07:54 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CEB1A0046 for ; Wed, 30 Jul 2014 06:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 X55t6V10-7mP for ; Wed, 30 Jul 2014 06:07:41 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141481A0030 for ; Wed, 30 Jul 2014 06:07:38 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s6UD7WN8028315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Jul 2014 13:07:32 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s6UD7Uwr001058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jul 2014 15:07:30 +0200 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 30 Jul 2014 15:07:30 +0200 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.195]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0195.001; Wed, 30 Jul 2014 15:07:31 +0200 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Jouni Korhonen , ext Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) Thread-Index: AQHPpPA/36IwRToz/kGtAPmPhYVJupuqvVowgAxDloCAACTwUIABSp6AgAAs/qA= Date: Wed, 30 Jul 2014 13:07:30 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668152081C8@DEMUMBX014.nsn-intra.net> References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> <53D7AA31.3070908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520806A@DEMUMBX014.nsn-intra.net> <53D8DE85.5040201@gmail.com> In-Reply-To: <53D8DE85.5040201@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 29715 X-purgate-ID: 151667::1406725652-000005B1-F912E3FB/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/x_vUKXPazDHZv-yS4XnoaEilIno Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 13:07:47 -0000 Jouni, this may be true for server selecting nodes that do not support DOIC. However, when the server selecting node supports DOIC, once the server is s= elected and the abatement (according to a previously received OLR from the = selected server) is performed (e.g. a 30% throttling was survived), you do = not want upstream agents to undo the server selection (as it cannot undo th= e throttling that is associated with the originaly selected server).=20 Therefore I think we should mandate that DOIC supporting nodes that perform= server selection and perform abatement according to reports received from = the selected server make sure that upstream agents do not select another se= rver. Otherwise we end up with a mismatch between performed abatement and e= ventually selected server. Ulrich=20 -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Wednesday, July 30, 2014 2:01 PM To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime= -ovli-03.txt) Few comments inline.. 7/29/2014 6:41 PM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: > Steve, > > It is my understanding that the node (client or agent) which performs ser= ver selection (e.g. selects server S) needs to make sure that any upstream = agent will not undo the selection (e.g. by selecting another server Z). Thi= s can be ensured by inserting a Destination-Host AVP containing S's Diamete= rIdentity to the request. Inserting the Destinatio-Host AVP is not needed w= hen there are no upstream agents i.e. when there is a "direct transport con= nection" to the selected server. The case where the node that selects the s= erver for a realm-routed request has a direct transport connection to the s= elected server is not the general case. > > A DOICable node (client or agent) may face the situation where it has to = send out a realm-routed request. Before sending the request it may detect t= hat it (the node) is configured to perform server selection. The node selec= ts server S. Now (still before sending the request out) the node detects (f= rom checking overload states) that S is overloaded therefore it performs ab= atement (diversion to Z). Now the node may either have a direct transport c= onnection to Z in which case it sends the request to Z (this is the case yo= u covered), or it does not have a direct transport connetion to Z in which = case it inserts the Destination-Host AVP with Z's Diameter Identity and sen= ds the request to the next hop. I have a problem with this. My understanding is that the server=20 selection does not imply intermediate nodes inserting Destination-Host=20 into the request independent there is direct transport connection or=20 not.. Or am I reading the intention of this paragraph wrong? Up to the=20 point the realm routed (Destination-Realm only case) request reaches the=20 "server" it is pure routing & forwarding of the request. The insertion=20 of the Destination-Host is done by the client when it has learned the=20 used server (from the Origin-Host). If the client has the desination=20 host information already it may or may not insert Destination-Host into=20 request.. depending of its needs. - Jouni > > > Ulrich > > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Tuesday, July 29, 2014 4:06 PM > To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org > Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-di= me-ovli-03.txt) > > Ulrich, > > Thanks for the detailed response. I think we are very close to being in > agreement. > > The area I'm not sure about yet is using the wording "A DOIC node that > does server selection" versus "A DOIC node with a direct transport > connection". > > A client might think it is doing server selection even when it is > connecting to an agent. That is why I used the "direct transport > connection" wording to make it more explicit. > > What is the objection to this wording? > > This could also be solved by adding a definition of server selection, > but it would need to be done in a way that also addresses transactions > that flow from a Diameter server to a Diameter client. > > Regards. > > Steve > > On 7/29/14, 2:29 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Steve, >> >> I can agree with most of your statements. >> >> A DOICable agent needs to determine in which scenario it actually is. Th= is decision must be based on presence/absence of OC-S-F-AVP in the received= requests, presence/absence of Destination-Host AVP in the received request= and configuration data (configured to select/not to select the server for = realm routed requests). >> >> Once this decision is taken the agent >> a) inserts an OC-S-F to the request, or >> b) transparently forwards the request (i.e. does not remove or add an OC= -S-F AVP), or >> c) removes the received OC-S-F AVP and inserts its own OC-S-F AVP >> >> note that c) includes the case where the removed AVP and the inserted AV= P are identical. >> >> Case b) is the transparent case where the agent - although it supports D= OIC (and DOIC is not turned off) - from an external point of view behaves l= ike a non-DOICable node. >> >> See also inline. >> >> Regards, >> Ulrich >> (still trying to catch up with lots of mails) >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan >> Sent: Monday, July 21, 2014 4:29 PM >> To: dime@ietf.org >> Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-d= ime-ovli-03.txt) >> >> Ulrich, >> >> I am not arguing that all agents should take an active role in the >> handling of all overload reports. What I am arguing is that there are >> scenarios where an agent must take an active role in DOIC to ensure that >> a requested reduction in traffic an be achieved. >> >> For DOIC to work a carrier cannot turn off all DOIC behavior in agents, >> as suggested by Jouni. >> >> I agree that in your scenario below, a1 does not need to take an active >> role in reducing traffic when c supports DOIC. a1 should take an active >> role when c does not support DOIC. The problem is that a1 does not know >> in advance whether c supports DOIC so it will need to inspect all >> transactions for the presence of OC-S-F to determine if it needs to >> handle overload reports for a non supporting client. >> I agree >> >> Does that mean a1 is transparent if it inspects all requests and does >> nothing in the case where there is c supports DOIC? >> yes >> >> Does transparent mean that there is no observable difference in the DOIC >> AVPs that pass through the agent >> yes or does it mean that there is no >> observable difference in how transactions are handled by the DOIC agent? >> no >> >> I'm guessing that we have multiple assumptions on what transparent means >> and, if we are going to continue saying agents should be transparent >> then we need a definition of transparent. >> >> I think for this use case, we need the following normative statements in >> the draft for handling of abatement of realm-routed requests? I think >> this is general behavior and should go in the section on handling of >> overload reports. >> >> "DOIC nodes with a direct transport connection to a reporting node that >> has an active overload report must handle abatement of realm-routed >> requests. The preferred method for handling abatement of realm-routed >> requests is diversion, where the node with the direct transport >> connection routes the request to an alternative server that is able to >> handle the request. If there is no alternative server with the needed >> capacity to handle the request then the DOIC node must/should throttle >> the necessary requests to meet the requested reduction in traffic." >> My proposal: >> "A DOIC node with performs server selection for realm routed requests th= at >> has active overload reports from servers it potentially selects, must >> handle abatement of realm-routed >> requests. The preferred method for handling abatement of realm-routed >> requests is diversion, where the node selecting the server routes the >> request to an alternative server that is able to >> handle the request. If there is no alternative server with the needed >> capacity to handle the request then the DOIC node must/should preferrabl= y >> delegate abatement (of realm routed requests) towards a downstream react= ing >> node or otherwise throttle >> the necessary requests to meet the requested reduction in traffic." >> >> >> >> If we can agree on this then we can move on to the next agent based use >> case. >> >> Regards, >> >> Steve >> >> On 7/21/14, 9:47 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>> Steve, >>> >>> The example you show is absolutely valid and 100% inline with A) to F) = - (assuming that all servers can serve any request). >>> However, there are other scenarios like: >>> >>> >>> >>> +--+ >>> /--|s1| >>> +-+ +--+ +--+ / +--+ >>> |c|--- |a1|--|a2|=3D=3D ... >>> +-+ +--+ +--+ \ +--+ >>> \--|sn| >>> +--+ >>> >>> Here I think a1 should be transparent even when DOICable. >>> a1 does not take the role of a reacting node since c supports DOIC. >>> a1 does not perform server selection and therefore does not take the ro= le of a reporting node (for realm-reports). >>> >>> Ulrich >>> >>> >>> -----Original Message----- >>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] >>> Sent: Monday, July 21, 2014 3:16 PM >>> To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munic= h); dime@ietf.org >>> Subject: Transparent agents (was Re: [Dime] I-D Action: draft-ietf-dime= -ovli-03.txt) >>> >>> Ok, let's see if it's possible to completely turn off all DOIC behavior >>> in agents and still be able to reduce traffic to a server that sends a >>> host overload report. >>> >>> Assume the following agent based deployment: >>> >>> +--+ >>> /--|s1| >>> +-+ +-+ / +--+ >>> |c|--|a|=3D=3D ... >>> +-+ +-+ \ +--+ >>> \--|sn| >>> +--+ >>> >>> Assume that there is a large number of servers, say 50. >>> >>> Now, assume that the Diameter application in question exclusively uses >>> realm-routed requests - 100% of requests sent by the client do NOT have >>> a destination-host AVP. >>> >>> Now assume that server s1 sends an host type overload report requesting >>> a reduction of 20% using the loss algorithm. >>> >>> Also assume that the unused capacity in servers s2 through s50 is >>> sufficient to handle the traffic that would have been sent to s1. As >>> such, there is no reason to throttle any requests. >>> >>> There are no host routed requests for this application and the client >>> does not have a direct transport connection to server s1. The only >>> option a client has is to hand the request off to the agent for routing= . >>> >>> The proposal in the agent cases draft is that the agent diverts 20% of >>> the realm routed requests that would have been sent to server s1 to >>> servers s2 through s50. >>> >>> If DOIC behavior is turned off in the agent then how will the traffic >>> routed to s1 be reduced? >>> >>> Steve >>> >>> On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote: >>>> +1 for the following aspect. >>>> >>>>>>> Agents must take an active role in even the most basic case for >>>>>>> overload handling to work, so they cannot be transparent. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not= support DOIC are transparent. Agents that support DOIC in most cases behav= e like non supporting agents. >>>>> I am towards Ulrich's view here. Even for an agent that understands D= OIC it is up to the local policy whether it is transparent or takes an acti= ve role. >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >>>> Sent: Monday, July 21, 2014 12:26 AM >>>> To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org >>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>> >>>> Some comments inline.. >>>> >>>> 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >>>>> Steve, >>>>> please see my response inline. >>>>> >>>>> Regards >>>>> Ulrich >>>>> >>>>> -----Original Message----- >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>> Donovan >>>>> Sent: Tuesday, July 15, 2014 3:53 PM >>>>> To: dime@ietf.org >>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>> >>>>> Ulrich, >>>>> >>>>> Thanks for the comments. Please see my responses inline. >>>>> >>>>> Regards, >>>>> >>>>> Steve >>>>> On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>>>> Hi Steve, >>>>>> here are my comments. >>>>>> They focus on new text you introduced. I agree that restructuring ma= y require new text, however, I believe that with the new text a new concept= s is introduced which macerates the agreed end-to-end concept and allows al= l DOIC agents on the path to do what they wants, so that we end up in a hop= -by-hop concept. >>>>> SRD> We have never had an agreement on end-to-end versus hop-by-hop >>>>> SRD> and >>>>> I believe that we will end up with a hybrid of the two. We have open >>>>> issues on agent behavior that Ben and I are attempting to address wit= h >>>>> the agent cases draft. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop appro= ach of the roach draft was reason not to proceed with that draft. >>>>> >>>>> SRD> That said, this type of restructuring of the document is likely >>>>> SRD> to >>>>> put agreed to behavior in a new light. If there are cases where I >>>>> have implied changes to agreed to normative behavior, or if the >>>>> informative text is not accurate, then these things need to be correc= ted. >>>>>> 1. clause 2.3, second paragraph: >>>>>> Should read: "Reacting nodes indicate support for DOIC by including = the OC-Supported-Features AVP into all request messages originated or relay= ed by the Reacting node." >>>>> SRD> You mean clause 3.2. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes >>>>> I agree with the change. >>>>>> 2. clause 2.3, 3rd paragraph, 1st sentence: >>>>>> OC-xxx AVPs must not be included in an answer message when the corre= sponding request did not contain an OC-S-F AVP. >>>>> SRD> Agreed. >>>>>> 3. clause 3.3, 7th paragraph: >>>>>> Should read "The reporting node only includes an indication of suppo= rt for one overload abatement algorithm. This is the algorithm that the re= porting node intends to use should it enter an overload condition or reques= ts to use while it actually is in an overload condition. Reacting nodes can= use the indicated overload abatement algorithm to prepare for possible ove= rload reports and must use the indicated overload abatement algorithm if tr= affic reduction is actually requested." >>>>> SRD. OK. >>>>>> 4. clause 3.3, 10th paragraph: >>>>>> The 1st sentence is misleading. In the general case, agents on the p= ath between reacting node and reporting node are transparent. I agree that = there are exceptions to the general case where an agent on the path is not = transparent, but then the agent IS the reporting node (reporting to the sen= der of the request) and it also IS the reacting node (reacting on reports r= eceived from the upstream reporting node). >>>>>> The first 3 words of the second sentence "in this case" need clarifi= cation: "In the case where an agent takes the role of a reporting node (rep= orting to the downstream reacting node) and at the same time takes the role= of a reacting node (reacting on reports received from an upstream reportin= g node)". >>>>>> Last sentence: Its not an update but a replacement. The two DOIC ass= ociations are handled independently. >>>>> SRD> I don't know what you mean when you say an agent is transparent. >>>>> Agents must take an active role in even the most basic case for >>>>> overload handling to work, so they cannot be transparent. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not = support DOIC are transparent. Agents that support DOIC in most cases behave= like non supporting agents. >>>> I am towards Ulrich's view here. Even for an agent that understands DO= IC it is up to the local policy whether it is transparent or takes an activ= e role. >>>> >>>>>> 5. clause 3.3, last paragraph: >>>>>> General rules shall be followed for each of the two associations sep= arately. The content of the OC-S-F AVP sent by the agent upstream should re= flect what the agent is able and willing to support (as always). >>>>> SRD> What two associations? Is there one association (end-to-end) or >>>>> SRD> is >>>>> the an association on both sides of the agent (hop-by-hop)? Or is >>>>> there an association that involves three entities, the reporting node= , >>>>> an agent reacting node for realm-routed requests and a >>>>> transaction-client reporting node for handling host-routed requests? >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, There i= s >>>>> one association between C and A, and one association between A and S.= Both associations are "end-to-end" as there may be transparent (supporting= or non-supporting) agents in the middle. >>>>>> 6. clause 3.4, 2nd paragraph: >>>>>> Should read: "The OC-OLR AVP is referred to as an overload report. = The OC-OLR AVP includes the type of report, a sequence number, the length o= f time that the report is valid and abatement algorithm specific AVPs." >>>>> SRD> The sequence number is being used as an overload report ID. I ca= n >>>>> make the change but I don't see it as necessary. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. >>>> OK to do the change. >>>> >>>>>> 7. clause 3.4, 4th paragraph, 2nd sentence: >>>>>> I cannot understand this sentence. Probably only simple typos but I = don't know. >>>>> SRD> Yes, a typo (this instead of the) and awkward wording. How abou= t >>>>> "This applies to requests that contain the Destination-Host AVP with = a >>>>> DiameterIdentity that matches the overload report. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that con= tain a DiameterIdentity in the Destination-Host AVP that matches the report= ing host's DiameterIdentity" >>>> I would be inclined to keep the text Steve proposed. But both are ok a= ctually. >>>> >>>>>> 8. clause 3.4, 4th paragraph last 2 sentences: >>>>>> I don't understand and probably do not agree. >>>>> SRD> See above. >>>>>> 9. clause 3.5, 3rd paragraph, last word: >>>>>> Should read "communicated" >>>>> SRD> Agreed. >>>>>> 10. clause 3.5, 4th paragraph, 1st sentence: >>>>>> I don't understand. I can understand: "Reporting nodes use the OC-OL= R AVP to communicate overload occurances towards reacting nodes." >>>>> SRD> Who else would reports be sent to? >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement algo= rithm but the reporting node that uses the OC-OLR AVP to communicate overlo= ad occurances. >>>> Agree. >>>> >>>>>> 11. clause 4.1, 3rd paragraph, last 4 words: >>>>>> may be misleading. A DOIC supporting agent sitting between DOIC supp= orting client and DOIC supporting Server is transparent with regard to DOIC= . This agent does not indicate DOIC support. >>>>> SRD> I disagree. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Sho= uld be: ...This agent does not indicate its DOIC support, rather it transpa= rently forwards the client's DOIC support. >>>> Agree with Ulrich on the intent of agent behavior but not with the pro= posed text change. >>>> >>>>>> 12. clause 4.1, 4th paragraph, 2nd sentence: >>>>>> Should read:"If a request message handled by the DOIC agent does not= include the OC-Supported-Features AVP then the DOIC agent inserts the AVP.= " >>>>> SRD> That is what it already says. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... >>>> OC-Supported-Features can be in both request and answer, thus "If a me= ssage" in that sense is correct. >>>> >>>>>> 13. clause 4.1, last sentence: >>>>>> Should read "If the message already has the AVP then the agent eithe= r leaves it unchanged in the relayed message or replaces it to reflect the = features the agent is able and willing to support." Clarification is needed= to say that strict rules must be followed by the agent to select the corre= ct option. These rules take into account whether the request is host-routed= or relam-routed and whether the agent is configured to select the server f= or realm-routed requests. >>>>> SRD> This is a topic on agent behavior that is addressed in the agent >>>>> cases draft. I'll leave the discussion for what the wording should b= e >>>>> to the discussion on that draft. >>>>>> 14. clause 4.1.2, 2nd paragraph: >>>>>> Should read: "Based on the content of the OC-Supported-Features AVP = in the request message, the reporting node knows what overload control func= tionality is supported by the reacting node. The reporting node then acts = accordingly for the subsequent answer messages it initiates for the transac= tion." >>>>> SRD> It would be easier if you didn't make it difficult to understand >>>>> the change you are proposing. I think you are proposing changing >>>>> node(s) to node. I don't agree but that will be addressed as part of >>>>> the agent cases discussion. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing tw= o sentences? The proposal is to insert "is" between "functionality" and "su= pported", to add "the" between "by" and "reacting", to replace "node(s)" wi= th "node", and to insert "for the transaction" after "initiates". >>>> Agree with the proposed change. >>>> >>>>>> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >>>>>> Should read: "message's" >>>>> SRD> I'm assuming you mean section 4.1.2. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, = and 19. >>>>> I agree to the change. >>>>>> 16. clause 4.1, 6th paragraph: >>>>>> This should be left to the (future) specification that introduces ot= her DOIC features. >>>>>> >>>>>> 17. clause 4.1, 7th paragraph, last 6 words: >>>>>> should be based on requiements set by the (future) specification tha= t >>>>>> introduces other DOIC features >>>>> SRD> Again, clause 4.1.2 -- I don't understand the issue when these >>>>> SRD> two >>>>> paragraphs are taken together. >>>>>> 18. clause 4.1, 8th paragraph, last sentence: >>>>>> Should read: "Lack of the OC-Supported-Features AVP in the request m= essage indicates that there is no downstream reacting node for the transact= ion." >>>>> SRD> I think you mean clause 4.1.2. I don't see the need for the cha= nge. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not co= rrect. It should either read: "Lack of the OC-Supported-Feature AVP in the = request message indicates to the reporting node that there is no reacting n= ode for the transaction" or as proposed above. >>>> I don't see a reason for the change. Original text seem correct to me. >>>> >>>>>> 19. clause 4.1, last sentence: >>>>>> Should read: "An agent MAY replace the OC-Supported-Features AVP car= ried in answer messages." This replacement must follow general rules. Its n= ot so that the agent may do what ever it wants to. The decision must be bas= ed on whether or not the agent has replaced the OC-S-F in the corresponding= request. >>>>> SRD> What is the difference between modify and replace? I am ok with >>>>> removing this statement until we have the agent behavior discussion. >>>>> I thought I had taken the agent specific statements out of this versi= on. >>>>> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with identi= cal values. You remove what has been received in and insert your own stuff. >>>> Agent (proxy) can always do that i.e. modify the APV contents. Obvious= ly if an agent tampers the OC-Supported-Features AVP it needs to know what = it is doing. In general agree with the clarification but not with the propo= sed text. >>>> >>>> - Jouni >>>> >>>>>> 20. clause 5.2, 1st sentence: >>>>>> Should read: "A reporting node using the loss algorithm must use the= OC-Reduction-Percentage AVP (Section 6.7) to indicated the desired percent= age of traffic reduction." >>>>> SRD> Agreed. >>>>>> 21. clause 5.2, last sentence: >>>>>> Should read: "Editor's note: The above duplicates what is in the OC-= Reduction-Percentage AVP section and can probably be removed." >>>>> SRD> Yes, bad wording. The note will be removed, bad wording and all= , >>>>> once there is a discussion on if this is redundant. >>>>>> 22. clause 5.4, 6th paragraph: >>>>>> Should read: "If the reacting node does not receive a an OLR in the = answer that corresponds to the probe request messages sent to the formally = overloaded node then the reacting node should slowly increase the rate of t= raffic sent to the overloaded node." >>>>> SRD Agreed, this is more clear. >>>>>> Best regards >>>>>> Ulrich >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>>> Donovan >>>>>> Sent: Saturday, July 05, 2014 9:42 PM >>>>>> To: dime@ietf.org >>>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>> >>>>>> All, >>>>>> >>>>>> This version of the DOIC draft is a restructuring of previously >>>>>> agreed to content. >>>>>> >>>>>> The master plan for the restructuring is in Appendix C. This >>>>>> outlines where material from -02 was moved in -03. >>>>>> >>>>>> For those interested, the work was done in steps, with a snapshot fo= r >>>>>> each step available here: >>>>>> >>>>>> https://github.com/jounikor/draft-docdt-dime-ovli >>>>>> >>>>>> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >>>>>> >>>>>> where nn indicates the subversion and "text" indicates the focus for >>>>>> that subversion. >>>>>> >>>>>> The next step will be to resolve open issues already identified and >>>>>> those yet those yet to be identified. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Steve >>>>>> >>>>>> >>>>>> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>>>>> This draft is a work item of the Diameter Maintenance and E= xtensions Working Group of the IETF. >>>>>>> >>>>>>> Title : Diameter Overload Indication Conve= yance >>>>>>> Authors : Jouni Korhonen >>>>>>> Steve Donovan >>>>>>> Ben Campbell >>>>>>> Lionel Morand >>>>>>> Filename : draft-ietf-dime-ovli-03.txt >>>>>>> Pages : 48 >>>>>>> Date : 2014-07-03 >>>>>>> >>>>>>> Abstract: >>>>>>> This specification documents a Diameter Overload Control = (DOC) base >>>>>>> solution and the dissemination of the overload report inf= ormation. >>>>>>> >>>>>>> Requirements >>>>>>> >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>>>>>> >>>>>>> There's also a htmlized version available at: >>>>>>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-ovli-03 >>>>>>> >>>>>>> >>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>> submission until the htmlized version and diff are available at too= ls.ietf.org. >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>> DiME@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Wed Jul 30 06:36:52 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125491A005C for ; Wed, 30 Jul 2014 06:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 6sd5LkmY3dPL for ; Wed, 30 Jul 2014 06:36:46 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3755E1A0030 for ; Wed, 30 Jul 2014 06:36:45 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id hz20so904301lab.27 for ; Wed, 30 Jul 2014 06:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dAgE6yC921amTq8JjX0P9Yg2IJvhoLHp4UhIAxSpOJ4=; b=chS1eFx6Mvboe+wvhblLC7H/d9D/LGhSC4qHoVQbDPWtXu9hIgdrrpIZkjBpTuAePI gftzVMPERmvGLttQYOsg4YBzvjIWNQNaoXQfaSmGq3Vnwskfvt3sx6v9r6zPnXiRNWXb kozkAOb0+81bIBfEP1QApQO3gIYTQUDaugVhKtRLWgFWGvo2IXLGsjkKJHlJn+ZlRRY4 Qm4ZKE9god5OcajU4vpmW1vQPODH3G3Wmzgt9YyveXeZagQmOuNkhQr9wRs4W6GiCFDU rzL1R0CW1oZUGf84gB9eDTwU3+UUG+ST3DbhRaS1Bl05EbwWflPHblhcf+BEJZr2PSxy FWYg== X-Received: by 10.152.7.70 with SMTP id h6mr3892556laa.96.1406727403358; Wed, 30 Jul 2014 06:36:43 -0700 (PDT) Received: from [10.37.148.49] ([77.95.242.69]) by mx.google.com with ESMTPSA id a17sm3484571lbh.45.2014.07.30.06.36.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 06:36:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jouni X-Mailer: iPhone Mail (11D201) In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668152081C8@DEMUMBX014.nsn-intra.net> Date: Wed, 30 Jul 2014 16:36:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> <53D7AA31.3070908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520806A@DEMUMBX014.nsn-intra.net> <53D8DE85.5040201@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668152081C8@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qLvg-uSbQ9WZ2OU-8gj7SYTA61Y Cc: "dime@ietf.org" Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 13:36:51 -0000 Ulrich, I have no problem with DOICable node doing routing/forwarding based on load w= hatever. But I have an issue an intermediate node adding Destination-Host in= to a request when the client did not originally insert one. I am a bit cauti= ous that an agent next to a server can be overruled by other agents when sel= ecting the server. While this all is still within RFC6733 boundaries it is s= omewhat different than in RFC6733. That's why I have concerns with this.=20 Jouni --=20 Jouni Korhonen Broadcom (Sent from my mobile..) > "Wiehe, Ulrich (NSN - DE/Munich)" kirjoitti 30.7.20= 14 kello 16.07: >=20 > Jouni, >=20 > this may be true for server selecting nodes that do not support DOIC. >=20 > However, when the server selecting node supports DOIC, once the server is s= elected and the abatement (according to a previously received OLR from the s= elected server) is performed (e.g. a 30% throttling was survived), you do no= t want upstream agents to undo the server selection (as it cannot undo the t= hrottling that is associated with the originaly selected server).=20 > Therefore I think we should mandate that DOIC supporting nodes that perfor= m server selection and perform abatement according to reports received from t= he selected server make sure that upstream agents do not select another serv= er. Otherwise we end up with a mismatch between performed abatement and even= tually selected server. >=20 > Ulrich=20 >=20 > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Wednesday, July 30, 2014 2:01 PM > To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org > Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dim= e-ovli-03.txt) >=20 > Few comments inline.. >=20 > 7/29/2014 6:41 PM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >> Steve, >>=20 >> It is my understanding that the node (client or agent) which performs ser= ver selection (e.g. selects server S) needs to make sure that any upstream a= gent will not undo the selection (e.g. by selecting another server Z). This c= an be ensured by inserting a Destination-Host AVP containing S's DiameterIde= ntity to the request. Inserting the Destinatio-Host AVP is not needed when t= here are no upstream agents i.e. when there is a "direct transport connectio= n" to the selected server. The case where the node that selects the server f= or a realm-routed request has a direct transport connection to the selected s= erver is not the general case. >>=20 >> A DOICable node (client or agent) may face the situation where it has to s= end out a realm-routed request. Before sending the request it may detect tha= t it (the node) is configured to perform server selection. The node selects s= erver S. Now (still before sending the request out) the node detects (from c= hecking overload states) that S is overloaded therefore it performs abatemen= t (diversion to Z). Now the node may either have a direct transport connecti= on to Z in which case it sends the request to Z (this is the case you covere= d), or it does not have a direct transport connetion to Z in which case it i= nserts the Destination-Host AVP with Z's Diameter Identity and sends the req= uest to the next hop. >=20 > I have a problem with this. My understanding is that the server=20 > selection does not imply intermediate nodes inserting Destination-Host=20 > into the request independent there is direct transport connection or=20 > not.. Or am I reading the intention of this paragraph wrong? Up to the=20 > point the realm routed (Destination-Realm only case) request reaches the=20= > "server" it is pure routing & forwarding of the request. The insertion=20 > of the Destination-Host is done by the client when it has learned the=20 > used server (from the Origin-Host). If the client has the desination=20 > host information already it may or may not insert Destination-Host into=20= > request.. depending of its needs. >=20 > - Jouni >=20 >=20 >=20 >>=20 >>=20 >> Ulrich >>=20 >>=20 >> -----Original Message----- >> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Tuesday, July 29, 2014 4:06 PM >> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org >> Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-di= me-ovli-03.txt) >>=20 >> Ulrich, >>=20 >> Thanks for the detailed response. I think we are very close to being in >> agreement. >>=20 >> The area I'm not sure about yet is using the wording "A DOIC node that >> does server selection" versus "A DOIC node with a direct transport >> connection". >>=20 >> A client might think it is doing server selection even when it is >> connecting to an agent. That is why I used the "direct transport >> connection" wording to make it more explicit. >>=20 >> What is the objection to this wording? >>=20 >> This could also be solved by adding a definition of server selection, >> but it would need to be done in a way that also addresses transactions >> that flow from a Diameter server to a Diameter client. >>=20 >> Regards. >>=20 >> Steve >>=20 >>> On 7/29/14, 2:29 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>> Steve, >>>=20 >>> I can agree with most of your statements. >>>=20 >>> A DOICable agent needs to determine in which scenario it actually is. Th= is decision must be based on presence/absence of OC-S-F-AVP in the received r= equests, presence/absence of Destination-Host AVP in the received request an= d configuration data (configured to select/not to select the server for real= m routed requests). >>>=20 >>> Once this decision is taken the agent >>> a) inserts an OC-S-F to the request, or >>> b) transparently forwards the request (i.e. does not remove or add an OC= -S-F AVP), or >>> c) removes the received OC-S-F AVP and inserts its own OC-S-F AVP >>>=20 >>> note that c) includes the case where the removed AVP and the inserted AV= P are identical. >>>=20 >>> Case b) is the transparent case where the agent - although it supports D= OIC (and DOIC is not turned off) - from an external point of view behaves li= ke a non-DOICable node. >>>=20 >>> See also inline. >>>=20 >>> Regards, >>> Ulrich >>> (still trying to catch up with lots of mails) >>>=20 >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan= >>> Sent: Monday, July 21, 2014 4:29 PM >>> To: dime@ietf.org >>> Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-d= ime-ovli-03.txt) >>>=20 >>> Ulrich, >>>=20 >>> I am not arguing that all agents should take an active role in the >>> handling of all overload reports. What I am arguing is that there are >>> scenarios where an agent must take an active role in DOIC to ensure that= >>> a requested reduction in traffic an be achieved. >>>=20 >>> For DOIC to work a carrier cannot turn off all DOIC behavior in agents, >>> as suggested by Jouni. >>>=20 >>> I agree that in your scenario below, a1 does not need to take an active >>> role in reducing traffic when c supports DOIC. a1 should take an active= >>> role when c does not support DOIC. The problem is that a1 does not know= >>> in advance whether c supports DOIC so it will need to inspect all >>> transactions for the presence of OC-S-F to determine if it needs to >>> handle overload reports for a non supporting client. >>> I agree >>>=20 >>> Does that mean a1 is transparent if it inspects all requests and does >>> nothing in the case where there is c supports DOIC? >>> yes >>>=20 >>> Does transparent mean that there is no observable difference in the DOIC= >>> AVPs that pass through the agent >>> yes or does it mean that there is no >>> observable difference in how transactions are handled by the DOIC agent?= >>> no >>>=20 >>> I'm guessing that we have multiple assumptions on what transparent means= >>> and, if we are going to continue saying agents should be transparent >>> then we need a definition of transparent. >>>=20 >>> I think for this use case, we need the following normative statements in= >>> the draft for handling of abatement of realm-routed requests? I think >>> this is general behavior and should go in the section on handling of >>> overload reports. >>>=20 >>> "DOIC nodes with a direct transport connection to a reporting node that >>> has an active overload report must handle abatement of realm-routed >>> requests. The preferred method for handling abatement of realm-routed >>> requests is diversion, where the node with the direct transport >>> connection routes the request to an alternative server that is able to >>> handle the request. If there is no alternative server with the needed >>> capacity to handle the request then the DOIC node must/should throttle >>> the necessary requests to meet the requested reduction in traffic." >>> My proposal: >>> "A DOIC node with performs server selection for realm routed requests th= at >>> has active overload reports from servers it potentially selects, must >>> handle abatement of realm-routed >>> requests. The preferred method for handling abatement of realm-routed >>> requests is diversion, where the node selecting the server routes the >>> request to an alternative server that is able to >>> handle the request. If there is no alternative server with the needed >>> capacity to handle the request then the DOIC node must/should preferrabl= y >>> delegate abatement (of realm routed requests) towards a downstream react= ing >>> node or otherwise throttle >>> the necessary requests to meet the requested reduction in traffic." >>> >>>=20 >>>=20 >>> If we can agree on this then we can move on to the next agent based use >>> case. >>>=20 >>> Regards, >>>=20 >>> Steve >>>=20 >>>> On 7/21/14, 9:47 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>> Steve, >>>>=20 >>>> The example you show is absolutely valid and 100% inline with A) to F) -= (assuming that all servers can serve any request). >>>> However, there are other scenarios like: >>>>=20 >>>>=20 >>>>=20 >>>> +--+ >>>> /--|s1| >>>> +-+ +--+ +--+ / +--+ >>>> |c|--- |a1|--|a2|=3D=3D ... >>>> +-+ +--+ +--+ \ +--+ >>>> \--|sn| >>>> +--+ >>>>=20 >>>> Here I think a1 should be transparent even when DOICable. >>>> a1 does not take the role of a reacting node since c supports DOIC. >>>> a1 does not perform server selection and therefore does not take the ro= le of a reporting node (for realm-reports). >>>>=20 >>>> Ulrich >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] >>>> Sent: Monday, July 21, 2014 3:16 PM >>>> To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Munic= h); dime@ietf.org >>>> Subject: Transparent agents (was Re: [Dime] I-D Action: draft-ietf-dime= -ovli-03.txt) >>>>=20 >>>> Ok, let's see if it's possible to completely turn off all DOIC behavior= >>>> in agents and still be able to reduce traffic to a server that sends a >>>> host overload report. >>>>=20 >>>> Assume the following agent based deployment: >>>>=20 >>>> +--+ >>>> /--|s1| >>>> +-+ +-+ / +--+ >>>> |c|--|a|=3D=3D ... >>>> +-+ +-+ \ +--+ >>>> \--|sn| >>>> +--+ >>>>=20 >>>> Assume that there is a large number of servers, say 50. >>>>=20 >>>> Now, assume that the Diameter application in question exclusively uses >>>> realm-routed requests - 100% of requests sent by the client do NOT have= >>>> a destination-host AVP. >>>>=20 >>>> Now assume that server s1 sends an host type overload report requesting= >>>> a reduction of 20% using the loss algorithm. >>>>=20 >>>> Also assume that the unused capacity in servers s2 through s50 is >>>> sufficient to handle the traffic that would have been sent to s1. As >>>> such, there is no reason to throttle any requests. >>>>=20 >>>> There are no host routed requests for this application and the client >>>> does not have a direct transport connection to server s1. The only >>>> option a client has is to hand the request off to the agent for routing= . >>>>=20 >>>> The proposal in the agent cases draft is that the agent diverts 20% of >>>> the realm routed requests that would have been sent to server s1 to >>>> servers s2 through s50. >>>>=20 >>>> If DOIC behavior is turned off in the agent then how will the traffic >>>> routed to s1 be reduced? >>>>=20 >>>> Steve >>>>=20 >>>>> On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote: >>>>> +1 for the following aspect. >>>>>=20 >>>>>>>> Agents must take an active role in even the most basic case for >>>>>>>> overload handling to work, so they cannot be transparent. >>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not= support DOIC are transparent. Agents that support DOIC in most cases behave= like non supporting agents. >>>>>> I am towards Ulrich's view here. Even for an agent that understands D= OIC it is up to the local policy whether it is transparent or takes an activ= e role. >>>>> -----Original Message----- >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >>>>> Sent: Monday, July 21, 2014 12:26 AM >>>>> To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org >>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>=20 >>>>> Some comments inline.. >>>>>=20 >>>>> 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >>>>>> Steve, >>>>>> please see my response inline. >>>>>>=20 >>>>>> Regards >>>>>> Ulrich >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>>> Donovan >>>>>> Sent: Tuesday, July 15, 2014 3:53 PM >>>>>> To: dime@ietf.org >>>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>>=20 >>>>>> Ulrich, >>>>>>=20 >>>>>> Thanks for the comments. Please see my responses inline. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Steve >>>>>>> On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>>>>> Hi Steve, >>>>>>> here are my comments. >>>>>>> They focus on new text you introduced. I agree that restructuring ma= y require new text, however, I believe that with the new text a new concepts= is introduced which macerates the agreed end-to-end concept and allows all D= OIC agents on the path to do what they wants, so that we end up in a hop-by-= hop concept. >>>>>> SRD> We have never had an agreement on end-to-end versus hop-by-hop >>>>>> SRD> and >>>>>> I believe that we will end up with a hybrid of the two. We have open= >>>>>> issues on agent behavior that Ben and I are attempting to address wit= h >>>>>> the agent cases draft. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop appro= ach of the roach draft was reason not to proceed with that draft. >>>>>>=20 >>>>>> SRD> That said, this type of restructuring of the document is likely >>>>>> SRD> to >>>>>> put agreed to behavior in a new light. If there are cases where I >>>>>> have implied changes to agreed to normative behavior, or if the >>>>>> informative text is not accurate, then these things need to be correc= ted. >>>>>>> 1. clause 2.3, second paragraph: >>>>>>> Should read: "Reacting nodes indicate support for DOIC by including t= he OC-Supported-Features AVP into all request messages originated or relayed= by the Reacting node." >>>>>> SRD> You mean clause 3.2. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes >>>>>> I agree with the change. >>>>>>> 2. clause 2.3, 3rd paragraph, 1st sentence: >>>>>>> OC-xxx AVPs must not be included in an answer message when the corre= sponding request did not contain an OC-S-F AVP. >>>>>> SRD> Agreed. >>>>>>> 3. clause 3.3, 7th paragraph: >>>>>>> Should read "The reporting node only includes an indication of suppo= rt for one overload abatement algorithm. This is the algorithm that the rep= orting node intends to use should it enter an overload condition or requests= to use while it actually is in an overload condition. Reacting nodes can us= e the indicated overload abatement algorithm to prepare for possible overloa= d reports and must use the indicated overload abatement algorithm if traffic= reduction is actually requested." >>>>>> SRD. OK. >>>>>>> 4. clause 3.3, 10th paragraph: >>>>>>> The 1st sentence is misleading. In the general case, agents on the p= ath between reacting node and reporting node are transparent. I agree that t= here are exceptions to the general case where an agent on the path is not tr= ansparent, but then the agent IS the reporting node (reporting to the sender= of the request) and it also IS the reacting node (reacting on reports recei= ved from the upstream reporting node). >>>>>>> The first 3 words of the second sentence "in this case" need clarifi= cation: "In the case where an agent takes the role of a reporting node (repo= rting to the downstream reacting node) and at the same time takes the role o= f a reacting node (reacting on reports received from an upstream reporting n= ode)". >>>>>>> Last sentence: Its not an update but a replacement. The two DOIC ass= ociations are handled independently. >>>>>> SRD> I don't know what you mean when you say an agent is transparent.= >>>>>> Agents must take an active role in even the most basic case for >>>>>> overload handling to work, so they cannot be transparent. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not s= upport DOIC are transparent. Agents that support DOIC in most cases behave l= ike non supporting agents. >>>>> I am towards Ulrich's view here. Even for an agent that understands DO= IC it is up to the local policy whether it is transparent or takes an active= role. >>>>>=20 >>>>>>> 5. clause 3.3, last paragraph: >>>>>>> General rules shall be followed for each of the two associations sep= arately. The content of the OC-S-F AVP sent by the agent upstream should ref= lect what the agent is able and willing to support (as always). >>>>>> SRD> What two associations? Is there one association (end-to-end) or= >>>>>> SRD> is >>>>>> the an association on both sides of the agent (hop-by-hop)? Or is >>>>>> there an association that involves three entities, the reporting node= , >>>>>> an agent reacting node for realm-routed requests and a >>>>>> transaction-client reporting node for handling host-routed requests? >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, There i= s >>>>>> one association between C and A, and one association between A and S.= Both associations are "end-to-end" as there may be transparent (supporting o= r non-supporting) agents in the middle. >>>>>>> 6. clause 3.4, 2nd paragraph: >>>>>>> Should read: "The OC-OLR AVP is referred to as an overload report. T= he OC-OLR AVP includes the type of report, a sequence number, the length of t= ime that the report is valid and abatement algorithm specific AVPs." >>>>>> SRD> The sequence number is being used as an overload report ID. I ca= n >>>>>> make the change but I don't see it as necessary. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. >>>>> OK to do the change. >>>>>=20 >>>>>>> 7. clause 3.4, 4th paragraph, 2nd sentence: >>>>>>> I cannot understand this sentence. Probably only simple typos but I d= on't know. >>>>>> SRD> Yes, a typo (this instead of the) and awkward wording. How abou= t >>>>>> "This applies to requests that contain the Destination-Host AVP with a= >>>>>> DiameterIdentity that matches the overload report. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that con= tain a DiameterIdentity in the Destination-Host AVP that matches the reporti= ng host's DiameterIdentity" >>>>> I would be inclined to keep the text Steve proposed. But both are ok a= ctually. >>>>>=20 >>>>>>> 8. clause 3.4, 4th paragraph last 2 sentences: >>>>>>> I don't understand and probably do not agree. >>>>>> SRD> See above. >>>>>>> 9. clause 3.5, 3rd paragraph, last word: >>>>>>> Should read "communicated" >>>>>> SRD> Agreed. >>>>>>> 10. clause 3.5, 4th paragraph, 1st sentence: >>>>>>> I don't understand. I can understand: "Reporting nodes use the OC-OL= R AVP to communicate overload occurances towards reacting nodes." >>>>>> SRD> Who else would reports be sent to? >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement algo= rithm but the reporting node that uses the OC-OLR AVP to communicate overloa= d occurances. >>>>> Agree. >>>>>=20 >>>>>>> 11. clause 4.1, 3rd paragraph, last 4 words: >>>>>>> may be misleading. A DOIC supporting agent sitting between DOIC supp= orting client and DOIC supporting Server is transparent with regard to DOIC.= This agent does not indicate DOIC support. >>>>>> SRD> I disagree. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Sho= uld be: ...This agent does not indicate its DOIC support, rather it transpar= ently forwards the client's DOIC support. >>>>> Agree with Ulrich on the intent of agent behavior but not with the pro= posed text change. >>>>>=20 >>>>>>> 12. clause 4.1, 4th paragraph, 2nd sentence: >>>>>>> Should read:"If a request message handled by the DOIC agent does not= include the OC-Supported-Features AVP then the DOIC agent inserts the AVP."= >>>>>> SRD> That is what it already says. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... >>>>> OC-Supported-Features can be in both request and answer, thus "If a me= ssage" in that sense is correct. >>>>>=20 >>>>>>> 13. clause 4.1, last sentence: >>>>>>> Should read "If the message already has the AVP then the agent eithe= r leaves it unchanged in the relayed message or replaces it to reflect the f= eatures the agent is able and willing to support." Clarification is needed t= o say that strict rules must be followed by the agent to select the correct o= ption. These rules take into account whether the request is host-routed or r= elam-routed and whether the agent is configured to select the server for rea= lm-routed requests. >>>>>> SRD> This is a topic on agent behavior that is addressed in the agent= >>>>>> cases draft. I'll leave the discussion for what the wording should b= e >>>>>> to the discussion on that draft. >>>>>>> 14. clause 4.1.2, 2nd paragraph: >>>>>>> Should read: "Based on the content of the OC-Supported-Features AVP i= n the request message, the reporting node knows what overload control functi= onality is supported by the reacting node. The reporting node then acts acc= ordingly for the subsequent answer messages it initiates for the transaction= ." >>>>>> SRD> It would be easier if you didn't make it difficult to understand= >>>>>> the change you are proposing. I think you are proposing changing >>>>>> node(s) to node. I don't agree but that will be addressed as part of= >>>>>> the agent cases discussion. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing tw= o sentences? The proposal is to insert "is" between "functionality" and "sup= ported", to add "the" between "by" and "reacting", to replace "node(s)" with= "node", and to insert "for the transaction" after "initiates". >>>>> Agree with the proposed change. >>>>>=20 >>>>>>> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >>>>>>> Should read: "message's" >>>>>> SRD> I'm assuming you mean section 4.1.2. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18, a= nd 19. >>>>>> I agree to the change. >>>>>>> 16. clause 4.1, 6th paragraph: >>>>>>> This should be left to the (future) specification that introduces ot= her DOIC features. >>>>>>>=20 >>>>>>> 17. clause 4.1, 7th paragraph, last 6 words: >>>>>>> should be based on requiements set by the (future) specification tha= t >>>>>>> introduces other DOIC features >>>>>> SRD> Again, clause 4.1.2 -- I don't understand the issue when these >>>>>> SRD> two >>>>>> paragraphs are taken together. >>>>>>> 18. clause 4.1, 8th paragraph, last sentence: >>>>>>> Should read: "Lack of the OC-Supported-Features AVP in the request m= essage indicates that there is no downstream reacting node for the transacti= on." >>>>>> SRD> I think you mean clause 4.1.2. I don't see the need for the cha= nge. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not co= rrect. It should either read: "Lack of the OC-Supported-Feature AVP in the r= equest message indicates to the reporting node that there is no reacting nod= e for the transaction" or as proposed above. >>>>> I don't see a reason for the change. Original text seem correct to me.= >>>>>=20 >>>>>>> 19. clause 4.1, last sentence: >>>>>>> Should read: "An agent MAY replace the OC-Supported-Features AVP car= ried in answer messages." This replacement must follow general rules. Its no= t so that the agent may do what ever it wants to. The decision must be based= on whether or not the agent has replaced the OC-S-F in the corresponding re= quest. >>>>>> SRD> What is the difference between modify and replace? I am ok with= >>>>>> removing this statement until we have the agent behavior discussion. >>>>>> I thought I had taken the agent specific statements out of this versi= on. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with identi= cal values. You remove what has been received in and insert your own stuff. >>>>> Agent (proxy) can always do that i.e. modify the APV contents. Obvious= ly if an agent tampers the OC-Supported-Features AVP it needs to know what i= t is doing. In general agree with the clarification but not with the propose= d text. >>>>>=20 >>>>> - Jouni >>>>>=20 >>>>>>> 20. clause 5.2, 1st sentence: >>>>>>> Should read: "A reporting node using the loss algorithm must use the= OC-Reduction-Percentage AVP (Section 6.7) to indicated the desired percenta= ge of traffic reduction." >>>>>> SRD> Agreed. >>>>>>> 21. clause 5.2, last sentence: >>>>>>> Should read: "Editor's note: The above duplicates what is in the OC-= Reduction-Percentage AVP section and can probably be removed." >>>>>> SRD> Yes, bad wording. The note will be removed, bad wording and all= , >>>>>> once there is a discussion on if this is redundant. >>>>>>> 22. clause 5.4, 6th paragraph: >>>>>>> Should read: "If the reacting node does not receive a an OLR in the a= nswer that corresponds to the probe request messages sent to the formally ov= erloaded node then the reacting node should slowly increase the rate of traf= fic sent to the overloaded node." >>>>>> SRD Agreed, this is more clear. >>>>>>> Best regards >>>>>>> Ulrich >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>>>> Donovan >>>>>>> Sent: Saturday, July 05, 2014 9:42 PM >>>>>>> To: dime@ietf.org >>>>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>>>=20 >>>>>>> All, >>>>>>>=20 >>>>>>> This version of the DOIC draft is a restructuring of previously >>>>>>> agreed to content. >>>>>>>=20 >>>>>>> The master plan for the restructuring is in Appendix C. This >>>>>>> outlines where material from -02 was moved in -03. >>>>>>>=20 >>>>>>> For those interested, the work was done in steps, with a snapshot fo= r >>>>>>> each step available here: >>>>>>>=20 >>>>>>> https://github.com/jounikor/draft-docdt-dime-ovli >>>>>>>=20 >>>>>>> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >>>>>>>=20 >>>>>>> where nn indicates the subversion and "text" indicates the focus for= >>>>>>> that subversion. >>>>>>>=20 >>>>>>> The next step will be to resolve open issues already identified and >>>>>>> those yet those yet to be identified. >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Steve >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts d= irectories. >>>>>>>> This draft is a work item of the Diameter Maintenance and Ex= tensions Working Group of the IETF. >>>>>>>>=20 >>>>>>>> Title : Diameter Overload Indication Convey= ance >>>>>>>> Authors : Jouni Korhonen >>>>>>>> Steve Donovan >>>>>>>> Ben Campbell >>>>>>>> Lionel Morand >>>>>>>> Filename : draft-ietf-dime-ovli-03.txt >>>>>>>> Pages : 48 >>>>>>>> Date : 2014-07-03 >>>>>>>>=20 >>>>>>>> Abstract: >>>>>>>> This specification documents a Diameter Overload Control (= DOC) base >>>>>>>> solution and the dissemination of the overload report info= rmation. >>>>>>>>=20 >>>>>>>> Requirements >>>>>>>>=20 >>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>>>>>>>=20 >>>>>>>> There's also a htmlized version available at: >>>>>>>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>>>>>>>=20 >>>>>>>> A diff from the previous version is available at: >>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-ovli-03 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>>> submission until the htmlized version and diff are available at too= ls.ietf.org. >>>>>>>>=20 >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> DiME mailing list >>>>>>>> DiME@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>> DiME@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>=20 >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 From nobody Wed Jul 30 06:46:38 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D02B1A0030 for ; Wed, 30 Jul 2014 06:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 35gbr0U3ksri for ; Wed, 30 Jul 2014 06:46:32 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E38F1A0056 for ; Wed, 30 Jul 2014 06:46:31 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id B3AAE22D8E7; Wed, 30 Jul 2014 15:46:29 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 9BC09238134; Wed, 30 Jul 2014 15:46:29 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Wed, 30 Jul 2014 15:46:29 +0200 From: To: Jouni , "Wiehe, Ulrich (NSN - DE/Munich)" Thread-Topic: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) Thread-Index: AQHPpPA/36IwRToz/kGtAPmPhYVJupuqvVowgAxDloCAACTwUIABSp6AgAAs/qD//+2lgIAAIsLw Date: Wed, 30 Jul 2014 13:46:28 +0000 Message-ID: <11125_1406727989_53D8F735_11125_1419_1_6B7134B31289DC4FAF731D844122B36E68248A@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> <53D7AA31.3070908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520806A@DEMUMBX014.nsn-intra.net> <53D8DE85.5040201@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668152081C8@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.81224 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/NKKF2WdtnxcE4LvtnC2Pxw2EnhA Cc: "dime@ietf.org" Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 13:46:37 -0000 Hi, IMHO, node selection is performed when multiple servers are present in the = realm-routing table for a given realm entry. And if multiple servers are pr= esent in table, it is because multiple connections are available. In fine, = it is the connection that is selected. No need for an agent to insert the D= est-Host AVP in the request. Therefore, I agree that DOICable may/must use = the overload reports received from the different servers to select the most= suitable server, but I agree with Jouni that an agent does not have to ins= ert Dest-Host AVP. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Envoy=E9=A0: mercredi 30 juillet 2014 15:36 =C0=A0: Wiehe, Ulrich (NSN - DE/Munich) Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dim= e-ovli-03.txt) Ulrich, I have no problem with DOICable node doing routing/forwarding based on load= whatever. But I have an issue an intermediate node adding Destination-Host= into a request when the client did not originally insert one. I am a bit c= autious that an agent next to a server can be overruled by other agents whe= n selecting the server. While this all is still within RFC6733 boundaries i= t is somewhat different than in RFC6733. That's why I have concerns with th= is.=20 Jouni --=20 Jouni Korhonen Broadcom (Sent from my mobile..) > "Wiehe, Ulrich (NSN - DE/Munich)" kirjoitti 30.7.2= 014 kello 16.07: >=20 > Jouni, >=20 > this may be true for server selecting nodes that do not support DOIC. >=20 > However, when the server selecting node supports DOIC, once the server is= selected and the abatement (according to a previously received OLR from th= e selected server) is performed (e.g. a 30% throttling was survived), you d= o not want upstream agents to undo the server selection (as it cannot undo = the throttling that is associated with the originaly selected server).=20 > Therefore I think we should mandate that DOIC supporting nodes that perfo= rm server selection and perform abatement according to reports received fro= m the selected server make sure that upstream agents do not select another = server. Otherwise we end up with a mismatch between performed abatement and= eventually selected server. >=20 > Ulrich=20 >=20 > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Wednesday, July 30, 2014 2:01 PM > To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org > Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-di= me-ovli-03.txt) >=20 > Few comments inline.. >=20 > 7/29/2014 6:41 PM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >> Steve, >>=20 >> It is my understanding that the node (client or agent) which performs se= rver selection (e.g. selects server S) needs to make sure that any upstream= agent will not undo the selection (e.g. by selecting another server Z). Th= is can be ensured by inserting a Destination-Host AVP containing S's Diamet= erIdentity to the request. Inserting the Destinatio-Host AVP is not needed = when there are no upstream agents i.e. when there is a "direct transport co= nnection" to the selected server. The case where the node that selects the = server for a realm-routed request has a direct transport connection to the = selected server is not the general case. >>=20 >> A DOICable node (client or agent) may face the situation where it has to= send out a realm-routed request. Before sending the request it may detect = that it (the node) is configured to perform server selection. The node sele= cts server S. Now (still before sending the request out) the node detects (= from checking overload states) that S is overloaded therefore it performs a= batement (diversion to Z). Now the node may either have a direct transport = connection to Z in which case it sends the request to Z (this is the case y= ou covered), or it does not have a direct transport connetion to Z in which= case it inserts the Destination-Host AVP with Z's Diameter Identity and se= nds the request to the next hop. >=20 > I have a problem with this. My understanding is that the server=20 > selection does not imply intermediate nodes inserting Destination-Host=20 > into the request independent there is direct transport connection or=20 > not.. Or am I reading the intention of this paragraph wrong? Up to the=20 > point the realm routed (Destination-Realm only case) request reaches the= =20 > "server" it is pure routing & forwarding of the request. The insertion=20 > of the Destination-Host is done by the client when it has learned the=20 > used server (from the Origin-Host). If the client has the desination=20 > host information already it may or may not insert Destination-Host into= =20 > request.. depending of its needs. >=20 > - Jouni >=20 >=20 >=20 >>=20 >>=20 >> Ulrich >>=20 >>=20 >> -----Original Message----- >> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] >> Sent: Tuesday, July 29, 2014 4:06 PM >> To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org >> Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-d= ime-ovli-03.txt) >>=20 >> Ulrich, >>=20 >> Thanks for the detailed response. I think we are very close to being in >> agreement. >>=20 >> The area I'm not sure about yet is using the wording "A DOIC node that >> does server selection" versus "A DOIC node with a direct transport >> connection". >>=20 >> A client might think it is doing server selection even when it is >> connecting to an agent. That is why I used the "direct transport >> connection" wording to make it more explicit. >>=20 >> What is the objection to this wording? >>=20 >> This could also be solved by adding a definition of server selection, >> but it would need to be done in a way that also addresses transactions >> that flow from a Diameter server to a Diameter client. >>=20 >> Regards. >>=20 >> Steve >>=20 >>> On 7/29/14, 2:29 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>> Steve, >>>=20 >>> I can agree with most of your statements. >>>=20 >>> A DOICable agent needs to determine in which scenario it actually is. T= his decision must be based on presence/absence of OC-S-F-AVP in the receive= d requests, presence/absence of Destination-Host AVP in the received reques= t and configuration data (configured to select/not to select the server for= realm routed requests). >>>=20 >>> Once this decision is taken the agent >>> a) inserts an OC-S-F to the request, or >>> b) transparently forwards the request (i.e. does not remove or add an O= C-S-F AVP), or >>> c) removes the received OC-S-F AVP and inserts its own OC-S-F AVP >>>=20 >>> note that c) includes the case where the removed AVP and the inserted A= VP are identical. >>>=20 >>> Case b) is the transparent case where the agent - although it supports = DOIC (and DOIC is not turned off) - from an external point of view behaves = like a non-DOICable node. >>>=20 >>> See also inline. >>>=20 >>> Regards, >>> Ulrich >>> (still trying to catch up with lots of mails) >>>=20 >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan >>> Sent: Monday, July 21, 2014 4:29 PM >>> To: dime@ietf.org >>> Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-= dime-ovli-03.txt) >>>=20 >>> Ulrich, >>>=20 >>> I am not arguing that all agents should take an active role in the >>> handling of all overload reports. What I am arguing is that there are >>> scenarios where an agent must take an active role in DOIC to ensure that >>> a requested reduction in traffic an be achieved. >>>=20 >>> For DOIC to work a carrier cannot turn off all DOIC behavior in agents, >>> as suggested by Jouni. >>>=20 >>> I agree that in your scenario below, a1 does not need to take an active >>> role in reducing traffic when c supports DOIC. a1 should take an active >>> role when c does not support DOIC. The problem is that a1 does not know >>> in advance whether c supports DOIC so it will need to inspect all >>> transactions for the presence of OC-S-F to determine if it needs to >>> handle overload reports for a non supporting client. >>> I agree >>>=20 >>> Does that mean a1 is transparent if it inspects all requests and does >>> nothing in the case where there is c supports DOIC? >>> yes >>>=20 >>> Does transparent mean that there is no observable difference in the DOIC >>> AVPs that pass through the agent >>> yes or does it mean that there is no >>> observable difference in how transactions are handled by the DOIC agent? >>> no >>>=20 >>> I'm guessing that we have multiple assumptions on what transparent means >>> and, if we are going to continue saying agents should be transparent >>> then we need a definition of transparent. >>>=20 >>> I think for this use case, we need the following normative statements in >>> the draft for handling of abatement of realm-routed requests? I think >>> this is general behavior and should go in the section on handling of >>> overload reports. >>>=20 >>> "DOIC nodes with a direct transport connection to a reporting node that >>> has an active overload report must handle abatement of realm-routed >>> requests. The preferred method for handling abatement of realm-routed >>> requests is diversion, where the node with the direct transport >>> connection routes the request to an alternative server that is able to >>> handle the request. If there is no alternative server with the needed >>> capacity to handle the request then the DOIC node must/should throttle >>> the necessary requests to meet the requested reduction in traffic." >>> My proposal: >>> "A DOIC node with performs server selection for realm routed requests t= hat >>> has active overload reports from servers it potentially selects, must >>> handle abatement of realm-routed >>> requests. The preferred method for handling abatement of realm-routed >>> requests is diversion, where the node selecting the server routes the >>> request to an alternative server that is able to >>> handle the request. If there is no alternative server with the needed >>> capacity to handle the request then the DOIC node must/should preferrab= ly >>> delegate abatement (of realm routed requests) towards a downstream reac= ting >>> node or otherwise throttle >>> the necessary requests to meet the requested reduction in traffic." >>> >>>=20 >>>=20 >>> If we can agree on this then we can move on to the next agent based use >>> case. >>>=20 >>> Regards, >>>=20 >>> Steve >>>=20 >>>> On 7/21/14, 9:47 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>> Steve, >>>>=20 >>>> The example you show is absolutely valid and 100% inline with A) to F)= - (assuming that all servers can serve any request). >>>> However, there are other scenarios like: >>>>=20 >>>>=20 >>>>=20 >>>> +--+ >>>> /--|s1| >>>> +-+ +--+ +--+ / +--+ >>>> |c|--- |a1|--|a2|=3D=3D ... >>>> +-+ +--+ +--+ \ +--+ >>>> \--|sn| >>>> +--+ >>>>=20 >>>> Here I think a1 should be transparent even when DOICable. >>>> a1 does not take the role of a reacting node since c supports DOIC. >>>> a1 does not perform server selection and therefore does not take the r= ole of a reporting node (for realm-reports). >>>>=20 >>>> Ulrich >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] >>>> Sent: Monday, July 21, 2014 3:16 PM >>>> To: Nirav Salot (nsalot); Jouni Korhonen; Wiehe, Ulrich (NSN - DE/Muni= ch); dime@ietf.org >>>> Subject: Transparent agents (was Re: [Dime] I-D Action: draft-ietf-dim= e-ovli-03.txt) >>>>=20 >>>> Ok, let's see if it's possible to completely turn off all DOIC behavior >>>> in agents and still be able to reduce traffic to a server that sends a >>>> host overload report. >>>>=20 >>>> Assume the following agent based deployment: >>>>=20 >>>> +--+ >>>> /--|s1| >>>> +-+ +-+ / +--+ >>>> |c|--|a|=3D=3D ... >>>> +-+ +-+ \ +--+ >>>> \--|sn| >>>> +--+ >>>>=20 >>>> Assume that there is a large number of servers, say 50. >>>>=20 >>>> Now, assume that the Diameter application in question exclusively uses >>>> realm-routed requests - 100% of requests sent by the client do NOT have >>>> a destination-host AVP. >>>>=20 >>>> Now assume that server s1 sends an host type overload report requesting >>>> a reduction of 20% using the loss algorithm. >>>>=20 >>>> Also assume that the unused capacity in servers s2 through s50 is >>>> sufficient to handle the traffic that would have been sent to s1. As >>>> such, there is no reason to throttle any requests. >>>>=20 >>>> There are no host routed requests for this application and the client >>>> does not have a direct transport connection to server s1. The only >>>> option a client has is to hand the request off to the agent for routin= g. >>>>=20 >>>> The proposal in the agent cases draft is that the agent diverts 20% of >>>> the realm routed requests that would have been sent to server s1 to >>>> servers s2 through s50. >>>>=20 >>>> If DOIC behavior is turned off in the agent then how will the traffic >>>> routed to s1 be reduced? >>>>=20 >>>> Steve >>>>=20 >>>>> On 7/21/14, 12:08 AM, Nirav Salot (nsalot) wrote: >>>>> +1 for the following aspect. >>>>>=20 >>>>>>>> Agents must take an active role in even the most basic case for >>>>>>>> overload handling to work, so they cannot be transparent. >>>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do no= t support DOIC are transparent. Agents that support DOIC in most cases beha= ve like non supporting agents. >>>>>> I am towards Ulrich's view here. Even for an agent that understands = DOIC it is up to the local policy whether it is transparent or takes an act= ive role. >>>>> -----Original Message----- >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >>>>> Sent: Monday, July 21, 2014 12:26 AM >>>>> To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org >>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>=20 >>>>> Some comments inline.. >>>>>=20 >>>>> 7/19/2014 10:29 AM, Wiehe, Ulrich (NSN - DE/Munich) kirjoitti: >>>>>> Steve, >>>>>> please see my response inline. >>>>>>=20 >>>>>> Regards >>>>>> Ulrich >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>>> Donovan >>>>>> Sent: Tuesday, July 15, 2014 3:53 PM >>>>>> To: dime@ietf.org >>>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>>=20 >>>>>> Ulrich, >>>>>>=20 >>>>>> Thanks for the comments. Please see my responses inline. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Steve >>>>>>> On 7/14/14, 10:33 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>>>>> Hi Steve, >>>>>>> here are my comments. >>>>>>> They focus on new text you introduced. I agree that restructuring m= ay require new text, however, I believe that with the new text a new concep= ts is introduced which macerates the agreed end-to-end concept and allows a= ll DOIC agents on the path to do what they wants, so that we end up in a ho= p-by-hop concept. >>>>>> SRD> We have never had an agreement on end-to-end versus hop-by-hop >>>>>> SRD> and >>>>>> I believe that we will end up with a hybrid of the two. We have open >>>>>> issues on agent behavior that Ben and I are attempting to address wi= th >>>>>> the agent cases draft. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I thought that the hop-by-hop appr= oach of the roach draft was reason not to proceed with that draft. >>>>>>=20 >>>>>> SRD> That said, this type of restructuring of the document is likely >>>>>> SRD> to >>>>>> put agreed to behavior in a new light. If there are cases where I >>>>>> have implied changes to agreed to normative behavior, or if the >>>>>> informative text is not accurate, then these things need to be corre= cted. >>>>>>> 1. clause 2.3, second paragraph: >>>>>>> Should read: "Reacting nodes indicate support for DOIC by including= the OC-Supported-Features AVP into all request messages originated or rela= yed by the Reacting node." >>>>>> SRD> You mean clause 3.2. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes >>>>>> I agree with the change. >>>>>>> 2. clause 2.3, 3rd paragraph, 1st sentence: >>>>>>> OC-xxx AVPs must not be included in an answer message when the corr= esponding request did not contain an OC-S-F AVP. >>>>>> SRD> Agreed. >>>>>>> 3. clause 3.3, 7th paragraph: >>>>>>> Should read "The reporting node only includes an indication of supp= ort for one overload abatement algorithm. This is the algorithm that the r= eporting node intends to use should it enter an overload condition or reque= sts to use while it actually is in an overload condition. Reacting nodes ca= n use the indicated overload abatement algorithm to prepare for possible ov= erload reports and must use the indicated overload abatement algorithm if t= raffic reduction is actually requested." >>>>>> SRD. OK. >>>>>>> 4. clause 3.3, 10th paragraph: >>>>>>> The 1st sentence is misleading. In the general case, agents on the = path between reacting node and reporting node are transparent. I agree that= there are exceptions to the general case where an agent on the path is not= transparent, but then the agent IS the reporting node (reporting to the se= nder of the request) and it also IS the reacting node (reacting on reports = received from the upstream reporting node). >>>>>>> The first 3 words of the second sentence "in this case" need clarif= ication: "In the case where an agent takes the role of a reporting node (re= porting to the downstream reacting node) and at the same time takes the rol= e of a reacting node (reacting on reports received from an upstream reporti= ng node)". >>>>>>> Last sentence: Its not an update but a replacement. The two DOIC as= sociations are handled independently. >>>>>> SRD> I don't know what you mean when you say an agent is transparent. >>>>>> Agents must take an active role in even the most basic case for >>>>>> overload handling to work, so they cannot be transparent. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] I do not agree. Agents that do not= support DOIC are transparent. Agents that support DOIC in most cases behav= e like non supporting agents. >>>>> I am towards Ulrich's view here. Even for an agent that understands D= OIC it is up to the local policy whether it is transparent or takes an acti= ve role. >>>>>=20 >>>>>>> 5. clause 3.3, last paragraph: >>>>>>> General rules shall be followed for each of the two associations se= parately. The content of the OC-S-F AVP sent by the agent upstream should r= eflect what the agent is able and willing to support (as always). >>>>>> SRD> What two associations? Is there one association (end-to-end) or >>>>>> SRD> is >>>>>> the an association on both sides of the agent (hop-by-hop)? Or is >>>>>> there an association that involves three entities, the reporting nod= e, >>>>>> an agent reacting node for realm-routed requests and a >>>>>> transaction-client reporting node for handling host-routed requests? >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] See figure 4 in clause 3.1, There = is >>>>>> one association between C and A, and one association between A and S= . Both associations are "end-to-end" as there may be transparent (supportin= g or non-supporting) agents in the middle. >>>>>>> 6. clause 3.4, 2nd paragraph: >>>>>>> Should read: "The OC-OLR AVP is referred to as an overload report. = The OC-OLR AVP includes the type of report, a sequence number, the length = of time that the report is valid and abatement algorithm specific AVPs." >>>>>> SRD> The sequence number is being used as an overload report ID. I c= an >>>>>> make the change but I don't see it as necessary. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] please make the change. >>>>> OK to do the change. >>>>>=20 >>>>>>> 7. clause 3.4, 4th paragraph, 2nd sentence: >>>>>>> I cannot understand this sentence. Probably only simple typos but I= don't know. >>>>>> SRD> Yes, a typo (this instead of the) and awkward wording. How abo= ut >>>>>> "This applies to requests that contain the Destination-Host AVP with= a >>>>>> DiameterIdentity that matches the overload report. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] or "They apply to requests that co= ntain a DiameterIdentity in the Destination-Host AVP that matches the repor= ting host's DiameterIdentity" >>>>> I would be inclined to keep the text Steve proposed. But both are ok = actually. >>>>>=20 >>>>>>> 8. clause 3.4, 4th paragraph last 2 sentences: >>>>>>> I don't understand and probably do not agree. >>>>>> SRD> See above. >>>>>>> 9. clause 3.5, 3rd paragraph, last word: >>>>>>> Should read "communicated" >>>>>> SRD> Agreed. >>>>>>> 10. clause 3.5, 4th paragraph, 1st sentence: >>>>>>> I don't understand. I can understand: "Reporting nodes use the OC-O= LR AVP to communicate overload occurances towards reacting nodes." >>>>>> SRD> Who else would reports be sent to? >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Its not the Overload abatement alg= orithm but the reporting node that uses the OC-OLR AVP to communicate overl= oad occurances. >>>>> Agree. >>>>>=20 >>>>>>> 11. clause 4.1, 3rd paragraph, last 4 words: >>>>>>> may be misleading. A DOIC supporting agent sitting between DOIC sup= porting client and DOIC supporting Server is transparent with regard to DOI= C. This agent does not indicate DOIC support. >>>>>> SRD> I disagree. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] Maybe my comment was not clear. Sh= ould be: ...This agent does not indicate its DOIC support, rather it transp= arently forwards the client's DOIC support. >>>>> Agree with Ulrich on the intent of agent behavior but not with the pr= oposed text change. >>>>>=20 >>>>>>> 12. clause 4.1, 4th paragraph, 2nd sentence: >>>>>>> Should read:"If a request message handled by the DOIC agent does no= t include the OC-Supported-Features AVP then the DOIC agent inserts the AVP= ." >>>>>> SRD> That is what it already says. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] no, it says: If a message... >>>>> OC-Supported-Features can be in both request and answer, thus "If a m= essage" in that sense is correct. >>>>>=20 >>>>>>> 13. clause 4.1, last sentence: >>>>>>> Should read "If the message already has the AVP then the agent eith= er leaves it unchanged in the relayed message or replaces it to reflect the= features the agent is able and willing to support." Clarification is neede= d to say that strict rules must be followed by the agent to select the corr= ect option. These rules take into account whether the request is host-route= d or relam-routed and whether the agent is configured to select the server = for realm-routed requests. >>>>>> SRD> This is a topic on agent behavior that is addressed in the agent >>>>>> cases draft. I'll leave the discussion for what the wording should = be >>>>>> to the discussion on that draft. >>>>>>> 14. clause 4.1.2, 2nd paragraph: >>>>>>> Should read: "Based on the content of the OC-Supported-Features AVP= in the request message, the reporting node knows what overload control fun= ctionality is supported by the reacting node. The reporting node then acts= accordingly for the subsequent answer messages it initiates for the transa= ction." >>>>>> SRD> It would be easier if you didn't make it difficult to understand >>>>>> the change you are proposing. I think you are proposing changing >>>>>> node(s) to node. I don't agree but that will be addressed as part of >>>>>> the agent cases discussion. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] what is difficult with comparing t= wo sentences? The proposal is to insert "is" between "functionality" and "s= upported", to add "the" between "by" and "reacting", to replace "node(s)" w= ith "node", and to insert "for the transaction" after "initiates". >>>>> Agree with the proposed change. >>>>>=20 >>>>>>> 15. clause 4.1, 4th paragraph, 2nd sentence, 17th word: >>>>>>> Should read: "message's" >>>>>> SRD> I'm assuming you mean section 4.1.2. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] yes, also for comments 16, 17, 18,= and 19. >>>>>> I agree to the change. >>>>>>> 16. clause 4.1, 6th paragraph: >>>>>>> This should be left to the (future) specification that introduces o= ther DOIC features. >>>>>>>=20 >>>>>>> 17. clause 4.1, 7th paragraph, last 6 words: >>>>>>> should be based on requiements set by the (future) specification th= at >>>>>>> introduces other DOIC features >>>>>> SRD> Again, clause 4.1.2 -- I don't understand the issue when these >>>>>> SRD> two >>>>>> paragraphs are taken together. >>>>>>> 18. clause 4.1, 8th paragraph, last sentence: >>>>>>> Should read: "Lack of the OC-Supported-Features AVP in the request = message indicates that there is no downstream reacting node for the transac= tion." >>>>>> SRD> I think you mean clause 4.1.2. I don't see the need for the ch= ange. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] The sentence as it stands is not c= orrect. It should either read: "Lack of the OC-Supported-Feature AVP in the= request message indicates to the reporting node that there is no reacting = node for the transaction" or as proposed above. >>>>> I don't see a reason for the change. Original text seem correct to me. >>>>>=20 >>>>>>> 19. clause 4.1, last sentence: >>>>>>> Should read: "An agent MAY replace the OC-Supported-Features AVP ca= rried in answer messages." This replacement must follow general rules. Its = not so that the agent may do what ever it wants to. The decision must be ba= sed on whether or not the agent has replaced the OC-S-F in the correspondin= g request. >>>>>> SRD> What is the difference between modify and replace? I am ok with >>>>>> removing this statement until we have the agent behavior discussion. >>>>>> I thought I had taken the agent specific statements out of this vers= ion. >>>>>> [Wiehe, Ulrich (NSN - DE/Munich)] replacement can be done with ident= ical values. You remove what has been received in and insert your own stuff. >>>>> Agent (proxy) can always do that i.e. modify the APV contents. Obviou= sly if an agent tampers the OC-Supported-Features AVP it needs to know what= it is doing. In general agree with the clarification but not with the prop= osed text. >>>>>=20 >>>>> - Jouni >>>>>=20 >>>>>>> 20. clause 5.2, 1st sentence: >>>>>>> Should read: "A reporting node using the loss algorithm must use th= e OC-Reduction-Percentage AVP (Section 6.7) to indicated the desired percen= tage of traffic reduction." >>>>>> SRD> Agreed. >>>>>>> 21. clause 5.2, last sentence: >>>>>>> Should read: "Editor's note: The above duplicates what is in the OC= -Reduction-Percentage AVP section and can probably be removed." >>>>>> SRD> Yes, bad wording. The note will be removed, bad wording and al= l, >>>>>> once there is a discussion on if this is redundant. >>>>>>> 22. clause 5.4, 6th paragraph: >>>>>>> Should read: "If the reacting node does not receive a an OLR in the= answer that corresponds to the probe request messages sent to the formally= overloaded node then the reacting node should slowly increase the rate of = traffic sent to the overloaded node." >>>>>> SRD Agreed, this is more clear. >>>>>>> Best regards >>>>>>> Ulrich >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve >>>>>>> Donovan >>>>>>> Sent: Saturday, July 05, 2014 9:42 PM >>>>>>> To: dime@ietf.org >>>>>>> Subject: Re: [Dime] I-D Action: draft-ietf-dime-ovli-03.txt >>>>>>>=20 >>>>>>> All, >>>>>>>=20 >>>>>>> This version of the DOIC draft is a restructuring of previously >>>>>>> agreed to content. >>>>>>>=20 >>>>>>> The master plan for the restructuring is in Appendix C. This >>>>>>> outlines where material from -02 was moved in -03. >>>>>>>=20 >>>>>>> For those interested, the work was done in steps, with a snapshot f= or >>>>>>> each step available here: >>>>>>>=20 >>>>>>> https://github.com/jounikor/draft-docdt-dime-ovli >>>>>>>=20 >>>>>>> Each step has the name draft-ietf-dime-ovli-03-nn-text.txt >>>>>>>=20 >>>>>>> where nn indicates the subversion and "text" indicates the focus for >>>>>>> that subversion. >>>>>>>=20 >>>>>>> The next step will be to resolve open issues already identified and >>>>>>> those yet those yet to be identified. >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Steve >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 7/3/14, 2:31 PM, internet-drafts@ietf.org wrote: >>>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts= directories. >>>>>>>> This draft is a work item of the Diameter Maintenance and E= xtensions Working Group of the IETF. >>>>>>>>=20 >>>>>>>> Title : Diameter Overload Indication Conve= yance >>>>>>>> Authors : Jouni Korhonen >>>>>>>> Steve Donovan >>>>>>>> Ben Campbell >>>>>>>> Lionel Morand >>>>>>>> Filename : draft-ietf-dime-ovli-03.txt >>>>>>>> Pages : 48 >>>>>>>> Date : 2014-07-03 >>>>>>>>=20 >>>>>>>> Abstract: >>>>>>>> This specification documents a Diameter Overload Control = (DOC) base >>>>>>>> solution and the dissemination of the overload report inf= ormation. >>>>>>>>=20 >>>>>>>> Requirements >>>>>>>>=20 >>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/ >>>>>>>>=20 >>>>>>>> There's also a htmlized version available at: >>>>>>>> http://tools.ietf.org/html/draft-ietf-dime-ovli-03 >>>>>>>>=20 >>>>>>>> A diff from the previous version is available at: >>>>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-ovli-03 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>>> submission until the htmlized version and diff are available at to= ols.ietf.org. >>>>>>>>=20 >>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> DiME mailing list >>>>>>>> DiME@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>> _______________________________________________ >>>>>>> DiME mailing list >>>>>>> DiME@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>>=20 >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Jul 30 07:01:00 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD38E1A005B for ; Wed, 30 Jul 2014 07:00:58 -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, SPF_NEUTRAL=0.779] autolearn=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 jl67vNLmSFUx for ; Wed, 30 Jul 2014 07:00:56 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 874491A004E for ; Wed, 30 Jul 2014 07:00:56 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57804 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XCUR3-0000Ew-4h for dime@ietf.org; Wed, 30 Jul 2014 07:00:55 -0700 Message-ID: <53D8FA94.6030806@usdonovans.com> Date: Wed, 30 Jul 2014 09:00:52 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dime@ietf.org References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> <53D7AA31.3070908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520806A@DEMUMBX014.nsn-intra.net> <53D8DE85.5040201@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668152081C8@DEMUMBX014.nsn-intra.net> <11125_1406727989_53D8F735_11125_1419_1_6B7134B31289DC4FAF731D844122B36E68248A@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <11125_1406727989_53D8F735_11125_1419_1_6B7134B31289DC4FAF731D844122B36E68248A@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/sz4X5QsWy5mP30Lo4YgeIn3XsDw Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 14:00:59 -0000 The question is the behavior of a DOIC node that does abatement of "realm-route-requests" in the face of a host report for a server. I think the DOIC specification needs to say that for a DOIC node to do abatement of realm-routed-requests it needs to be able to guarantee that the request that survive abatement will be routed to the reporting node for the host report. This is easy to achieve if the DOIC node has a direct transport connection to the reporting node. Ulrich's point is that it can also be achieved by the DOIC node inserting destination-host for requests targeted for the reporting node that survive abatement. Steve On 7/30/14, 8:46 AM, lionel.morand@orange.com wrote: > Hi, > > IMHO, node selection is performed when multiple servers are present in the realm-routing table for a given realm entry. And if multiple servers are present in table, it is because multiple connections are available. In fine, it is the connection that is selected. No need for an agent to insert the Dest-Host AVP in the request. Therefore, I agree that DOICable may/must use the overload reports received from the different servers to select the most suitable server, but I agree with Jouni that an agent does not have to insert Dest-Host AVP. > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni > Envoyé : mercredi 30 juillet 2014 15:36 > À : Wiehe, Ulrich (NSN - DE/Munich) > Cc : dime@ietf.org > Objet : Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) > > Ulrich, > > I have no problem with DOICable node doing routing/forwarding based on load whatever. But I have an issue an intermediate node adding Destination-Host into a request when the client did not originally insert one. I am a bit cautious that an agent next to a server can be overruled by other agents when selecting the server. While this all is still within RFC6733 boundaries it is somewhat different than in RFC6733. That's why I have concerns with this. > > Jouni > From nobody Wed Jul 30 07:33:57 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8E61A0087 for ; Wed, 30 Jul 2014 07:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 60Xuug7vUADi for ; Wed, 30 Jul 2014 07:33:51 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id E2F5C1A00E5 for ; Wed, 30 Jul 2014 07:33:40 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0195.001; Wed, 30 Jul 2014 10:33:40 -0400 From: Dave Dolson To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) Thread-Index: AQHPpOYdR9zJJGY8lEarOX8WMqkJU5uqzgGAgAALjoCADB0+gIAAbsyAgAAavYCAAVTRgIAAEooAgAAIGYCAAALKAIAABAYA///FTvA= Date: Wed, 30 Jul 2014 14:33:38 +0000 Message-ID: References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> <53D7AA31.3070908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520806A@DEMUMBX014.nsn-intra.net> <53D8DE85.5040201@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668152081C8@DEMUMBX014.nsn-intra.net> <11125_1406727989_53D8F735_11125_1419_1_6B7134B31289DC4FAF731D844122B36E68248A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53D8FA94.6030806@usdonovans.com> In-Reply-To: <53D8FA94.6030806@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.111] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xAqQlDMQpZL0Ocj3hga3XonGueE Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 14:33:53 -0000 Host overload reports should not affect realm-route-requests. The system will be more stable if the two control systems are independent, = not cross-coupled. -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, July 30, 2014 10:01 AM To: dime@ietf.org Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime= -ovli-03.txt) The question is the behavior of a DOIC node that does abatement of=20 "realm-route-requests" in the face of a host report for a server. I think the DOIC specification needs to say that for a DOIC node to do=20 abatement of realm-routed-requests it needs to be able to guarantee that=20 the request that survive abatement will be routed to the reporting node=20 for the host report. This is easy to achieve if the DOIC node has a=20 direct transport connection to the reporting node. Ulrich's point is=20 that it can also be achieved by the DOIC node inserting destination-host=20 for requests targeted for the reporting node that survive abatement. Steve On 7/30/14, 8:46 AM, lionel.morand@orange.com wrote: > Hi, > > IMHO, node selection is performed when multiple servers are present in th= e realm-routing table for a given realm entry. And if multiple servers are = present in table, it is because multiple connections are available. In fine= , it is the connection that is selected. No need for an agent to insert the= Dest-Host AVP in the request. Therefore, I agree that DOICable may/must us= e the overload reports received from the different servers to select the mo= st suitable server, but I agree with Jouni that an agent does not have to i= nsert Dest-Host AVP. > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni > Envoy=E9 : mercredi 30 juillet 2014 15:36 > =C0 : Wiehe, Ulrich (NSN - DE/Munich) > Cc : dime@ietf.org > Objet : Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dim= e-ovli-03.txt) > > Ulrich, > > I have no problem with DOICable node doing routing/forwarding based on lo= ad whatever. But I have an issue an intermediate node adding Destination-Ho= st into a request when the client did not originally insert one. I am a bit= cautious that an agent next to a server can be overruled by other agents w= hen selecting the server. While this all is still within RFC6733 boundaries= it is somewhat different than in RFC6733. That's why I have concerns with = this. > > Jouni > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Wed Jul 30 07:48:26 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3BB1A0108 for ; Wed, 30 Jul 2014 07:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 GLJ-CJc5lA5q for ; Wed, 30 Jul 2014 07:48:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B2CB1A00A7 for ; Wed, 30 Jul 2014 07:48:21 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id C34E82DC0D9; Wed, 30 Jul 2014 16:48:19 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id A8F3927C091; Wed, 30 Jul 2014 16:48:19 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Wed, 30 Jul 2014 16:48:19 +0200 From: To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) Thread-Index: AQHPpPA/36IwRToz/kGtAPmPhYVJupuqvVowgAxDloCAACTwUIABSp6AgAAs/qD//+2lgIAAIsLw///kDgCAAC0BIA== Date: Wed, 30 Jul 2014 14:48:18 +0000 Message-ID: <3526_1406731699_53D905B3_3526_8469_1_6B7134B31289DC4FAF731D844122B36E68263A@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> <53D7AA31.3070908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520806A@DEMUMBX014.nsn-intra.net> <53D8DE85.5040201@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668152081C8@DEMUMBX014.nsn-intra.net> <11125_1406727989_53D8F735_11125_1419_1_6B7134B31289DC4FAF731D844122B36E68248A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53D8FA94.6030806@usdonovans.com> In-Reply-To: <53D8FA94.6030806@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.30.103920 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/TKLcw6FMQfnm9sg9zAFog-TiXfM Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 14:48:24 -0000 I was commenting Ulrich's point on the insertion of the Dest-Host. My answe= r was based on the RFC6733. The Dest-Host is inserting by the node initiati= ng the request. Anything relating to a an agent inserting a Dest-Host on be= half of the request initiator should be left out of the specification. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9=A0: mercredi 30 juillet 2014 16:01 =C0=A0: dime@ietf.org Objet=A0: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dim= e-ovli-03.txt) The question is the behavior of a DOIC node that does abatement of=20 "realm-route-requests" in the face of a host report for a server. I think the DOIC specification needs to say that for a DOIC node to do=20 abatement of realm-routed-requests it needs to be able to guarantee that=20 the request that survive abatement will be routed to the reporting node=20 for the host report. This is easy to achieve if the DOIC node has a=20 direct transport connection to the reporting node. Ulrich's point is=20 that it can also be achieved by the DOIC node inserting destination-host=20 for requests targeted for the reporting node that survive abatement. Steve On 7/30/14, 8:46 AM, lionel.morand@orange.com wrote: > Hi, > > IMHO, node selection is performed when multiple servers are present in th= e realm-routing table for a given realm entry. And if multiple servers are = present in table, it is because multiple connections are available. In fine= , it is the connection that is selected. No need for an agent to insert the= Dest-Host AVP in the request. Therefore, I agree that DOICable may/must us= e the overload reports received from the different servers to select the mo= st suitable server, but I agree with Jouni that an agent does not have to i= nsert Dest-Host AVP. > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni > Envoy=E9 : mercredi 30 juillet 2014 15:36 > =C0 : Wiehe, Ulrich (NSN - DE/Munich) > Cc : dime@ietf.org > Objet : Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dim= e-ovli-03.txt) > > Ulrich, > > I have no problem with DOICable node doing routing/forwarding based on lo= ad whatever. But I have an issue an intermediate node adding Destination-Ho= st into a request when the client did not originally insert one. I am a bit= cautious that an agent next to a server can be overruled by other agents w= hen selecting the server. While this all is still within RFC6733 boundaries= it is somewhat different than in RFC6733. That's why I have concerns with = this. > > Jouni > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Jul 30 07:56:05 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD681A0162 for ; Wed, 30 Jul 2014 07:56:02 -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, SPF_NEUTRAL=0.779] autolearn=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 Ryk7tvnOUOSY for ; Wed, 30 Jul 2014 07:56:01 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 05F4E1A00A7 for ; Wed, 30 Jul 2014 07:56:01 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57933 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XCVIJ-0002dK-HR; Wed, 30 Jul 2014 07:56:00 -0700 Message-ID: <53D90779.4060100@usdonovans.com> Date: Wed, 30 Jul 2014 09:55:53 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> <53D7AA31.3070908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520806A@DEMUMBX014.nsn-intra.net> <53D8DE85.5040201@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668152081C8@DEMUMBX014.nsn-intra.net> <11125_1406727989_53D8F735_11125_1419_1_6B7134B31289DC4FAF731D844122B36E68248A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53D8FA94.6030806@usdonovans.com> <3526_1406731699_53D905B3_3526_8469_1_6B7134B31289DC4FAF731D844122B36E68263A@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <3526_1406731699_53D905B3_3526_8469_1_6B7134B31289DC4FAF731D844122B36E68263A@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/mlGcijFjtlQ-lNcDKa3EIE8GFOo Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 14:56:02 -0000 I'm ok with keeping it limited to just DOIC nodes that have direct transport connections. I agreed with Ulrich's suggestion because there are agents in the wild that can insert destination-Host, depending on local policy. It is, however, probably better to remain consistent with RFC6733. Steve On 7/30/14, 9:48 AM, lionel.morand@orange.com wrote: > I was commenting Ulrich's point on the insertion of the Dest-Host. My answer was based on the RFC6733. The Dest-Host is inserting by the node initiating the request. Anything relating to a an agent inserting a Dest-Host on behalf of the request initiator should be left out of the specification. > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoyé : mercredi 30 juillet 2014 16:01 > À : dime@ietf.org > Objet : Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) > > The question is the behavior of a DOIC node that does abatement of > "realm-route-requests" in the face of a host report for a server. > > I think the DOIC specification needs to say that for a DOIC node to do > abatement of realm-routed-requests it needs to be able to guarantee that > the request that survive abatement will be routed to the reporting node > for the host report. This is easy to achieve if the DOIC node has a > direct transport connection to the reporting node. Ulrich's point is > that it can also be achieved by the DOIC node inserting destination-host > for requests targeted for the reporting node that survive abatement. > > Steve > > On 7/30/14, 8:46 AM, lionel.morand@orange.com wrote: >> Hi, >> >> IMHO, node selection is performed when multiple servers are present in the realm-routing table for a given realm entry. And if multiple servers are present in table, it is because multiple connections are available. In fine, it is the connection that is selected. No need for an agent to insert the Dest-Host AVP in the request. Therefore, I agree that DOICable may/must use the overload reports received from the different servers to select the most suitable server, but I agree with Jouni that an agent does not have to insert Dest-Host AVP. >> >> Lionel >> >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni >> Envoyé : mercredi 30 juillet 2014 15:36 >> À : Wiehe, Ulrich (NSN - DE/Munich) >> Cc : dime@ietf.org >> Objet : Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) >> >> Ulrich, >> >> I have no problem with DOICable node doing routing/forwarding based on load whatever. But I have an issue an intermediate node adding Destination-Host into a request when the client did not originally insert one. I am a bit cautious that an agent next to a server can be overruled by other agents when selecting the server. While this all is still within RFC6733 boundaries it is somewhat different than in RFC6733. That's why I have concerns with this. >> >> Jouni >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > From nobody Wed Jul 30 08:01:20 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219DD1A0188 for ; Wed, 30 Jul 2014 08:01:14 -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, SPF_NEUTRAL=0.779] autolearn=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 l4GhIk9wo20R for ; Wed, 30 Jul 2014 08:01:12 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 9F04A1A0199 for ; Wed, 30 Jul 2014 08:01:11 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:57941 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XCVNJ-0007Jv-3q; Wed, 30 Jul 2014 08:01:10 -0700 Message-ID: <53D908B1.7030404@usdonovans.com> Date: Wed, 30 Jul 2014 10:01:05 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dave Dolson , "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> <53D7AA31.3070908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520806A@DEMUMBX014.nsn-intra.net> <53D8DE85.5040201@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668152081C8@DEMUMBX014.nsn-intra.net> <11125_1406727989_53D8F735_11125_1419_1_6B7134B31289DC4FAF731D844122B36E68248A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53D8FA94.6030806@usdonovans.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XSRD5HxnRIZvAvwPKtylV1_iVfI Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 15:01:14 -0000 Dave, A host report is a request by the reporting node to reduce traffic to that node, regardless of the type of request. In order to achieve that reduction, it is necessary to abate both "host-routed" requests and "realm-routed" request". The first use case in the agent cases draft illustrates this scenario where the client handles abatement of the host-routed requests and the agent that has direct transport connection to the reporting node handles abatement of realm-routed requests. There is no mechanism for the reporting node to request a reduction in host-routed requests separate from realm-routed requests. One of the reasons is that for realm-routed requests there may be other nodes that could handle the request. Steve On 7/30/14, 9:33 AM, Dave Dolson wrote: > Host overload reports should not affect realm-route-requests. > The system will be more stable if the two control systems are independent, not cross-coupled. > > > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: Wednesday, July 30, 2014 10:01 AM > To: dime@ietf.org > Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) > > The question is the behavior of a DOIC node that does abatement of > "realm-route-requests" in the face of a host report for a server. > > I think the DOIC specification needs to say that for a DOIC node to do > abatement of realm-routed-requests it needs to be able to guarantee that > the request that survive abatement will be routed to the reporting node > for the host report. This is easy to achieve if the DOIC node has a > direct transport connection to the reporting node. Ulrich's point is > that it can also be achieved by the DOIC node inserting destination-host > for requests targeted for the reporting node that survive abatement. > > Steve > > On 7/30/14, 8:46 AM, lionel.morand@orange.com wrote: >> Hi, >> >> IMHO, node selection is performed when multiple servers are present in the realm-routing table for a given realm entry. And if multiple servers are present in table, it is because multiple connections are available. In fine, it is the connection that is selected. No need for an agent to insert the Dest-Host AVP in the request. Therefore, I agree that DOICable may/must use the overload reports received from the different servers to select the most suitable server, but I agree with Jouni that an agent does not have to insert Dest-Host AVP. >> >> Lionel >> >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni >> Envoyé : mercredi 30 juillet 2014 15:36 >> À : Wiehe, Ulrich (NSN - DE/Munich) >> Cc : dime@ietf.org >> Objet : Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) >> >> Ulrich, >> >> I have no problem with DOICable node doing routing/forwarding based on load whatever. But I have an issue an intermediate node adding Destination-Host into a request when the client did not originally insert one. I am a bit cautious that an agent next to a server can be overruled by other agents when selecting the server. While this all is still within RFC6733 boundaries it is somewhat different than in RFC6733. That's why I have concerns with this. >> >> Jouni >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Wed Jul 30 08:10:38 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF1C1A0235 for ; Wed, 30 Jul 2014 08:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 hPyY4KoXPbL3 for ; Wed, 30 Jul 2014 08:10:33 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E061A01F3 for ; Wed, 30 Jul 2014 08:09:36 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 6AA002AD817; Wed, 30 Jul 2014 17:09:34 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 476DE1581EA; Wed, 30 Jul 2014 17:09:34 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Wed, 30 Jul 2014 17:09:34 +0200 From: To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Steve Donovan" , "dime@ietf.org" Thread-Topic: [Dime] Issue #26 proposed resolution Thread-Index: AQHPq2cDWCopVPpFZk2PDWjium63lZu4K8YAgACMgTA= Date: Wed, 30 Jul 2014 15:09:33 +0000 Message-ID: <21807_1406732974_53D90AAE_21807_8763_1_6B7134B31289DC4FAF731D844122B36E6826D2@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <53D7FC1B.8070708@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520812B@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681520812B@DEMUMBX014.nsn-intra.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.30.103920 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-gztcidJ3XejrD4Aq1dRNHnXmlg Subject: Re: [Dime] Issue #26 proposed resolution X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 15:10:35 -0000 The concept of DOIC endpoint is introduced in section 3. I share the view that the section 3.1 can be removed. And the figures do no= t provide real added-values after saying in the introduction: "Any Diameter node can act as a DOIC endpoint, including clients, servers, and agents. DOIC endpoints are further divided into "Reporting Nodes" and "Reacting Nodes." A reporting node requests overload abatement by sending an Overload Report (OLR) to one or more reacting nodes. A reacting node consumes OLRs, and performs whatever actions are needed to fulfill the abatement requests included in the OLRs. A Reporting node may report overload on its own behalf, or on behalf of other (typically upstream) nodes. Likewise, a reacting node may perform overload abatement on its own behalf, or on behalf of other (typically downstream) nodes." Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN= - DE/Munich) Envoy=E9=A0: mercredi 30 juillet 2014 10:41 =C0=A0: ext Steve Donovan; dime@ietf.org Objet=A0: Re: [Dime] Issue #26 proposed resolution Steve, I find the concept of DOIC End Points (and DOIC associations between DOIC E= nd Points) helpful; especially the figures in section 3.1 are useful as the= y show valid scenarios. I, however, agree that more clarifying text is needed to say how nodes dete= ct in wich scenario they actually are. E.g. with regard to figure 2, current text says "... there is an agent that is not participating directly in the exchange = of overload reports." but it is not said how the agent determines that it should/must be transpar= ent. Similarly for other figures. Rather than deleting clause 3.1, I would prefer to add text providing rules= for nodes to detect which of the valid scenarios is actually applicable. P= lease see my proposal of rules A) to F) sent on July 11th. Regards, Ulrich=20=20 -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Tuesday, July 29, 2014 9:55 PM To: dime@ietf.org Subject: [Dime] Issue #26 proposed resolution All, Issue #26 - Overload control endpoints under specified. During the DIME meeting in Toronto the proposal was made to remove the=20 concept of Endpoints and Associations. These concepts were helpful getting the specification to where it is now=20 but a number of us consider the concepts to be confusing at best and=20 potentially misleading. The high level proposal is to remove section 3.1 that talks about=20 Overload Control Endpoints and DOIC Associations. The remainder of the=20 document would then be updated to handle any references to that section=20 and to the concepts of endpoint and association. I've done a quick review of the document and there are a number of=20 places where the term "overload control endpoint" is used. I think most=20 of these can be changed to "overload control node" or "DOIC node" with=20 no additional change needed (other than to define these terms in the=20 terminology section). I want to see if there are any objections to this potential change=20 before doing the work to propose specific wording changes. If there is=20 general agreement then I will come back to the list with detailed=20 proposal for wording changes that would be reflected in the -04 version=20 of the draft. The other option would be to rewrite section 3.1 to have a more concise=20 definition of endpoint, most likely removing the concept of DOIC=20 association. Regards, Steve _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Jul 30 08:19:42 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934051A01EE for ; Wed, 30 Jul 2014 08:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 AW02ve6s7vqA for ; Wed, 30 Jul 2014 08:19:36 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5E01A01EF for ; Wed, 30 Jul 2014 08:18:09 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id A317122D809; Wed, 30 Jul 2014 17:18:07 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 88DD335C0B3; Wed, 30 Jul 2014 17:18:07 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Wed, 30 Jul 2014 17:18:07 +0200 From: To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] meeting minutes uploada Thread-Index: AQHPql7m05i1EW1ypEOzrEC/+XRedpu26/QAgABl1QCAAWxXcA== Date: Wed, 30 Jul 2014 15:18:06 +0000 Message-ID: <31392_1406733487_53D90CAF_31392_9558_1_6B7134B31289DC4FAF731D844122B36E682737@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <53D640F6.5080502@gmail.com> <53D7F720.90503@usdonovans.com> In-Reply-To: <53D7F720.90503@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.30.103920 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iRrE5i8_LuBCufQhLaVyqXFY9dc Subject: Re: [Dime] meeting minutes uploada X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 15:19:38 -0000 More than perfect! :) -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9=A0: mardi 29 juillet 2014 21:34 =C0=A0: dime@ietf.org Objet=A0: Re: [Dime] meeting minutes uploada Dave, My take is that it is clear the DOIC AVPs and behaviors will not be=20 incorporated into the base protocol. I was a little loose in my=20 terminology during the meeting. The goal, at least for me, has been to define a common mechanism for=20 Diameter nodes to exchange Diameter Overload related AVPs, with the=20 necessary behavior defined for the handling of those AVPs. Application specifications will then be updated to reference the DOIC=20 specification. This process has already started in 3GPP, with updates=20 to many of the 3GPP specification already made. It is a measure of our success in defining a common mechanism that can=20 be reused unchanged by Diameter applications that the updates to the=20 application specifications has been a very straight forward process.=20=20 This has consisted primarily of adding the AVPs to the list of=20 application AVPs and referencing of the DOIC specification for behavior=20 associated with those AVPs. Regards, Steve On 7/29/14, 8:29 AM, Dave Dolson wrote: > I'm the "Dave" (Dolson, Dawson, etc.) in the minutes. > > My understanding in the meeting discussion about DOIC was that the DOIC A= VPs will have to be added to application protocols. > In other words, NOT added to the base protocol, and no existing Diameter = agents or end-points will be expected to understand it. > > My reasoning was that abatement is always application-specific, requiring= knowledge of message semantics. > > But from the minutes, that conclusion isn't clear. I may have heard what = I wanted to hear rather than what was actually said... > > So, is the intent to define a new mechanism that may be used with new pro= tocols and protocol updates, or is the intent to put DOIC in the base such = that all protocols automatically inherit it? > > >> Dave - You will get the doc through quicker if you don't explain the >> approaches when you get the AVP. 4006 type applications - ses= sion-based >> applications. Here's one for stateless. > My point here is, just define the AVP and indicate how it should be used,= in the sense of providing design patterns (for stateless, online charging,= offline charging, etc). Then we don't have to debate the corner-cases of t= he abatement algorithms of all applications; we just need to agree on the w= ire format. Then applications can start to reference it, one by one. > > > David Dolson > Senior Software Architect, Sandvine Inc. > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Monday, July 28, 2014 8:24 AM > To: dime@ietf.org > Subject: [Dime] meeting minutes uploada > > Thanks to Jean for extensive minutes & notes: > http://tools.ietf.org/wg/dime/minutes?item=3Dminutes-90-dime.html > > - Jouni > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Jul 30 08:26:01 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717FC1A019B for ; Wed, 30 Jul 2014 08:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 MzL20ldmF5po for ; Wed, 30 Jul 2014 08:25:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0871A0114 for ; Wed, 30 Jul 2014 08:24:37 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id D1CA0325522; Wed, 30 Jul 2014 17:24:35 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id B49E04C0CA; Wed, 30 Jul 2014 17:24:35 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Wed, 30 Jul 2014 17:24:35 +0200 From: To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Issue #23 - Proposed resolution Thread-Index: AQHPq2Jx3rQsneshpEqvUXHZZd+3bZu4vTxA Date: Wed, 30 Jul 2014 15:24:34 +0000 Message-ID: <4485_1406733875_53D90E33_4485_11209_1_6B7134B31289DC4FAF731D844122B36E6827AB@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <53D7F470.3090500@usdonovans.com> In-Reply-To: <53D7F470.3090500@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.30.103920 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/B5gyGKGO692Yg6xVwro6hWLDmrU Subject: Re: [Dime] Issue #23 - Proposed resolution X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 15:25:45 -0000 Hi Steve, As said during the meeting, you can consider this issue as closed. So please take it into account when reviewing the draft. Regards, Lionel=20=20 -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9=A0: mardi 29 juillet 2014 21:22 =C0=A0: dime@ietf.org Objet=A0: [Dime] Issue #23 - Proposed resolution Issue @23 points out that there are two interpretations of the realm=20 overload report in the current text. One implies that a realm report=20 applies to all requests sent to the realm, the other implies that it=20 only applies to requests sent to the realm that does not contain a=20 destination-host AVP. I believe we have consensus to use the second definition. There was also a proposal, made by me, to change the name of the report=20 to something like "realm-routed-request" to be more accurate in defining=20 what the scope of the overload report. I no longer think this is=20 necessary and am happy with the "realm" name for the report. If we have agreement on the direction then I will identify the text that=20 needs to be changed to remove the conflicting definitions of the report=20 type. I will send it to the list for review before incorporating it=20 into the -04 version of the draft and closing the issue. Please let me know if there are issues with this proposal. Regards, Steve _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Jul 30 09:03:19 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859421A00DD for ; Wed, 30 Jul 2014 09:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 i0fbehDkQUUS for ; Wed, 30 Jul 2014 09:03:11 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 49BEB1A0137 for ; Wed, 30 Jul 2014 09:03:11 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0195.001; Wed, 30 Jul 2014 12:03:10 -0400 From: Dave Dolson To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) Thread-Index: AQHPpOYdR9zJJGY8lEarOX8WMqkJU5uqzgGAgAALjoCADB0+gIAAbsyAgAAavYCAAVTRgIAAEooAgAAIGYCAAALKAIAABAYA///FTvCAAEuFgP//zBHg Date: Wed, 30 Jul 2014 16:03:10 +0000 Message-ID: References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> <53D7AA31.3070908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520806A@DEMUMBX014.nsn-intra.net> <53D8DE85.5040201@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668152081C8@DEMUMBX014.nsn-intra.net> <11125_1406727989_53D8F735_11125_1419_1_6B7134B31289DC4FAF731D844122B36E68248A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53D8FA94.6030806@usdonovans.com> <53D908B1.7030404@usdonovans.com> In-Reply-To: <53D908B1.7030404@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.111] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/tejjCXN-hQbmYTsuxEKMOWu8zxg Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 16:03:15 -0000 Sorry for not paying attention... But wouldn't it be simpler and more stable to keep them independent? As you describe, host-routed requests need to consider host load and also r= ealm load,=20 Here is my perspective: 1- when sending a host-routed request, only the load of the destination-hos= t matters. The overall realm load is irrelevant 2- when sending a realm-only-routed request, only the ability of the realm = to accept a new session matters. I believe we've got (2) right by saying that realm-routed abatement does no= t apply to messages with destination-host. -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Wednesday, July 30, 2014 11:01 AM To: Dave Dolson; dime@ietf.org Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime= -ovli-03.txt) Dave, A host report is a request by the reporting node to reduce traffic to=20 that node, regardless of the type of request. In order to achieve that=20 reduction, it is necessary to abate both "host-routed" requests and=20 "realm-routed" request". The first use case in the agent cases draft=20 illustrates this scenario where the client handles abatement of the=20 host-routed requests and the agent that has direct transport connection=20 to the reporting node handles abatement of realm-routed requests. There is no mechanism for the reporting node to request a reduction in=20 host-routed requests separate from realm-routed requests. One of the=20 reasons is that for realm-routed requests there may be other nodes that=20 could handle the request. Steve On 7/30/14, 9:33 AM, Dave Dolson wrote: > Host overload reports should not affect realm-route-requests. > The system will be more stable if the two control systems are independent= , not cross-coupled. > > > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: Wednesday, July 30, 2014 10:01 AM > To: dime@ietf.org > Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-di= me-ovli-03.txt) > > The question is the behavior of a DOIC node that does abatement of > "realm-route-requests" in the face of a host report for a server. > > I think the DOIC specification needs to say that for a DOIC node to do > abatement of realm-routed-requests it needs to be able to guarantee that > the request that survive abatement will be routed to the reporting node > for the host report. This is easy to achieve if the DOIC node has a > direct transport connection to the reporting node. Ulrich's point is > that it can also be achieved by the DOIC node inserting destination-host > for requests targeted for the reporting node that survive abatement. > > Steve > > On 7/30/14, 8:46 AM, lionel.morand@orange.com wrote: >> Hi, >> >> IMHO, node selection is performed when multiple servers are present in t= he realm-routing table for a given realm entry. And if multiple servers are= present in table, it is because multiple connections are available. In fin= e, it is the connection that is selected. No need for an agent to insert th= e Dest-Host AVP in the request. Therefore, I agree that DOICable may/must u= se the overload reports received from the different servers to select the m= ost suitable server, but I agree with Jouni that an agent does not have to = insert Dest-Host AVP. >> >> Lionel >> >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni >> Envoy=E9 : mercredi 30 juillet 2014 15:36 >> =C0 : Wiehe, Ulrich (NSN - DE/Munich) >> Cc : dime@ietf.org >> Objet : Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-di= me-ovli-03.txt) >> >> Ulrich, >> >> I have no problem with DOICable node doing routing/forwarding based on l= oad whatever. But I have an issue an intermediate node adding Destination-H= ost into a request when the client did not originally insert one. I am a bi= t cautious that an agent next to a server can be overruled by other agents = when selecting the server. While this all is still within RFC6733 boundarie= s it is somewhat different than in RFC6733. That's why I have concerns with= this. >> >> Jouni >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Wed Jul 30 09:29:46 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88E61A0300 for ; Wed, 30 Jul 2014 09:29:38 -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, SPF_NEUTRAL=0.779] autolearn=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 1Bxnelmiy-V8 for ; Wed, 30 Jul 2014 09:29:37 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 3A1BB1A02FC for ; Wed, 30 Jul 2014 09:29:36 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:58250 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XCWkv-00055p-78; Wed, 30 Jul 2014 09:29:34 -0700 Message-ID: <53D91D6D.4020309@usdonovans.com> Date: Wed, 30 Jul 2014 11:29:33 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dave Dolson , "dime@ietf.org" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> <53D7AA31.3070908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520806A@DEMUMBX014.nsn-intra.net> <53D8DE85.5040201@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668152081C8@DEMUMBX014.nsn-intra.net> <11125_1406727989_53D8F735_11125_1419_1_6B7134B31289DC4FAF731D844122B36E68248A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53D8FA94.6030806@usdonovans.com> <53D908B1.7030404@usdonovans.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/SCoBFavTf1OrHO98im8mDFJ7StM Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 16:29:39 -0000 Dave, Please see inline. Steve On 7/30/14, 11:03 AM, Dave Dolson wrote: > Sorry for not paying attention... > > But wouldn't it be simpler and more stable to keep them independent? Definitely not simpler. This would require the reporting node, generally a server, to know more than just the its own overload state. A realm-routed request can go to multiple servers, all with different overload states. To send a realm report requires knowledge of all of the servers in the realm. Keeping the reports separate would also require an understanding of the mix of host-routed requests and realm-routed requests, something that is likely to be very dynamic and certainly will be different across applications. The loss algorithm is designed to be very simple. The reporting node requests a percentage reduction of traffic sent to it and the reacting node(s) abate that percentage of traffic sent to the node. > > As you describe, host-routed requests need to consider host load and also realm load, > > Here is my perspective: > 1- when sending a host-routed request, only the load of the destination-host matters. The overall realm load is irrelevant Agreed, mostly. Only the load of the reporting node matters. This still requires reducing all traffic sent to the node, both host-routed and realm-routed requests. > 2- when sending a realm-only-routed request, only the ability of the realm to accept a new session matters. Not necessarily. Realm-routed requests are used for things other than establishing new sessions. There are applications that are not session based, for instance. There are applications that do not require mid session requests to have the destination-host AVP. > > > I believe we've got (2) right by saying that realm-routed abatement does not apply to messages with destination-host. > > > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, July 30, 2014 11:01 AM > To: Dave Dolson; dime@ietf.org > Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) > > Dave, > > A host report is a request by the reporting node to reduce traffic to > that node, regardless of the type of request. In order to achieve that > reduction, it is necessary to abate both "host-routed" requests and > "realm-routed" request". The first use case in the agent cases draft > illustrates this scenario where the client handles abatement of the > host-routed requests and the agent that has direct transport connection > to the reporting node handles abatement of realm-routed requests. > > There is no mechanism for the reporting node to request a reduction in > host-routed requests separate from realm-routed requests. One of the > reasons is that for realm-routed requests there may be other nodes that > could handle the request. > > Steve > > On 7/30/14, 9:33 AM, Dave Dolson wrote: >> Host overload reports should not affect realm-route-requests. >> The system will be more stable if the two control systems are independent, not cross-coupled. >> >> >> >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >> Sent: Wednesday, July 30, 2014 10:01 AM >> To: dime@ietf.org >> Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) >> >> The question is the behavior of a DOIC node that does abatement of >> "realm-route-requests" in the face of a host report for a server. >> >> I think the DOIC specification needs to say that for a DOIC node to do >> abatement of realm-routed-requests it needs to be able to guarantee that >> the request that survive abatement will be routed to the reporting node >> for the host report. This is easy to achieve if the DOIC node has a >> direct transport connection to the reporting node. Ulrich's point is >> that it can also be achieved by the DOIC node inserting destination-host >> for requests targeted for the reporting node that survive abatement. >> >> Steve >> >> On 7/30/14, 8:46 AM, lionel.morand@orange.com wrote: >>> Hi, >>> >>> IMHO, node selection is performed when multiple servers are present in the realm-routing table for a given realm entry. And if multiple servers are present in table, it is because multiple connections are available. In fine, it is the connection that is selected. No need for an agent to insert the Dest-Host AVP in the request. Therefore, I agree that DOICable may/must use the overload reports received from the different servers to select the most suitable server, but I agree with Jouni that an agent does not have to insert Dest-Host AVP. >>> >>> Lionel >>> >>> -----Message d'origine----- >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni >>> Envoyé : mercredi 30 juillet 2014 15:36 >>> À : Wiehe, Ulrich (NSN - DE/Munich) >>> Cc : dime@ietf.org >>> Objet : Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) >>> >>> Ulrich, >>> >>> I have no problem with DOICable node doing routing/forwarding based on load whatever. But I have an issue an intermediate node adding Destination-Host into a request when the client did not originally insert one. I am a bit cautious that an agent next to a server can be overruled by other agents when selecting the server. While this all is still within RFC6733 boundaries it is somewhat different than in RFC6733. That's why I have concerns with this. >>> >>> Jouni >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > From nobody Wed Jul 30 09:31:52 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9421A0086 for ; Wed, 30 Jul 2014 09:31:50 -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, SPF_NEUTRAL=0.779] autolearn=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 YFsYs6O8jbjI for ; Wed, 30 Jul 2014 09:31:50 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 0974E1A0099 for ; Wed, 30 Jul 2014 09:31:50 -0700 (PDT) Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:58256 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XCWn4-00077I-41; Wed, 30 Jul 2014 09:31:47 -0700 Message-ID: <53D91DF2.5070409@usdonovans.com> Date: Wed, 30 Jul 2014 11:31:46 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "dime@ietf.org" References: <53D7F470.3090500@usdonovans.com> <4485_1406733875_53D90E33_4485_11209_1_6B7134B31289DC4FAF731D844122B36E6827AB@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <4485_1406733875_53D90E33_4485_11209_1_6B7134B31289DC4FAF731D844122B36E6827AB@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2_pC5OFueEfVvZHAkBC3oRb8e80 Subject: Re: [Dime] Issue #23 - Proposed resolution X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 16:31:51 -0000 Lionel, I believe it is closed from a conceptual basis but text changes are required before it can be truly considered closed. At least that is the process we have been following to date. I will propose those text changes for review prior to closing the issue. Steve On 7/30/14, 10:24 AM, lionel.morand@orange.com wrote: > Hi Steve, > > As said during the meeting, you can consider this issue as closed. > So please take it into account when reviewing the draft. > > Regards, > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoyé : mardi 29 juillet 2014 21:22 > À : dime@ietf.org > Objet : [Dime] Issue #23 - Proposed resolution > > Issue @23 points out that there are two interpretations of the realm > overload report in the current text. One implies that a realm report > applies to all requests sent to the realm, the other implies that it > only applies to requests sent to the realm that does not contain a > destination-host AVP. > > I believe we have consensus to use the second definition. > > There was also a proposal, made by me, to change the name of the report > to something like "realm-routed-request" to be more accurate in defining > what the scope of the overload report. I no longer think this is > necessary and am happy with the "realm" name for the report. > > If we have agreement on the direction then I will identify the text that > needs to be changed to remove the conflicting definitions of the report > type. I will send it to the list for review before incorporating it > into the -04 version of the draft and closing the issue. > > Please let me know if there are issues with this proposal. > > Regards, > > Steve > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > From nobody Wed Jul 30 09:35:26 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05CE1A01D0 for ; Wed, 30 Jul 2014 09:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 ATWLIm9VuUbW for ; Wed, 30 Jul 2014 09:35:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E881A0084 for ; Wed, 30 Jul 2014 09:35:20 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 881D23B4121; Wed, 30 Jul 2014 18:35:18 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 6E7EE384078; Wed, 30 Jul 2014 18:35:18 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Wed, 30 Jul 2014 18:35:18 +0200 From: To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Issue #23 - Proposed resolution Thread-Index: AQHPq2Jx3rQsneshpEqvUXHZZd+3bZu4vTxA///x+gCAACHCYA== Date: Wed, 30 Jul 2014 16:35:17 +0000 Message-ID: <20099_1406738118_53D91EC6_20099_19198_1_6B7134B31289DC4FAF731D844122B36E682AFE@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <53D7F470.3090500@usdonovans.com> <4485_1406733875_53D90E33_4485_11209_1_6B7134B31289DC4FAF731D844122B36E6827AB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53D91DF2.5070409@usdonovans.com> In-Reply-To: <53D91DF2.5070409@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.30.103920 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/aouPMnzJ11j-Wr8supflzc_KEjo Subject: Re: [Dime] Issue #23 - Proposed resolution X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 16:35:24 -0000 You are right. I was speaking about the discussion on the two possible inte= rpretations of "realm" that it closed now. -----Message d'origine----- De=A0: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Envoy=E9=A0: mercredi 30 juillet 2014 18:32 =C0=A0: MORAND Lionel IMT/OLN; dime@ietf.org Objet=A0: Re: [Dime] Issue #23 - Proposed resolution Lionel, I believe it is closed from a conceptual basis but text changes are=20 required before it can be truly considered closed. At least that is the=20 process we have been following to date. I will propose those text changes for review prior to closing the issue. Steve On 7/30/14, 10:24 AM, lionel.morand@orange.com wrote: > Hi Steve, > > As said during the meeting, you can consider this issue as closed. > So please take it into account when reviewing the draft. > > Regards, > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan > Envoy=E9 : mardi 29 juillet 2014 21:22 > =C0 : dime@ietf.org > Objet : [Dime] Issue #23 - Proposed resolution > > Issue @23 points out that there are two interpretations of the realm > overload report in the current text. One implies that a realm report > applies to all requests sent to the realm, the other implies that it > only applies to requests sent to the realm that does not contain a > destination-host AVP. > > I believe we have consensus to use the second definition. > > There was also a proposal, made by me, to change the name of the report > to something like "realm-routed-request" to be more accurate in defining > what the scope of the overload report. I no longer think this is > necessary and am happy with the "realm" name for the report. > > If we have agreement on the direction then I will identify the text that > needs to be changed to remove the conflicting definitions of the report > type. I will send it to the list for review before incorporating it > into the -04 version of the draft and closing the issue. > > Please let me know if there are issues with this proposal. > > Regards, > > Steve > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Jul 30 13:04:34 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFEC1A0386 for ; Wed, 30 Jul 2014 13:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 3XOM4gsmBSfF for ; Wed, 30 Jul 2014 13:04:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5F8AE1A0359 for ; Wed, 30 Jul 2014 13:04:27 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6UK4Oqh056161 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jul 2014 15:04:25 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <21807_1406732974_53D90AAE_21807_8763_1_6B7134B31289DC4FAF731D844122B36E6826D2@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Wed, 30 Jul 2014 15:04:23 -0500 X-Mao-Original-Outgoing-Id: 428443463.215084-b29b571ab630226d996f1fd9215fbb2a Content-Transfer-Encoding: quoted-printable Message-Id: <0B0F1739-45A6-43F2-A3E7-F56883C803B6@nostrum.com> References: <53D7FC1B.8070708@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520812B@DEMUMBX014.nsn-intra.net> <21807_1406732974_53D90AAE_21807_8763_1_6B7134B31289DC4FAF731D844122B36E6826D2@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/x5Z-hXbdgJA8Ydtuq12XcPdWqWo Cc: "dime@ietf.org" Subject: Re: [Dime] Issue #26 proposed resolution X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 20:04:30 -0000 I concur. "Association" is an abstract concept that isn't needed to = explain behavior. The specification should be about behavior. On Jul 30, 2014, at 10:09 AM, lionel.morand@orange.com wrote: > The concept of DOIC endpoint is introduced in section 3. > I share the view that the section 3.1 can be removed. And the figures = do not provide real added-values after saying in the introduction: >=20 > "Any Diameter node can act as a DOIC endpoint, including clients, > servers, and agents. DOIC endpoints are further divided into > "Reporting Nodes" and "Reacting Nodes." A reporting node requests > overload abatement by sending an Overload Report (OLR) to one or = more > reacting nodes. >=20 > A reacting node consumes OLRs, and performs whatever actions are > needed to fulfill the abatement requests included in the OLRs. A > Reporting node may report overload on its own behalf, or on behalf = of > other (typically upstream) nodes. Likewise, a reacting node may > perform overload abatement on its own behalf, or on behalf of other > (typically downstream) nodes." >=20 > Lionel >=20 From nobody Wed Jul 30 13:19:51 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851311A026E for ; Wed, 30 Jul 2014 13:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 oYSfd-7Jdu-t for ; Wed, 30 Jul 2014 13:19:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A54EF1A00D4 for ; Wed, 30 Jul 2014 13:19:47 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6UKJj67057405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jul 2014 15:19:46 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53D7F720.90503@usdonovans.com> Date: Wed, 30 Jul 2014 15:19:44 -0500 X-Mao-Original-Outgoing-Id: 428444384.254902-a8131d0ec7d36cbf9f2c7a6fdd9d8329 Content-Transfer-Encoding: quoted-printable Message-Id: <8374EACC-ACF7-4B22-9AD3-C174A890479F@nostrum.com> References: <53D640F6.5080502@gmail.com> <53D7F720.90503@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/zxSDobl4j6CLIbtSn-bg5y5kAAs Cc: dime@ietf.org Subject: [Dime] DOIC: Base protocol vs application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 20:19:49 -0000 I'm not sure I agree. I think we may be skirting the first sentence in = Req 2, quoted here: > REQ 2: The solution MUST allow Diameter nodes to support overload > control regardless of which Diameter applications they > support. Diameter clients and agents must be able to use = the > received load and overload information to support graceful > behavior during an overload condition. Graceful behavior > under overload conditions is best described by REQ 3. >=20 The word "node" was carefully selected. If an agent with no knowledge of = the "foo" application cannot apply DOIC to messages for "foo", then we = have failed to meet that requirement. Allowing that implies that DOIC AVPs mean the same for all applications, = and can be inserted into messages for any application without a new = specification for that application. That's a stronger statement than = just saying any application can incorporate them. This seems to mean = they need to be part of the base specification. That all being said, I agree that often will be beneficial to explicitly = incorporate DOIC into applications, so that one can make = application-specific statements about things like detecting overload, = message prioritization under overload, and client application behavior = under overload. On Jul 29, 2014, at 2:33 PM, Steve Donovan = wrote: > Dave, >=20 > My take is that it is clear the DOIC AVPs and behaviors will not be = incorporated into the base protocol. I was a little loose in my = terminology during the meeting. >=20 > The goal, at least for me, has been to define a common mechanism for = Diameter nodes to exchange Diameter Overload related AVPs, with the = necessary behavior defined for the handling of those AVPs. >=20 > Application specifications will then be updated to reference the DOIC = specification. This process has already started in 3GPP, with updates = to many of the 3GPP specification already made. >=20 > It is a measure of our success in defining a common mechanism that can = be reused unchanged by Diameter applications that the updates to the = application specifications has been a very straight forward process. = This has consisted primarily of adding the AVPs to the list of = application AVPs and referencing of the DOIC specification for behavior = associated with those AVPs. >=20 > Regards, >=20 > Steve >=20 > On 7/29/14, 8:29 AM, Dave Dolson wrote: >> I'm the "Dave" (Dolson, Dawson, etc.) in the minutes. >>=20 >> My understanding in the meeting discussion about DOIC was that the = DOIC AVPs will have to be added to application protocols. >> In other words, NOT added to the base protocol, and no existing = Diameter agents or end-points will be expected to understand it. >>=20 >> My reasoning was that abatement is always application-specific, = requiring knowledge of message semantics. >>=20 >> But from the minutes, that conclusion isn't clear. I may have heard = what I wanted to hear rather than what was actually said... >>=20 >> So, is the intent to define a new mechanism that may be used with new = protocols and protocol updates, or is the intent to put DOIC in the base = such that all protocols automatically inherit it? >>=20 >>=20 >>> Dave - You will get the doc through quicker if you don't explain the >>> approaches when you get the AVP. 4006 type applications - = session-based >>> applications. Here's one for stateless. >> My point here is, just define the AVP and indicate how it should be = used, in the sense of providing design patterns (for stateless, online = charging, offline charging, etc). Then we don't have to debate the = corner-cases of the abatement algorithms of all applications; we just = need to agree on the wire format. Then applications can start to = reference it, one by one. >>=20 >>=20 >> David Dolson >> Senior Software Architect, Sandvine Inc. >>=20 >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >> Sent: Monday, July 28, 2014 8:24 AM >> To: dime@ietf.org >> Subject: [Dime] meeting minutes uploada >>=20 >> Thanks to Jean for extensive minutes & notes: >> http://tools.ietf.org/wg/dime/minutes?item=3Dminutes-90-dime.html >>=20 >> - Jouni >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed Jul 30 13:20:39 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953FD1A032C for ; Wed, 30 Jul 2014 13:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 gcCuAPCHU0jh for ; Wed, 30 Jul 2014 13:20:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 001551A0326 for ; Wed, 30 Jul 2014 13:20:35 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6UKJj68057405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jul 2014 15:20:35 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53D7F470.3090500@usdonovans.com> Date: Wed, 30 Jul 2014 15:20:34 -0500 X-Mao-Original-Outgoing-Id: 428444433.9985-83766e25f789b7707e6fae08da93bb7a Content-Transfer-Encoding: quoted-printable Message-Id: <5844172E-11E4-457A-9854-F01722402C3F@nostrum.com> References: <53D7F470.3090500@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KpCeWBYGmDzXq70V6obe-SdBheE Cc: "dime@ietf.org" Subject: Re: [Dime] Issue #23 - Proposed resolution X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 20:20:37 -0000 I concur. On Jul 29, 2014, at 2:22 PM, Steve Donovan = wrote: > Issue @23 points out that there are two interpretations of the realm = overload report in the current text. One implies that a realm report = applies to all requests sent to the realm, the other implies that it = only applies to requests sent to the realm that does not contain a = destination-host AVP. >=20 > I believe we have consensus to use the second definition. >=20 > There was also a proposal, made by me, to change the name of the = report to something like "realm-routed-request" to be more accurate in = defining what the scope of the overload report. I no longer think this = is necessary and am happy with the "realm" name for the report. >=20 > If we have agreement on the direction then I will identify the text = that needs to be changed to remove the conflicting definitions of the = report type. I will send it to the list for review before incorporating = it into the -04 version of the draft and closing the issue. >=20 > Please let me know if there are issues with this proposal. >=20 > Regards, >=20 > Steve >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed Jul 30 13:22:42 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0194C1A036F for ; Wed, 30 Jul 2014 13:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 IHuuS0aYvg3E for ; Wed, 30 Jul 2014 13:22:38 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 B2E5E1A0326 for ; Wed, 30 Jul 2014 13:22:38 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6UKMamv057718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jul 2014 15:22:38 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <8374EACC-ACF7-4B22-9AD3-C174A890479F@nostrum.com> Date: Wed, 30 Jul 2014 15:22:35 -0500 X-Mao-Original-Outgoing-Id: 428444555.597207-93e71a20a5b4969ac65286757fbd2e4c Content-Transfer-Encoding: quoted-printable Message-Id: References: <53D640F6.5080502@gmail.com> <53D7F720.90503@usdonovans.com> <8374EACC-ACF7-4B22-9AD3-C174A890479F@nostrum.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dqaHfwUsjepBfbJWq4bUAKkoA1M Cc: dime@ietf.org Subject: Re: [Dime] DOIC: Base protocol vs application (was: meeting minutes uploaded) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 20:22:41 -0000 (oops, I meant to comment on the changed subect line, and to to add = "was: meeting minutes uploaded" to the new subject. Fixed here.) On Jul 30, 2014, at 3:19 PM, Ben Campbell wrote: >=20 > I'm not sure I agree. I think we may be skirting the first sentence in = Req 2, quoted here: >=20 >> REQ 2: The solution MUST allow Diameter nodes to support overload >> control regardless of which Diameter applications they >> support. Diameter clients and agents must be able to use = the >> received load and overload information to support graceful >> behavior during an overload condition. Graceful behavior >> under overload conditions is best described by REQ 3. >>=20 >=20 > The word "node" was carefully selected. If an agent with no knowledge = of the "foo" application cannot apply DOIC to messages for "foo", then = we have failed to meet that requirement. >=20 > Allowing that implies that DOIC AVPs mean the same for all = applications, and can be inserted into messages for any application = without a new specification for that application. That's a stronger = statement than just saying any application can incorporate them. This = seems to mean they need to be part of the base specification. >=20 > That all being said, I agree that often will be beneficial to = explicitly incorporate DOIC into applications, so that one can make = application-specific statements about things like detecting overload, = message prioritization under overload, and client application behavior = under overload. >=20 > On Jul 29, 2014, at 2:33 PM, Steve Donovan = wrote: >=20 >> Dave, >>=20 >> My take is that it is clear the DOIC AVPs and behaviors will not be = incorporated into the base protocol. I was a little loose in my = terminology during the meeting. >>=20 >> The goal, at least for me, has been to define a common mechanism for = Diameter nodes to exchange Diameter Overload related AVPs, with the = necessary behavior defined for the handling of those AVPs. >>=20 >> Application specifications will then be updated to reference the DOIC = specification. This process has already started in 3GPP, with updates = to many of the 3GPP specification already made. >>=20 >> It is a measure of our success in defining a common mechanism that = can be reused unchanged by Diameter applications that the updates to the = application specifications has been a very straight forward process. = This has consisted primarily of adding the AVPs to the list of = application AVPs and referencing of the DOIC specification for behavior = associated with those AVPs. >>=20 >> Regards, >>=20 >> Steve >>=20 >> On 7/29/14, 8:29 AM, Dave Dolson wrote: >>> I'm the "Dave" (Dolson, Dawson, etc.) in the minutes. >>>=20 >>> My understanding in the meeting discussion about DOIC was that the = DOIC AVPs will have to be added to application protocols. >>> In other words, NOT added to the base protocol, and no existing = Diameter agents or end-points will be expected to understand it. >>>=20 >>> My reasoning was that abatement is always application-specific, = requiring knowledge of message semantics. >>>=20 >>> But from the minutes, that conclusion isn't clear. I may have heard = what I wanted to hear rather than what was actually said... >>>=20 >>> So, is the intent to define a new mechanism that may be used with = new protocols and protocol updates, or is the intent to put DOIC in the = base such that all protocols automatically inherit it? >>>=20 >>>=20 >>>> Dave - You will get the doc through quicker if you don't explain = the >>>> approaches when you get the AVP. 4006 type applications - = session-based >>>> applications. Here's one for stateless. >>> My point here is, just define the AVP and indicate how it should be = used, in the sense of providing design patterns (for stateless, online = charging, offline charging, etc). Then we don't have to debate the = corner-cases of the abatement algorithms of all applications; we just = need to agree on the wire format. Then applications can start to = reference it, one by one. >>>=20 >>>=20 >>> David Dolson >>> Senior Software Architect, Sandvine Inc. >>>=20 >>>=20 >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni = Korhonen >>> Sent: Monday, July 28, 2014 8:24 AM >>> To: dime@ietf.org >>> Subject: [Dime] meeting minutes uploada >>>=20 >>> Thanks to Jean for extensive minutes & notes: >>> http://tools.ietf.org/wg/dime/minutes?item=3Dminutes-90-dime.html >>>=20 >>> - Jouni >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed Jul 30 13:43:07 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91AB01A0144 for ; Wed, 30 Jul 2014 13:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 MW-SddyQz6QN for ; Wed, 30 Jul 2014 13:43:02 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8D4BA1A0125 for ; Wed, 30 Jul 2014 13:43:02 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6UKh0Ve059319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Jul 2014 15:43:01 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53D8FA94.6030806@usdonovans.com> Date: Wed, 30 Jul 2014 15:42:59 -0500 X-Mao-Original-Outgoing-Id: 428445779.487043-10a8da5b9f483d67b6c4a4eeb80ae080 Content-Transfer-Encoding: quoted-printable Message-Id: <4638F3D4-F0B5-4000-B7C7-C7DC45092474@nostrum.com> References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> <53D7AA31.3070908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520806A@DEMUMBX014.nsn-intra.net> <53D8DE85.5040201@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668152081C8@DEMUMBX014.nsn-intra.net> <11125_1406727989_53D8F735_11125_1419_1_6B7134B31289DC4FAF731D844122B36E68248A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53D8FA94.6030806@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kXfSILGGGoLuQCDtDshucLFc5p0 Cc: dime@ietf.org Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2014 20:43:04 -0000 While I don't think we should forbid an intermediate agent directing = messages to specific servers using Destination-Host, I don't think we = should suggest that it's a good idea. Assuming people see this as away = around the proposed guidance to avoid having a non-DOIC agent in the = "last-peer-before-server" position, it has some pretty severe = limitations: 1) It only works if the intermediate server knows what servers it can = choose among. (And it should probably also know current load state for = them.) While you can build networks that way, you do so at the expense = of flexibility and manageability. 2) There's no way to say things like "Don't send this to server A, but = any other server is okay". That means the intermediate server completely = owns server selection for all requests during the overload event. Even = ones that don't get diverted. Otherwise, the upstream agent will = redistribute those "non-diverted" requests however it wants to, and that = is not likely to match what the DOIC-supporting intermediary wants to = do. 3) It doesn't solve the situation where a node thinks it is selecting = servers, but some or all of those servers are really topology-hiding = agents, which seems like the biggest reason we would can't normatively = limit diversion to directly-connected agents. On Jul 30, 2014, at 9:00 AM, Steve Donovan = wrote: > The question is the behavior of a DOIC node that does abatement of = "realm-route-requests" in the face of a host report for a server. >=20 > I think the DOIC specification needs to say that for a DOIC node to do = abatement of realm-routed-requests it needs to be able to guarantee that = the request that survive abatement will be routed to the reporting node = for the host report. This is easy to achieve if the DOIC node has a = direct transport connection to the reporting node. Ulrich's point is = that it can also be achieved by the DOIC node inserting destination-host = for requests targeted for the reporting node that survive abatement. >=20 > Steve >=20 > On 7/30/14, 8:46 AM, lionel.morand@orange.com wrote: >> Hi, >>=20 >> IMHO, node selection is performed when multiple servers are present = in the realm-routing table for a given realm entry. And if multiple = servers are present in table, it is because multiple connections are = available. In fine, it is the connection that is selected. No need for = an agent to insert the Dest-Host AVP in the request. Therefore, I agree = that DOICable may/must use the overload reports received from the = different servers to select the most suitable server, but I agree with = Jouni that an agent does not have to insert Dest-Host AVP. >>=20 >> Lionel >>=20 >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni >> Envoy=E9 : mercredi 30 juillet 2014 15:36 >> =C0 : Wiehe, Ulrich (NSN - DE/Munich) >> Cc : dime@ietf.org >> Objet : Re: [Dime] Transparent agents (was Re: I-D Action: = draft-ietf-dime-ovli-03.txt) >>=20 >> Ulrich, >>=20 >> I have no problem with DOICable node doing routing/forwarding based = on load whatever. But I have an issue an intermediate node adding = Destination-Host into a request when the client did not originally = insert one. I am a bit cautious that an agent next to a server can be = overruled by other agents when selecting the server. While this all is = still within RFC6733 boundaries it is somewhat different than in = RFC6733. That's why I have concerns with this. >>=20 >> Jouni >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Wed Jul 30 23:22:11 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F9A1A0251 for ; Wed, 30 Jul 2014 23:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 QsYOPQWtZ0sE for ; Wed, 30 Jul 2014 23:22:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E8341A0062 for ; Wed, 30 Jul 2014 23:22:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKS96428; Thu, 31 Jul 2014 06:22:04 +0000 (GMT) Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 31 Jul 2014 07:22:03 +0100 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.49]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Thu, 31 Jul 2014 14:21:55 +0800 From: "Shishufeng (Susan)" To: Dave Dolson , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) Thread-Index: AQHPrBOcOZOpLF6tyUyYdfm4aZoW0Ju5oEfw Date: Thu, 31 Jul 2014 06:21:54 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F258DF61421@SZXEMA512-MBX.china.huawei.com> References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> <53D7AA31.3070908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520806A@DEMUMBX014.nsn-intra.net> <53D8DE85.5040201@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668152081C8@DEMUMBX014.nsn-intra.net> <11125_1406727989_53D8F735_11125_1419_1_6B7134B31289DC4FAF731D844122B36E68248A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53D8FA94.6030806@usdonovans.com> <53D908B1.7030404@usdonovans.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.62.57] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dime/DTlRS52fHVSPnkszXLuNc6lLfFU Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 06:22:10 -0000 Hello, I support Dave's view on the host-routed request and realm-routed request. = There is no need for the reacting node to mix two reports, since host-route= d request cannot be routed to other servers. Realm-routed overload report i= s only useful for the message without specific Destination-Host present. Best Regards, Susan -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com]=20 Sent: Thursday, July 31, 2014 12:03 AM To: Steve Donovan; dime@ietf.org Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime= -ovli-03.txt) Sorry for not paying attention... But wouldn't it be simpler and more stable to keep them independent? As you describe, host-routed requests need to consider host load and also r= ealm load,=20 Here is my perspective: 1- when sending a host-routed request, only the load of the destination-hos= t matters. The overall realm load is irrelevant 2- when sending a realm-only-routed request, only the ability of the realm = to accept a new session matters. I believe we've got (2) right by saying that realm-routed abatement does no= t apply to messages with destination-host. -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Wednesday, July 30, 2014 11:01 AM To: Dave Dolson; dime@ietf.org Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime= -ovli-03.txt) Dave, A host report is a request by the reporting node to reduce traffic to that = node, regardless of the type of request. In order to achieve that reductio= n, it is necessary to abate both "host-routed" requests and "realm-routed" = request". The first use case in the agent cases draft illustrates this sce= nario where the client handles abatement of the host-routed requests and th= e agent that has direct transport connection to the reporting node handles = abatement of realm-routed requests. There is no mechanism for the reporting node to request a reduction in host= -routed requests separate from realm-routed requests. One of the reasons i= s that for realm-routed requests there may be other nodes that could handle= the request. Steve On 7/30/14, 9:33 AM, Dave Dolson wrote: > Host overload reports should not affect realm-route-requests. > The system will be more stable if the two control systems are independent= , not cross-coupled. > > > > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: Wednesday, July 30, 2014 10:01 AM > To: dime@ietf.org > Subject: Re: [Dime] Transparent agents (was Re: I-D Action:=20 > draft-ietf-dime-ovli-03.txt) > > The question is the behavior of a DOIC node that does abatement of=20 > "realm-route-requests" in the face of a host report for a server. > > I think the DOIC specification needs to say that for a DOIC node to do=20 > abatement of realm-routed-requests it needs to be able to guarantee=20 > that the request that survive abatement will be routed to the=20 > reporting node for the host report. This is easy to achieve if the=20 > DOIC node has a direct transport connection to the reporting node. =20 > Ulrich's point is that it can also be achieved by the DOIC node=20 > inserting destination-host for requests targeted for the reporting node t= hat survive abatement. > > Steve > > On 7/30/14, 8:46 AM, lionel.morand@orange.com wrote: >> Hi, >> >> IMHO, node selection is performed when multiple servers are present in t= he realm-routing table for a given realm entry. And if multiple servers are= present in table, it is because multiple connections are available. In fin= e, it is the connection that is selected. No need for an agent to insert th= e Dest-Host AVP in the request. Therefore, I agree that DOICable may/must u= se the overload reports received from the different servers to select the m= ost suitable server, but I agree with Jouni that an agent does not have to = insert Dest-Host AVP. >> >> Lionel >> >> -----Message d'origine----- >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Envoy=E9 := =20 >> mercredi 30 juillet 2014 15:36 =C0 : Wiehe, Ulrich (NSN - DE/Munich) Cc= =20 >> : dime@ietf.org Objet : Re: [Dime] Transparent agents (was Re: I-D=20 >> Action: draft-ietf-dime-ovli-03.txt) >> >> Ulrich, >> >> I have no problem with DOICable node doing routing/forwarding based on l= oad whatever. But I have an issue an intermediate node adding Destination-H= ost into a request when the client did not originally insert one. I am a bi= t cautious that an agent next to a server can be overruled by other agents = when selecting the server. While this all is still within RFC6733 boundarie= s it is somewhat different than in RFC6733. That's why I have concerns with= this. >> >> Jouni >> > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Wed Jul 30 23:33:37 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B161A031C for ; Wed, 30 Jul 2014 23:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 b4AmtPUQud7k for ; Wed, 30 Jul 2014 23:33:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9321A0308 for ; Wed, 30 Jul 2014 23:33:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKS97526; Thu, 31 Jul 2014 06:33:18 +0000 (GMT) Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 31 Jul 2014 07:33:18 +0100 Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.49]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Thu, 31 Jul 2014 14:33:06 +0800 From: "Shishufeng (Susan)" To: Steve Donovan , Dave Dolson , "dime@ietf.org" Thread-Topic: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) Thread-Index: AQHPrBOcOZOpLF6tyUyYdfm4aZoW0Ju5uHJg Date: Thu, 31 Jul 2014 06:33:06 +0000 Message-ID: <26C84DFD55BC3040A45BF70926E55F258DF61431@SZXEMA512-MBX.china.huawei.com> References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> <53D7AA31.3070908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520806A@DEMUMBX014.nsn-intra.net> <53D8DE85.5040201@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668152081C8@DEMUMBX014.nsn-intra.net> <11125_1406727989_53D8F735_11125_1419_1_6B7134B31289DC4FAF731D844122B36E68248A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53D8FA94.6030806@usdonovans.com> <53D908B1.7030404@usdonovans.com> <53D91D6D.4020309@usdonovans.com> In-Reply-To: <53D91D6D.4020309@usdonovans.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.146.62.57] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dime/K2smE54VD9SZ6ASyquXGVOSLtPg Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 06:33:36 -0000 Hello Dave, My view is that the server only cares about its own overload state, there i= s no need for a server to know the overload status of the realm, which shou= ld be the responsibility of the agent serving a server farm. If the reacting node is unable to know the destination-host of the request,= the request will be treated as realm-routed messages and realm-routed repo= rt will be applied, whatever the request is session related or not, first m= essage or mid-session request. Best Regards, Susan -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Thursday, July 31, 2014 12:30 AM To: Dave Dolson; dime@ietf.org Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime= -ovli-03.txt) Dave, Please see inline. Steve On 7/30/14, 11:03 AM, Dave Dolson wrote: > Sorry for not paying attention... > > But wouldn't it be simpler and more stable to keep them independent? Definitely not simpler. This would require the reporting node, generally a= server, to know more than just the its own overload state. =20 A realm-routed request can go to multiple servers, all with different overl= oad states. To send a realm report requires knowledge of all of the server= s in the realm. Keeping the reports separate would also require an underst= anding of the mix of host-routed requests and realm-routed requests, someth= ing that is likely to be very dynamic and certainly will be different acros= s applications. The loss algorithm is designed to be very simple. The reporting node reque= sts a percentage reduction of traffic sent to it and the reacting node(s) abate that percentage of traffic sent to the node. > > As you describe, host-routed requests need to consider host load and=20 > also realm load, > > Here is my perspective: > 1- when sending a host-routed request, only the load of the=20 > destination-host matters. The overall realm load is irrelevant Agreed, mostly. Only the load of the reporting node matters. This still r= equires reducing all traffic sent to the node, both host-routed and realm-r= outed requests. > 2- when sending a realm-only-routed request, only the ability of the real= m to accept a new session matters. Not necessarily. Realm-routed requests are used for things other than esta= blishing new sessions. There are applications that are not session based, = for instance. There are applications that do not require mid session reque= sts to have the destination-host AVP. > > > I believe we've got (2) right by saying that realm-routed abatement does = not apply to messages with destination-host. > > > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, July 30, 2014 11:01 AM > To: Dave Dolson; dime@ietf.org > Subject: Re: [Dime] Transparent agents (was Re: I-D Action:=20 > draft-ietf-dime-ovli-03.txt) > > Dave, > > A host report is a request by the reporting node to reduce traffic to=20 > that node, regardless of the type of request. In order to achieve=20 > that reduction, it is necessary to abate both "host-routed" requests=20 > and "realm-routed" request". The first use case in the agent cases=20 > draft illustrates this scenario where the client handles abatement of=20 > the host-routed requests and the agent that has direct transport=20 > connection to the reporting node handles abatement of realm-routed reques= ts. > > There is no mechanism for the reporting node to request a reduction in=20 > host-routed requests separate from realm-routed requests. One of the=20 > reasons is that for realm-routed requests there may be other nodes=20 > that could handle the request. > > Steve > > On 7/30/14, 9:33 AM, Dave Dolson wrote: >> Host overload reports should not affect realm-route-requests. >> The system will be more stable if the two control systems are independen= t, not cross-coupled. >> >> >> >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >> Sent: Wednesday, July 30, 2014 10:01 AM >> To: dime@ietf.org >> Subject: Re: [Dime] Transparent agents (was Re: I-D Action:=20 >> draft-ietf-dime-ovli-03.txt) >> >> The question is the behavior of a DOIC node that does abatement of=20 >> "realm-route-requests" in the face of a host report for a server. >> >> I think the DOIC specification needs to say that for a DOIC node to=20 >> do abatement of realm-routed-requests it needs to be able to=20 >> guarantee that the request that survive abatement will be routed to=20 >> the reporting node for the host report. This is easy to achieve if=20 >> the DOIC node has a direct transport connection to the reporting=20 >> node. Ulrich's point is that it can also be achieved by the DOIC=20 >> node inserting destination-host for requests targeted for the reporting = node that survive abatement. >> >> Steve >> >> On 7/30/14, 8:46 AM, lionel.morand@orange.com wrote: >>> Hi, >>> >>> IMHO, node selection is performed when multiple servers are present in = the realm-routing table for a given realm entry. And if multiple servers ar= e present in table, it is because multiple connections are available. In fi= ne, it is the connection that is selected. No need for an agent to insert t= he Dest-Host AVP in the request. Therefore, I agree that DOICable may/must = use the overload reports received from the different servers to select the = most suitable server, but I agree with Jouni that an agent does not have to= insert Dest-Host AVP. >>> >>> Lionel >>> >>> -----Message d'origine----- >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Envoy=E9=20 >>> : mercredi 30 juillet 2014 15:36 =C0 : Wiehe, Ulrich (NSN - DE/Munich)= =20 >>> Cc : dime@ietf.org Objet : Re: [Dime] Transparent agents (was Re:=20 >>> I-D Action: draft-ietf-dime-ovli-03.txt) >>> >>> Ulrich, >>> >>> I have no problem with DOICable node doing routing/forwarding based on = load whatever. But I have an issue an intermediate node adding Destination-= Host into a request when the client did not originally insert one. I am a b= it cautious that an agent next to a server can be overruled by other agents= when selecting the server. While this all is still within RFC6733 boundari= es it is somewhat different than in RFC6733. That's why I have concerns wit= h this. >>> >>> Jouni >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > From nobody Thu Jul 31 00:03:34 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721421A037D for ; Thu, 31 Jul 2014 00:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 ut2Xv4KOfYPm for ; Thu, 31 Jul 2014 00:03:30 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C51981A036F for ; Thu, 31 Jul 2014 00:03:29 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id hz20so1667891lab.8 for ; Thu, 31 Jul 2014 00:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Sg8n2QJWohi63bxlNsr14zEkx3NiCWk1R/YSvza00K8=; b=wCV5Z4T5iR7zfkvrAoVEtLtHCOJjdc/BzuKS9XnxGDGNNRnVWqEfo+GTbMLyGT/KKb lurqLU3L+Bg1Sz7F9poxm9spoq/rLtsKVD7eBFJYHqvrUD5wAOYdu02edHItA6FIqsmL VktUHsVlr/va/9hHd0oBuSRsL3mF+WICBBHUmE3UH5402rJIDU3o/x5cihaet407uFM2 3Vfh/FI7+QEcNLCvUUE4gZO6qExxDddPKZYSIVIgNu3UNVBrwijOgkMCIbfjdquwII9S fV0K5KMKTW6RjmW+GCJwkmqCuTvJs6gH479WxAlWzmFAg0LAiFY69zwHIlQmDEd+KGcQ fLug== X-Received: by 10.152.207.36 with SMTP id lt4mr10093471lac.72.1406790207739; Thu, 31 Jul 2014 00:03:27 -0700 (PDT) Received: from [10.17.0.21] ([83.150.126.201]) by mx.google.com with ESMTPSA id tg1sm6996874lbb.11.2014.07.31.00.03.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jul 2014 00:03:26 -0700 (PDT) Message-ID: <53D9EA3C.5080301@gmail.com> Date: Thu, 31 Jul 2014 10:03:24 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Campbell , Steve Donovan References: <53D640F6.5080502@gmail.com> <53D7F720.90503@usdonovans.com> <8374EACC-ACF7-4B22-9AD3-C174A890479F@nostrum.com> In-Reply-To: <8374EACC-ACF7-4B22-9AD3-C174A890479F@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/G1yT0FLrQXxkvlsFX61h9QQIQFg Cc: dime@ietf.org Subject: Re: [Dime] DOIC: Base protocol vs application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 07:03:32 -0000 Ben, 7/30/2014 11:19 PM, Ben Campbell kirjoitti: > > I'm not sure I agree. I think we may be skirting the first sentence in Req 2, quoted here: > >> REQ 2: The solution MUST allow Diameter nodes to support overload >> control regardless of which Diameter applications they >> support. Diameter clients and agents must be able to use the >> received load and overload information to support graceful >> behavior during an overload condition. Graceful behavior >> under overload conditions is best described by REQ 3. >> > > The word "node" was carefully selected. If an agent with no knowledge of the "foo" application cannot apply DOIC to messages for "foo", then we have failed to meet that requirement. In this requirement the "node" does not apply to proxies. A proxy won't even receive messages for the "foo" application unless it advertises one. And if the proxy advertises a specific application it implicitly supports one. - Jouni > > Allowing that implies that DOIC AVPs mean the same for all applications, and can be inserted into messages for any application without a new specification for that application. That's a stronger statement than just saying any application can incorporate them. This seems to mean they need to be part of the base specification. > > That all being said, I agree that often will be beneficial to explicitly incorporate DOIC into applications, so that one can make application-specific statements about things like detecting overload, message prioritization under overload, and client application behavior under overload. > > On Jul 29, 2014, at 2:33 PM, Steve Donovan wrote: > >> Dave, >> >> My take is that it is clear the DOIC AVPs and behaviors will not be incorporated into the base protocol. I was a little loose in my terminology during the meeting. >> >> The goal, at least for me, has been to define a common mechanism for Diameter nodes to exchange Diameter Overload related AVPs, with the necessary behavior defined for the handling of those AVPs. >> >> Application specifications will then be updated to reference the DOIC specification. This process has already started in 3GPP, with updates to many of the 3GPP specification already made. >> >> It is a measure of our success in defining a common mechanism that can be reused unchanged by Diameter applications that the updates to the application specifications has been a very straight forward process. This has consisted primarily of adding the AVPs to the list of application AVPs and referencing of the DOIC specification for behavior associated with those AVPs. >> >> Regards, >> >> Steve >> >> On 7/29/14, 8:29 AM, Dave Dolson wrote: >>> I'm the "Dave" (Dolson, Dawson, etc.) in the minutes. >>> >>> My understanding in the meeting discussion about DOIC was that the DOIC AVPs will have to be added to application protocols. >>> In other words, NOT added to the base protocol, and no existing Diameter agents or end-points will be expected to understand it. >>> >>> My reasoning was that abatement is always application-specific, requiring knowledge of message semantics. >>> >>> But from the minutes, that conclusion isn't clear. I may have heard what I wanted to hear rather than what was actually said... >>> >>> So, is the intent to define a new mechanism that may be used with new protocols and protocol updates, or is the intent to put DOIC in the base such that all protocols automatically inherit it? >>> >>> >>>> Dave - You will get the doc through quicker if you don't explain the >>>> approaches when you get the AVP. 4006 type applications - session-based >>>> applications. Here's one for stateless. >>> My point here is, just define the AVP and indicate how it should be used, in the sense of providing design patterns (for stateless, online charging, offline charging, etc). Then we don't have to debate the corner-cases of the abatement algorithms of all applications; we just need to agree on the wire format. Then applications can start to reference it, one by one. >>> >>> >>> David Dolson >>> Senior Software Architect, Sandvine Inc. >>> >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >>> Sent: Monday, July 28, 2014 8:24 AM >>> To: dime@ietf.org >>> Subject: [Dime] meeting minutes uploada >>> >>> Thanks to Jean for extensive minutes & notes: >>> http://tools.ietf.org/wg/dime/minutes?item=minutes-90-dime.html >>> >>> - Jouni >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Thu Jul 31 00:08:06 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1501A0381 for ; Thu, 31 Jul 2014 00:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Nx3q0AqlUvFj for ; Thu, 31 Jul 2014 00:07:52 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1651A0375 for ; Thu, 31 Jul 2014 00:07:52 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id s7so1688520lbd.14 for ; Thu, 31 Jul 2014 00:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=6mkICNKyu6IcDlsLQkWBEY3xDMOJEQYKe9k6WnxtwLU=; b=yWVITsClFWHTlzTS+G2Fozqry6Ou7+cYU+Hj5kqNqEFwquQvlwiqT7qy8qjiXtNSPy eLo/N7HvWL4x6JSo5JQqoqq97gqMskskm51mdIjNULPGpUt9oxdFBKcdNpsiawhr2/n3 jBzZx9y/L+8sctWCiWZAG6zCCD11ZdaQzMVC1kW5664nnJSvBdpZjkJjJMbK4FjbhxB2 wCZWkVr6us9UMah7QRur/gxIbXq+4X10QBQdG+CkqEEo8Bpmw0XuEfD12XDenll1WNNC fw+mFCRNcv7DDVQa/m9Thj4AqJnv6e1+70QEZbQW4dBpFin9YQC4lwRo6O0efD070QME YVVQ== X-Received: by 10.112.202.106 with SMTP id kh10mr9540079lbc.66.1406790470499; Thu, 31 Jul 2014 00:07:50 -0700 (PDT) Received: from [10.17.0.21] ([83.150.126.201]) by mx.google.com with ESMTPSA id aa2sm6999699lbc.29.2014.07.31.00.07.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jul 2014 00:07:49 -0700 (PDT) Message-ID: <53D9EB44.8030709@gmail.com> Date: Thu, 31 Jul 2014 10:07:48 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "Wiehe, Ulrich (NSN - DE/Munich)" , ext Steve Donovan , "dime@ietf.org" References: <53D7FC1B.8070708@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520812B@DEMUMBX014.nsn-intra.net> <21807_1406732974_53D90AAE_21807_8763_1_6B7134B31289DC4FAF731D844122B36E6826D2@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <21807_1406732974_53D90AAE_21807_8763_1_6B7134B31289DC4FAF731D844122B36E6826D2@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/MMcfL-yXHBwimD4CiVbfUySw4AE Subject: Re: [Dime] Issue #26 proposed resolution X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 07:08:02 -0000 I am also for removing Section 3.1. - Jouni 7/30/2014 6:09 PM, lionel.morand@orange.com kirjoitti: > The concept of DOIC endpoint is introduced in section 3. > I share the view that the section 3.1 can be removed. And the figures do not provide real added-values after saying in the introduction: > > "Any Diameter node can act as a DOIC endpoint, including clients, > servers, and agents. DOIC endpoints are further divided into > "Reporting Nodes" and "Reacting Nodes." A reporting node requests > overload abatement by sending an Overload Report (OLR) to one or more > reacting nodes. > > A reacting node consumes OLRs, and performs whatever actions are > needed to fulfill the abatement requests included in the OLRs. A > Reporting node may report overload on its own behalf, or on behalf of > other (typically upstream) nodes. Likewise, a reacting node may > perform overload abatement on its own behalf, or on behalf of other > (typically downstream) nodes." > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) > Envoyé : mercredi 30 juillet 2014 10:41 > À : ext Steve Donovan; dime@ietf.org > Objet : Re: [Dime] Issue #26 proposed resolution > > Steve, > > I find the concept of DOIC End Points (and DOIC associations between DOIC End Points) helpful; especially the figures in section 3.1 are useful as they show valid scenarios. > I, however, agree that more clarifying text is needed to say how nodes detect in wich scenario they actually are. > > E.g. with regard to figure 2, current text says > "... there is an agent that is not participating directly in the exchange of overload reports." > but it is not said how the agent determines that it should/must be transparent. > > Similarly for other figures. > > Rather than deleting clause 3.1, I would prefer to add text providing rules for nodes to detect which of the valid scenarios is actually applicable. Please see my proposal of rules A) to F) sent on July 11th. > > Regards, > Ulrich > > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan > Sent: Tuesday, July 29, 2014 9:55 PM > To: dime@ietf.org > Subject: [Dime] Issue #26 proposed resolution > > All, > > Issue #26 - Overload control endpoints under specified. > > During the DIME meeting in Toronto the proposal was made to remove the > concept of Endpoints and Associations. > > These concepts were helpful getting the specification to where it is now > but a number of us consider the concepts to be confusing at best and > potentially misleading. > > The high level proposal is to remove section 3.1 that talks about > Overload Control Endpoints and DOIC Associations. The remainder of the > document would then be updated to handle any references to that section > and to the concepts of endpoint and association. > > I've done a quick review of the document and there are a number of > places where the term "overload control endpoint" is used. I think most > of these can be changed to "overload control node" or "DOIC node" with > no additional change needed (other than to define these terms in the > terminology section). > > I want to see if there are any objections to this potential change > before doing the work to propose specific wording changes. If there is > general agreement then I will come back to the list with detailed > proposal for wording changes that would be reflected in the -04 version > of the draft. > > The other option would be to rewrite section 3.1 to have a more concise > definition of endpoint, most likely removing the concept of DOIC > association. > > Regards, > > Steve > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Thu Jul 31 00:10:48 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2C31A0377 for ; Thu, 31 Jul 2014 00:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 Q-LhCiTQFMXO for ; Thu, 31 Jul 2014 00:10:41 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70B011A0375 for ; Thu, 31 Jul 2014 00:10:41 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id c11so1688157lbj.19 for ; Thu, 31 Jul 2014 00:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=2YDWtS8zts/9QBGwDFng3GYc6LVqGoxbHfFL9hyvUBE=; b=wsUfMiQ82nPPz/WpUZ+75qQglA40kM4amsSkXOrZ50OYEtFmxdLs1o36LwzoBfqr2U xLRj7KwHlZC9cFpH6NwWk++wWk4JZN6qjQtUffblpqbCUdogRSx4+bma/PNXaK864KCh 7ypD72xcM64TR2t+zTyZOq/8o6wnIPD8QNpIErHZguGy7TdohiVJQ6WTFepczkSDpDHO hgNQTXIRiWFIr+gQbasG/6Pw5ZzXV8xUyxwXKBm5mXQsS3CcHL7fy3qgt0RlAIWBRWLj K7f2XJ8P6OavDc/jNUFJc83BG+ANS4OX1YGUYVEq14/SiHIH/oFo/7GK/5sxxe22DMNU u8jg== X-Received: by 10.112.149.200 with SMTP id uc8mr9260886lbb.70.1406790639778; Thu, 31 Jul 2014 00:10:39 -0700 (PDT) Received: from [10.17.0.21] ([83.150.126.201]) by mx.google.com with ESMTPSA id t5sm2486282laa.26.2014.07.31.00.10.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jul 2014 00:10:39 -0700 (PDT) Message-ID: <53D9EBED.9080302@gmail.com> Date: Thu, 31 Jul 2014 10:10:37 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: lionel.morand@orange.com, "Wiehe, Ulrich (NSN - DE/Munich)" References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53B8550C.4050206@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FD9B1@DEMUMBX014.nsn-intra.net> <53C53234.9090007@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FE34D@DEMUMBX014.nsn-intra.net> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> <53D7AA31.3070908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520806A@DEMUMBX014.nsn-intra.net> <53D8DE85.5040201@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668152081C8@DEMUMBX014.nsn-intra.net> <11125_1406727989_53D8F735_11125_1419_1_6B7134B31289DC4FAF731D844122B36E68248A@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <11125_1406727989_53D8F735_11125_1419_1_6B7134B31289DC4FAF731D844122B36E68248A@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Lmj7g6GPw30s03J7km6I0rr80vQ Cc: "dime@ietf.org" Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 07:10:46 -0000 7/30/2014 4:46 PM, lionel.morand@orange.com kirjoitti: > Hi, > > IMHO, node selection is performed when multiple servers are present in the realm-routing table for a given realm entry. And if multiple servers are present in table, it is because multiple connections are available. In fine, it is the connection that is selected. No need for an agent to insert the Dest-Host AVP in the request. Therefore, I agree that DOICable may/must use the overload reports received from the different servers to select the most suitable server, but I agree with Jouni that an agent does not have to insert Dest-Host AVP. Exactly what I meant. - Jouni > > Lionel > > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni > Envoyé : mercredi 30 juillet 2014 15:36 > À : Wiehe, Ulrich (NSN - DE/Munich) > Cc : dime@ietf.org > Objet : Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) > > Ulrich, > > I have no problem with DOICable node doing routing/forwarding based on load whatever. But I have an issue an intermediate node adding Destination-Host into a request when the client did not originally insert one. I am a bit cautious that an agent next to a server can be overruled by other agents when selecting the server. While this all is still within RFC6733 boundaries it is somewhat different than in RFC6733. That's why I have concerns with this. > > Jouni > From nobody Thu Jul 31 05:53:19 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7441A0005 for ; Thu, 31 Jul 2014 05:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 qt8INlqd1cgB for ; Thu, 31 Jul 2014 05:53:16 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.162]) by ietfa.amsl.com (Postfix) with ESMTP id B390A1A0383 for ; Thu, 31 Jul 2014 05:53:15 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Thu, 31 Jul 2014 08:52:54 -0400 From: Dave Dolson To: "Shishufeng (Susan)" , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) Thread-Index: AQHPpOYdR9zJJGY8lEarOX8WMqkJU5uqzgGAgAALjoCADB0+gIAAbsyAgAAavYCAAVTRgIAAEooAgAAIGYCAAALKAIAABAYA///FTvCAAEuFgP//zBHggABMp4CAAOuvAIAAIlew Date: Thu, 31 Jul 2014 12:52:53 +0000 Message-ID: References: <20140703193124.12430.4816.idtracker@ietfa.amsl.com> <53CC10A4.4070200@gmail.com> <53CD1274.40405@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151FF466@DEMUMBX014.nsn-intra.net> <53CD23BD.8010906@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D900066815206E61@DEMUMBX014.nsn-intra.net> <53D7AA31.3070908@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681520806A@DEMUMBX014.nsn-intra.net> <53D8DE85.5040201@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668152081C8@DEMUMBX014.nsn-intra.net> <11125_1406727989_53D8F735_11125_1419_1_6B7134B31289DC4FAF731D844122B36E68248A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <53D8FA94.6030806@usdonovans.com> <53D908B1.7030404@usdonovans.com> <53D91D6D.4020309@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F258DF61431@SZXEMA512-MBX.china.huawei.com> In-Reply-To: <26C84DFD55BC3040A45BF70926E55F258DF61431@SZXEMA512-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.111] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7VXMv0W3ad41VEq_cHjFKVj7MQA Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime-ovli-03.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 12:53:18 -0000 That makes sense to me. When I was talking about new sessions, I was thinki= ng about stateful session-oriented protocols that use realm-only-routed req= uests only at the start of the session. I understand that other protocols m= ay be different. I think it is conceivable that realm overload state could be known by the i= ndividual hosts or by a load-balancing agent serving them; a vendor could p= rovide either solution when the vendor provides the load-balancing agent. Is it intended to standardize the algorithm a load-balancing agent would us= e to calculate and insert realm overload report by aggregating host overloa= d reports? Or would be up to the vendor? I guess this would be in section 4.2.4. -----Original Message----- From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]=20 Sent: Thursday, July 31, 2014 2:33 AM To: Steve Donovan; Dave Dolson; dime@ietf.org Subject: RE: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime= -ovli-03.txt) Hello Dave, My view is that the server only cares about its own overload state, there i= s no need for a server to know the overload status of the realm, which shou= ld be the responsibility of the agent serving a server farm. If the reacting node is unable to know the destination-host of the request,= the request will be treated as realm-routed messages and realm-routed repo= rt will be applied, whatever the request is session related or not, first m= essage or mid-session request. Best Regards, Susan -----Original Message----- From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Thursday, July 31, 2014 12:30 AM To: Dave Dolson; dime@ietf.org Subject: Re: [Dime] Transparent agents (was Re: I-D Action: draft-ietf-dime= -ovli-03.txt) Dave, Please see inline. Steve On 7/30/14, 11:03 AM, Dave Dolson wrote: > Sorry for not paying attention... > > But wouldn't it be simpler and more stable to keep them independent? Definitely not simpler. This would require the reporting node, generally a= server, to know more than just the its own overload state. =20 A realm-routed request can go to multiple servers, all with different overl= oad states. To send a realm report requires knowledge of all of the server= s in the realm. Keeping the reports separate would also require an underst= anding of the mix of host-routed requests and realm-routed requests, someth= ing that is likely to be very dynamic and certainly will be different acros= s applications. The loss algorithm is designed to be very simple. The reporting node reque= sts a percentage reduction of traffic sent to it and the reacting node(s) abate that percentage of traffic sent to the node. > > As you describe, host-routed requests need to consider host load and=20 > also realm load, > > Here is my perspective: > 1- when sending a host-routed request, only the load of the=20 > destination-host matters. The overall realm load is irrelevant Agreed, mostly. Only the load of the reporting node matters. This still r= equires reducing all traffic sent to the node, both host-routed and realm-r= outed requests. > 2- when sending a realm-only-routed request, only the ability of the real= m to accept a new session matters. Not necessarily. Realm-routed requests are used for things other than esta= blishing new sessions. There are applications that are not session based, = for instance. There are applications that do not require mid session reque= sts to have the destination-host AVP. > > > I believe we've got (2) right by saying that realm-routed abatement does = not apply to messages with destination-host. > > > > -----Original Message----- > From: Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Wednesday, July 30, 2014 11:01 AM > To: Dave Dolson; dime@ietf.org > Subject: Re: [Dime] Transparent agents (was Re: I-D Action:=20 > draft-ietf-dime-ovli-03.txt) > > Dave, > > A host report is a request by the reporting node to reduce traffic to=20 > that node, regardless of the type of request. In order to achieve=20 > that reduction, it is necessary to abate both "host-routed" requests=20 > and "realm-routed" request". The first use case in the agent cases=20 > draft illustrates this scenario where the client handles abatement of=20 > the host-routed requests and the agent that has direct transport=20 > connection to the reporting node handles abatement of realm-routed reques= ts. > > There is no mechanism for the reporting node to request a reduction in=20 > host-routed requests separate from realm-routed requests. One of the=20 > reasons is that for realm-routed requests there may be other nodes=20 > that could handle the request. > > Steve > > On 7/30/14, 9:33 AM, Dave Dolson wrote: >> Host overload reports should not affect realm-route-requests. >> The system will be more stable if the two control systems are independen= t, not cross-coupled. >> >> >> >> >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan >> Sent: Wednesday, July 30, 2014 10:01 AM >> To: dime@ietf.org >> Subject: Re: [Dime] Transparent agents (was Re: I-D Action:=20 >> draft-ietf-dime-ovli-03.txt) >> >> The question is the behavior of a DOIC node that does abatement of=20 >> "realm-route-requests" in the face of a host report for a server. >> >> I think the DOIC specification needs to say that for a DOIC node to=20 >> do abatement of realm-routed-requests it needs to be able to=20 >> guarantee that the request that survive abatement will be routed to=20 >> the reporting node for the host report. This is easy to achieve if=20 >> the DOIC node has a direct transport connection to the reporting=20 >> node. Ulrich's point is that it can also be achieved by the DOIC=20 >> node inserting destination-host for requests targeted for the reporting = node that survive abatement. >> >> Steve >> >> On 7/30/14, 8:46 AM, lionel.morand@orange.com wrote: >>> Hi, >>> >>> IMHO, node selection is performed when multiple servers are present in = the realm-routing table for a given realm entry. And if multiple servers ar= e present in table, it is because multiple connections are available. In fi= ne, it is the connection that is selected. No need for an agent to insert t= he Dest-Host AVP in the request. Therefore, I agree that DOICable may/must = use the overload reports received from the different servers to select the = most suitable server, but I agree with Jouni that an agent does not have to= insert Dest-Host AVP. >>> >>> Lionel >>> >>> -----Message d'origine----- >>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Envoy=E9=20 >>> : mercredi 30 juillet 2014 15:36 =C0 : Wiehe, Ulrich (NSN - DE/Munich)= =20 >>> Cc : dime@ietf.org Objet : Re: [Dime] Transparent agents (was Re:=20 >>> I-D Action: draft-ietf-dime-ovli-03.txt) >>> >>> Ulrich, >>> >>> I have no problem with DOICable node doing routing/forwarding based on = load whatever. But I have an issue an intermediate node adding Destination-= Host into a request when the client did not originally insert one. I am a b= it cautious that an agent next to a server can be overruled by other agents= when selecting the server. While this all is still within RFC6733 boundari= es it is somewhat different than in RFC6733. That's why I have concerns wit= h this. >>> >>> Jouni >>> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >> > From nobody Thu Jul 31 07:02:45 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFC51B2829 for ; Thu, 31 Jul 2014 07:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 Un18tVToCyLB for ; Thu, 31 Jul 2014 07:02:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 34DC51B281F for ; Thu, 31 Jul 2014 07:02:41 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6VE2a3Z049381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 Jul 2014 09:02:38 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53D9EA3C.5080301@gmail.com> Date: Thu, 31 Jul 2014 09:02:36 -0500 X-Mao-Original-Outgoing-Id: 428508155.983286-66a912b606eb7c85f332d50088e1be4b Content-Transfer-Encoding: quoted-printable Message-Id: References: <53D640F6.5080502@gmail.com> <53D7F720.90503@usdonovans.com> <8374EACC-ACF7-4B22-9AD3-C174A890479F@nostrum.com> <53D9EA3C.5080301@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5eORVxvQgvlSUpMGsCt2A1oH51g Cc: dime@ietf.org Subject: Re: [Dime] DOIC: Base protocol vs application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 14:02:43 -0000 On Jul 31, 2014, at 2:03 AM, Jouni Korhonen = wrote: > Ben, >=20 > 7/30/2014 11:19 PM, Ben Campbell kirjoitti: >>=20 >> I'm not sure I agree. I think we may be skirting the first sentence = in Req 2, quoted here: >>=20 >>> REQ 2: The solution MUST allow Diameter nodes to support = overload >>> control regardless of which Diameter applications they >>> support. Diameter clients and agents must be able to use = the >>> received load and overload information to support = graceful >>> behavior during an overload condition. Graceful behavior >>> under overload conditions is best described by REQ 3. >>>=20 >>=20 >> The word "node" was carefully selected. If an agent with no knowledge = of the "foo" application cannot apply DOIC to messages for "foo", then = we have failed to meet that requirement. >=20 > In this requirement the "node" does not apply to proxies. A proxy = won't even receive messages for the "foo" application unless it = advertises one. And if the proxy advertises a specific application it = implicitly supports one. I would say it's non-constraining for proxies. But "node" also includes = relays. >=20 > - Jouni >=20 >=20 >>=20 >> Allowing that implies that DOIC AVPs mean the same for all = applications, and can be inserted into messages for any application = without a new specification for that application. That's a stronger = statement than just saying any application can incorporate them. This = seems to mean they need to be part of the base specification. >>=20 >> That all being said, I agree that often will be beneficial to = explicitly incorporate DOIC into applications, so that one can make = application-specific statements about things like detecting overload, = message prioritization under overload, and client application behavior = under overload. >>=20 >> On Jul 29, 2014, at 2:33 PM, Steve Donovan = wrote: >>=20 >>> Dave, >>>=20 >>> My take is that it is clear the DOIC AVPs and behaviors will not be = incorporated into the base protocol. I was a little loose in my = terminology during the meeting. >>>=20 >>> The goal, at least for me, has been to define a common mechanism for = Diameter nodes to exchange Diameter Overload related AVPs, with the = necessary behavior defined for the handling of those AVPs. >>>=20 >>> Application specifications will then be updated to reference the = DOIC specification. This process has already started in 3GPP, with = updates to many of the 3GPP specification already made. >>>=20 >>> It is a measure of our success in defining a common mechanism that = can be reused unchanged by Diameter applications that the updates to the = application specifications has been a very straight forward process. = This has consisted primarily of adding the AVPs to the list of = application AVPs and referencing of the DOIC specification for behavior = associated with those AVPs. >>>=20 >>> Regards, >>>=20 >>> Steve >>>=20 >>> On 7/29/14, 8:29 AM, Dave Dolson wrote: >>>> I'm the "Dave" (Dolson, Dawson, etc.) in the minutes. >>>>=20 >>>> My understanding in the meeting discussion about DOIC was that the = DOIC AVPs will have to be added to application protocols. >>>> In other words, NOT added to the base protocol, and no existing = Diameter agents or end-points will be expected to understand it. >>>>=20 >>>> My reasoning was that abatement is always application-specific, = requiring knowledge of message semantics. >>>>=20 >>>> But from the minutes, that conclusion isn't clear. I may have heard = what I wanted to hear rather than what was actually said... >>>>=20 >>>> So, is the intent to define a new mechanism that may be used with = new protocols and protocol updates, or is the intent to put DOIC in the = base such that all protocols automatically inherit it? >>>>=20 >>>>=20 >>>>> Dave - You will get the doc through quicker if you don't explain = the >>>>> approaches when you get the AVP. 4006 type applications = - session-based >>>>> applications. Here's one for stateless. >>>> My point here is, just define the AVP and indicate how it should be = used, in the sense of providing design patterns (for stateless, online = charging, offline charging, etc). Then we don't have to debate the = corner-cases of the abatement algorithms of all applications; we just = need to agree on the wire format. Then applications can start to = reference it, one by one. >>>>=20 >>>>=20 >>>> David Dolson >>>> Senior Software Architect, Sandvine Inc. >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni = Korhonen >>>> Sent: Monday, July 28, 2014 8:24 AM >>>> To: dime@ietf.org >>>> Subject: [Dime] meeting minutes uploada >>>>=20 >>>> Thanks to Jean for extensive minutes & notes: >>>> http://tools.ietf.org/wg/dime/minutes?item=3Dminutes-90-dime.html >>>>=20 >>>> - Jouni >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>>=20 >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime From nobody Thu Jul 31 07:21:09 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3901B2848 for ; Thu, 31 Jul 2014 07:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 Q2tMPo-6qCOC for ; Thu, 31 Jul 2014 07:20:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E7D21B2840 for ; Thu, 31 Jul 2014 07:20:36 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 220EC264AF9; Thu, 31 Jul 2014 16:20:32 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 047074C3E5; Thu, 31 Jul 2014 16:20:32 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 31 Jul 2014 16:20:31 +0200 From: To: Ben Campbell , Jouni Korhonen Thread-Topic: [Dime] DOIC: Base protocol vs application Thread-Index: AQHPrDOf5TplgyrNLU28W6D8dfz75Zu5oRsAgAB1IACAACIZsA== Date: Thu, 31 Jul 2014 14:20:30 +0000 Message-ID: <5735_1406816432_53DA50B0_5735_8214_1_6B7134B31289DC4FAF731D844122B36E68460D@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <53D640F6.5080502@gmail.com> <53D7F720.90503@usdonovans.com> <8374EACC-ACF7-4B22-9AD3-C174A890479F@nostrum.com> <53D9EA3C.5080301@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.31.83628 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/E74-KzLtqkQlawaoC9N-FijWDvc Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC: Base protocol vs application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 14:20:55 -0000 The current solution has been designed to be generic enough to be supported= over any application. Any existing Diameter node can be upgraded to support overload control. Any= new node can be designed to support this mechanism. Client and servers can use overload report for graceful behavior. I fail to see where the requirement is not meant. And I think that it is wh= at it is already stated in the introduction: Furthermore, the solution is designed to apply to existing and future Diameter applications, requires no changes to the Diameter base protocol [RFC6733] and is deployable in environments where some Diameter nodes do not implement the Diameter overload control solution defined in this specification. Anyhow, I have no problem to agree that this solution fails to completely c= over the REQ2 if it is your understanding. The real requirement is to have = a solution supporting DOICable and non-DOCIable nodes. After, any vendor/op= erator can decide which nodes are deemed required to support DOIC. This is/= will be decided for 3GPP networks and in any network in which DOIC will hav= e to be introduced. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy=E9=A0: jeudi 31 juillet 2014 16:03 =C0=A0: Jouni Korhonen Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] DOIC: Base protocol vs application On Jul 31, 2014, at 2:03 AM, Jouni Korhonen wrote: > Ben, >=20 > 7/30/2014 11:19 PM, Ben Campbell kirjoitti: >>=20 >> I'm not sure I agree. I think we may be skirting the first sentence in R= eq 2, quoted here: >>=20 >>> REQ 2: The solution MUST allow Diameter nodes to support overload >>> control regardless of which Diameter applications they >>> support. Diameter clients and agents must be able to use the >>> received load and overload information to support graceful >>> behavior during an overload condition. Graceful behavior >>> under overload conditions is best described by REQ 3. >>>=20 >>=20 >> The word "node" was carefully selected. If an agent with no knowledge of= the "foo" application cannot apply DOIC to messages for "foo", then we hav= e failed to meet that requirement. >=20 > In this requirement the "node" does not apply to proxies. A proxy won't e= ven receive messages for the "foo" application unless it advertises one. An= d if the proxy advertises a specific application it implicitly supports one. I would say it's non-constraining for proxies. But "node" also includes rel= ays. >=20 > - Jouni >=20 >=20 >>=20 >> Allowing that implies that DOIC AVPs mean the same for all applications,= and can be inserted into messages for any application without a new specif= ication for that application. That's a stronger statement than just saying = any application can incorporate them. This seems to mean they need to be pa= rt of the base specification. >>=20 >> That all being said, I agree that often will be beneficial to explicitly= incorporate DOIC into applications, so that one can make application-speci= fic statements about things like detecting overload, message prioritization= under overload, and client application behavior under overload. >>=20 >> On Jul 29, 2014, at 2:33 PM, Steve Donovan wr= ote: >>=20 >>> Dave, >>>=20 >>> My take is that it is clear the DOIC AVPs and behaviors will not be inc= orporated into the base protocol. I was a little loose in my terminology d= uring the meeting. >>>=20 >>> The goal, at least for me, has been to define a common mechanism for Di= ameter nodes to exchange Diameter Overload related AVPs, with the necessary= behavior defined for the handling of those AVPs. >>>=20 >>> Application specifications will then be updated to reference the DOIC s= pecification. This process has already started in 3GPP, with updates to ma= ny of the 3GPP specification already made. >>>=20 >>> It is a measure of our success in defining a common mechanism that can = be reused unchanged by Diameter applications that the updates to the applic= ation specifications has been a very straight forward process. This has co= nsisted primarily of adding the AVPs to the list of application AVPs and re= ferencing of the DOIC specification for behavior associated with those AVPs. >>>=20 >>> Regards, >>>=20 >>> Steve >>>=20 >>> On 7/29/14, 8:29 AM, Dave Dolson wrote: >>>> I'm the "Dave" (Dolson, Dawson, etc.) in the minutes. >>>>=20 >>>> My understanding in the meeting discussion about DOIC was that the DOI= C AVPs will have to be added to application protocols. >>>> In other words, NOT added to the base protocol, and no existing Diamet= er agents or end-points will be expected to understand it. >>>>=20 >>>> My reasoning was that abatement is always application-specific, requir= ing knowledge of message semantics. >>>>=20 >>>> But from the minutes, that conclusion isn't clear. I may have heard wh= at I wanted to hear rather than what was actually said... >>>>=20 >>>> So, is the intent to define a new mechanism that may be used with new = protocols and protocol updates, or is the intent to put DOIC in the base su= ch that all protocols automatically inherit it? >>>>=20 >>>>=20 >>>>> Dave - You will get the doc through quicker if you don't explain the >>>>> approaches when you get the AVP. 4006 type applications - s= ession-based >>>>> applications. Here's one for stateless. >>>> My point here is, just define the AVP and indicate how it should be us= ed, in the sense of providing design patterns (for stateless, online chargi= ng, offline charging, etc). Then we don't have to debate the corner-cases o= f the abatement algorithms of all applications; we just need to agree on th= e wire format. Then applications can start to reference it, one by one. >>>>=20 >>>>=20 >>>> David Dolson >>>> Senior Software Architect, Sandvine Inc. >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >>>> Sent: Monday, July 28, 2014 8:24 AM >>>> To: dime@ietf.org >>>> Subject: [Dime] meeting minutes uploada >>>>=20 >>>> Thanks to Jean for extensive minutes & notes: >>>> http://tools.ietf.org/wg/dime/minutes?item=3Dminutes-90-dime.html >>>>=20 >>>> - Jouni >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>>=20 >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jul 31 08:00:29 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628FF1B2926 for ; Thu, 31 Jul 2014 08:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 qdbjOMSxXW5Z for ; Thu, 31 Jul 2014 08:00:05 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9B7F01B2918 for ; Thu, 31 Jul 2014 08:00:05 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6VF006N054341 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 Jul 2014 10:00:01 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <5735_1406816432_53DA50B0_5735_8214_1_6B7134B31289DC4FAF731D844122B36E68460D@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Thu, 31 Jul 2014 09:59:59 -0500 X-Mao-Original-Outgoing-Id: 428511599.677549-eba66eefc7fa2e377426dbe379b8b02b Content-Transfer-Encoding: quoted-printable Message-Id: References: <53D640F6.5080502@gmail.com> <53D7F720.90503@usdonovans.com> <8374EACC-ACF7-4B22-9AD3-C174A890479F@nostrum.com> <53D9EA3C.5080301@gmail.com> <5735_1406816432_53DA50B0_5735_8214_1_6B7134B31289DC4FAF731D844122B36E68460D@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/e94OT_kFs2V1PvfrGeZ3GxjEjEI Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC: Base protocol vs application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 15:00:18 -0000 On Jul 31, 2014, at 9:20 AM, = wrote: > The current solution has been designed to be generic enough to be = supported over any application. > Any existing Diameter node can be upgraded to support overload = control. Any new node can be designed to support this mechanism. > Client and servers can use overload report for graceful behavior. >=20 > I fail to see where the requirement is not meant. And I think that it = is what it is already stated in the introduction: >=20 > Furthermore, the solution is designed to apply to existing and = future > Diameter applications, requires no changes to the Diameter base > protocol [RFC6733] and is deployable in environments where some > Diameter nodes do not implement the Diameter overload control > solution defined in this specification. >=20 > Anyhow, I have no problem to agree that this solution fails to = completely cover the REQ2 if it is your understanding. The real = requirement is to have a solution supporting DOICable and non-DOCIable = nodes. After, any vendor/operator can decide which nodes are deemed = required to support DOIC. This is/will be decided for 3GPP networks and = in any network in which DOIC will have to be introduced. Hi Lionel, I'm not sure if we are agreeing or disagreeing. Given the existing specification, do you believe that any node = (including an agent that does not recognize the application in question) = can insert DOIC AVPs into messages for any arbitrary application?=20 If so, then I am happy with it, and consider the "base vs application" = discussion to be a red herring. (Although I think a discussion on = whether these might count as "routing" AVPs might be interesting.) >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell > Envoy=E9 : jeudi 31 juillet 2014 16:03 > =C0 : Jouni Korhonen > Cc : dime@ietf.org > Objet : Re: [Dime] DOIC: Base protocol vs application >=20 >=20 > On Jul 31, 2014, at 2:03 AM, Jouni Korhonen = wrote: >=20 >> Ben, >>=20 >> 7/30/2014 11:19 PM, Ben Campbell kirjoitti: >>>=20 >>> I'm not sure I agree. I think we may be skirting the first sentence = in Req 2, quoted here: >>>=20 >>>> REQ 2: The solution MUST allow Diameter nodes to support = overload >>>> control regardless of which Diameter applications they >>>> support. Diameter clients and agents must be able to use = the >>>> received load and overload information to support = graceful >>>> behavior during an overload condition. Graceful behavior >>>> under overload conditions is best described by REQ 3. >>>>=20 >>>=20 >>> The word "node" was carefully selected. If an agent with no = knowledge of the "foo" application cannot apply DOIC to messages for = "foo", then we have failed to meet that requirement. >>=20 >> In this requirement the "node" does not apply to proxies. A proxy = won't even receive messages for the "foo" application unless it = advertises one. And if the proxy advertises a specific application it = implicitly supports one. >=20 > I would say it's non-constraining for proxies. But "node" also = includes relays. >=20 >>=20 >> - Jouni >>=20 >>=20 >>>=20 >>> Allowing that implies that DOIC AVPs mean the same for all = applications, and can be inserted into messages for any application = without a new specification for that application. That's a stronger = statement than just saying any application can incorporate them. This = seems to mean they need to be part of the base specification. >>>=20 >>> That all being said, I agree that often will be beneficial to = explicitly incorporate DOIC into applications, so that one can make = application-specific statements about things like detecting overload, = message prioritization under overload, and client application behavior = under overload. >>>=20 >>> On Jul 29, 2014, at 2:33 PM, Steve Donovan = wrote: >>>=20 >>>> Dave, >>>>=20 >>>> My take is that it is clear the DOIC AVPs and behaviors will not be = incorporated into the base protocol. I was a little loose in my = terminology during the meeting. >>>>=20 >>>> The goal, at least for me, has been to define a common mechanism = for Diameter nodes to exchange Diameter Overload related AVPs, with the = necessary behavior defined for the handling of those AVPs. >>>>=20 >>>> Application specifications will then be updated to reference the = DOIC specification. This process has already started in 3GPP, with = updates to many of the 3GPP specification already made. >>>>=20 >>>> It is a measure of our success in defining a common mechanism that = can be reused unchanged by Diameter applications that the updates to the = application specifications has been a very straight forward process. = This has consisted primarily of adding the AVPs to the list of = application AVPs and referencing of the DOIC specification for behavior = associated with those AVPs. >>>>=20 >>>> Regards, >>>>=20 >>>> Steve >>>>=20 >>>> On 7/29/14, 8:29 AM, Dave Dolson wrote: >>>>> I'm the "Dave" (Dolson, Dawson, etc.) in the minutes. >>>>>=20 >>>>> My understanding in the meeting discussion about DOIC was that the = DOIC AVPs will have to be added to application protocols. >>>>> In other words, NOT added to the base protocol, and no existing = Diameter agents or end-points will be expected to understand it. >>>>>=20 >>>>> My reasoning was that abatement is always application-specific, = requiring knowledge of message semantics. >>>>>=20 >>>>> But from the minutes, that conclusion isn't clear. I may have = heard what I wanted to hear rather than what was actually said... >>>>>=20 >>>>> So, is the intent to define a new mechanism that may be used with = new protocols and protocol updates, or is the intent to put DOIC in the = base such that all protocols automatically inherit it? >>>>>=20 >>>>>=20 >>>>>> Dave - You will get the doc through quicker if you don't explain = the >>>>>> approaches when you get the AVP. 4006 type applications = - session-based >>>>>> applications. Here's one for stateless. >>>>> My point here is, just define the AVP and indicate how it should = be used, in the sense of providing design patterns (for stateless, = online charging, offline charging, etc). Then we don't have to debate = the corner-cases of the abatement algorithms of all applications; we = just need to agree on the wire format. Then applications can start to = reference it, one by one. >>>>>=20 >>>>>=20 >>>>> David Dolson >>>>> Senior Software Architect, Sandvine Inc. >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni = Korhonen >>>>> Sent: Monday, July 28, 2014 8:24 AM >>>>> To: dime@ietf.org >>>>> Subject: [Dime] meeting minutes uploada >>>>>=20 >>>>> Thanks to Jean for extensive minutes & notes: >>>>> http://tools.ietf.org/wg/dime/minutes?item=3Dminutes-90-dime.html >>>>>=20 >>>>> - Jouni >>>>>=20 >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>=20 >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Thu Jul 31 08:55:52 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7BF1A012D for ; Thu, 31 Jul 2014 08:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 TNjEbgxd0eFi for ; Thu, 31 Jul 2014 08:55:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8221A0127 for ; Thu, 31 Jul 2014 08:55:46 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 36B7D18D100; Thu, 31 Jul 2014 17:55:44 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 177D035C13C; Thu, 31 Jul 2014 17:55:44 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 31 Jul 2014 17:55:43 +0200 From: To: Ben Campbell Thread-Topic: [Dime] DOIC: Base protocol vs application Thread-Index: AQHPrDOf5TplgyrNLU28W6D8dfz75Zu5oRsAgAB1IACAACIZsP//7e+AgAAiDZA= Date: Thu, 31 Jul 2014 15:55:43 +0000 Message-ID: <19412_1406822144_53DA6700_19412_635_1_6B7134B31289DC4FAF731D844122B36E6847D4@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <53D640F6.5080502@gmail.com> <53D7F720.90503@usdonovans.com> <8374EACC-ACF7-4B22-9AD3-C174A890479F@nostrum.com> <53D9EA3C.5080301@gmail.com> <5735_1406816432_53DA50B0_5735_8214_1_6B7134B31289DC4FAF731D844122B36E68460D@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.81224 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/QFBCWVVVTcbj6efN5nm_3RHC7YI Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC: Base protocol vs application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 15:55:50 -0000 Hi Ben, I disagree on the fact that the REQ 2 is not covered by the current solutio= n providing a generic solution at the application level, without any impact= on the base protocol. A node that will implement DOIC will have to understand the application con= veying the DOIC AVP. Otherwise, it will not be able to know what to do when= receiving the overload report (e.g. drop the request, divert, differ, etc.= ) as this behavior heavily depends on the application. Now speaking about agent, as per the RFC6733, a Relay or a Redirect, agent = advertizing the Relay App Id (0xffffffff) cannot do much more than performi= ng look-up into their routing table to select of the next hop for a given r= equest. If several peers are available for a given entry in the routing, th= ey may perform some load balance of requests between peers. But nothing els= e.=20 Updating the RFC6733 to indicate that Relay and Redirect must now support D= OIC would be a non-sense as OLR are only meaningful at the application leve= l to know how to perform efficient overload control. And an agent that woul= d have to manage something at the application is called a Proxy, even if th= e application specific behavior is only related to the overload control fun= ctions.=20 In the same line, a node that would be designed to relay any application re= quest and only provide overload control as enhanced functionality would be = a simple proxy that would have to advertize in CER/CEA all the application-= Id used in the network in which it is deployed and support the abatement tr= eatment to apply per application (note: the same abatement treatment princi= ple may be reused for multiple applications). And this node can be reused f= or any application, as long as it list of supported app-id and the correspo= nding abatement treatments are kept up to date. So, in summary, I can agree that your understanding of the REQ2 is not the = same than mine. I could even agree that your understanding is correct if I'= m forced to. And I would then agree that the REQ2 is not fulfilled by a sol= ution at the application level. But this would not change my position: I'm = perfectly fine with current approach and no update of the RFC6733 is needed= .=20 Regards, Lionel -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com]=20 Envoy=E9=A0: jeudi 31 juillet 2014 17:00 =C0=A0: MORAND Lionel IMT/OLN Cc=A0: Jouni Korhonen; dime@ietf.org Objet=A0: Re: [Dime] DOIC: Base protocol vs application On Jul 31, 2014, at 9:20 AM, wrote: > The current solution has been designed to be generic enough to be support= ed over any application. > Any existing Diameter node can be upgraded to support overload control. A= ny new node can be designed to support this mechanism. > Client and servers can use overload report for graceful behavior. >=20 > I fail to see where the requirement is not meant. And I think that it is = what it is already stated in the introduction: >=20 > Furthermore, the solution is designed to apply to existing and future > Diameter applications, requires no changes to the Diameter base > protocol [RFC6733] and is deployable in environments where some > Diameter nodes do not implement the Diameter overload control > solution defined in this specification. >=20 > Anyhow, I have no problem to agree that this solution fails to completely= cover the REQ2 if it is your understanding. The real requirement is to hav= e a solution supporting DOICable and non-DOCIable nodes. After, any vendor/= operator can decide which nodes are deemed required to support DOIC. This i= s/will be decided for 3GPP networks and in any network in which DOIC will h= ave to be introduced. Hi Lionel, I'm not sure if we are agreeing or disagreeing. Given the existing specification, do you believe that any node (including a= n agent that does not recognize the application in question) can insert DOI= C AVPs into messages for any arbitrary application?=20 If so, then I am happy with it, and consider the "base vs application" disc= ussion to be a red herring. (Although I think a discussion on whether these= might count as "routing" AVPs might be interesting.) >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell > Envoy=E9 : jeudi 31 juillet 2014 16:03 > =C0 : Jouni Korhonen > Cc : dime@ietf.org > Objet : Re: [Dime] DOIC: Base protocol vs application >=20 >=20 > On Jul 31, 2014, at 2:03 AM, Jouni Korhonen wrot= e: >=20 >> Ben, >>=20 >> 7/30/2014 11:19 PM, Ben Campbell kirjoitti: >>>=20 >>> I'm not sure I agree. I think we may be skirting the first sentence in = Req 2, quoted here: >>>=20 >>>> REQ 2: The solution MUST allow Diameter nodes to support overload >>>> control regardless of which Diameter applications they >>>> support. Diameter clients and agents must be able to use the >>>> received load and overload information to support graceful >>>> behavior during an overload condition. Graceful behavior >>>> under overload conditions is best described by REQ 3. >>>>=20 >>>=20 >>> The word "node" was carefully selected. If an agent with no knowledge o= f the "foo" application cannot apply DOIC to messages for "foo", then we ha= ve failed to meet that requirement. >>=20 >> In this requirement the "node" does not apply to proxies. A proxy won't = even receive messages for the "foo" application unless it advertises one. A= nd if the proxy advertises a specific application it implicitly supports on= e. >=20 > I would say it's non-constraining for proxies. But "node" also includes r= elays. >=20 >>=20 >> - Jouni >>=20 >>=20 >>>=20 >>> Allowing that implies that DOIC AVPs mean the same for all applications= , and can be inserted into messages for any application without a new speci= fication for that application. That's a stronger statement than just saying= any application can incorporate them. This seems to mean they need to be p= art of the base specification. >>>=20 >>> That all being said, I agree that often will be beneficial to explicitl= y incorporate DOIC into applications, so that one can make application-spec= ific statements about things like detecting overload, message prioritizatio= n under overload, and client application behavior under overload. >>>=20 >>> On Jul 29, 2014, at 2:33 PM, Steve Donovan w= rote: >>>=20 >>>> Dave, >>>>=20 >>>> My take is that it is clear the DOIC AVPs and behaviors will not be in= corporated into the base protocol. I was a little loose in my terminology = during the meeting. >>>>=20 >>>> The goal, at least for me, has been to define a common mechanism for D= iameter nodes to exchange Diameter Overload related AVPs, with the necessar= y behavior defined for the handling of those AVPs. >>>>=20 >>>> Application specifications will then be updated to reference the DOIC = specification. This process has already started in 3GPP, with updates to m= any of the 3GPP specification already made. >>>>=20 >>>> It is a measure of our success in defining a common mechanism that can= be reused unchanged by Diameter applications that the updates to the appli= cation specifications has been a very straight forward process. This has c= onsisted primarily of adding the AVPs to the list of application AVPs and r= eferencing of the DOIC specification for behavior associated with those AVP= s. >>>>=20 >>>> Regards, >>>>=20 >>>> Steve >>>>=20 >>>> On 7/29/14, 8:29 AM, Dave Dolson wrote: >>>>> I'm the "Dave" (Dolson, Dawson, etc.) in the minutes. >>>>>=20 >>>>> My understanding in the meeting discussion about DOIC was that the DO= IC AVPs will have to be added to application protocols. >>>>> In other words, NOT added to the base protocol, and no existing Diame= ter agents or end-points will be expected to understand it. >>>>>=20 >>>>> My reasoning was that abatement is always application-specific, requi= ring knowledge of message semantics. >>>>>=20 >>>>> But from the minutes, that conclusion isn't clear. I may have heard w= hat I wanted to hear rather than what was actually said... >>>>>=20 >>>>> So, is the intent to define a new mechanism that may be used with new= protocols and protocol updates, or is the intent to put DOIC in the base s= uch that all protocols automatically inherit it? >>>>>=20 >>>>>=20 >>>>>> Dave - You will get the doc through quicker if you don't explain the >>>>>> approaches when you get the AVP. 4006 type applications - s= ession-based >>>>>> applications. Here's one for stateless. >>>>> My point here is, just define the AVP and indicate how it should be u= sed, in the sense of providing design patterns (for stateless, online charg= ing, offline charging, etc). Then we don't have to debate the corner-cases = of the abatement algorithms of all applications; we just need to agree on t= he wire format. Then applications can start to reference it, one by one. >>>>>=20 >>>>>=20 >>>>> David Dolson >>>>> Senior Software Architect, Sandvine Inc. >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen >>>>> Sent: Monday, July 28, 2014 8:24 AM >>>>> To: dime@ietf.org >>>>> Subject: [Dime] meeting minutes uploada >>>>>=20 >>>>> Thanks to Jean for extensive minutes & notes: >>>>> http://tools.ietf.org/wg/dime/minutes?item=3Dminutes-90-dime.html >>>>>=20 >>>>> - Jouni >>>>>=20 >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>=20 >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jul 31 09:52:46 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8431B294A for ; Thu, 31 Jul 2014 09:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=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 FHI02Zhb3u1v for ; Thu, 31 Jul 2014 09:52:43 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 AE57E1B294B for ; Thu, 31 Jul 2014 09:52:43 -0700 (PDT) Received: from [64.31.33.37] (port=49566 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XCtar-0002J6-Vp for dime@ietf.org; Thu, 31 Jul 2014 09:52:42 -0700 Message-ID: <53DA7458.5080301@usdonovans.com> Date: Thu, 31 Jul 2014 11:52:40 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/C7stx6Cs1t3kkiN11Jq7aeSou_w Subject: [Dime] Issue #48 - M-bit gives wrong sementics X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 16:52:44 -0000 All, The proposal coming out of the meeting in Toronto was to close this issue with no changes to the existing text. Let me know if there are objections to doing so, otherwise I'll close the issue. Regards, Steve From nobody Thu Jul 31 10:27:31 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF731A0193 for ; Thu, 31 Jul 2014 10:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 FU8qMdCfn1IQ for ; Thu, 31 Jul 2014 10:27:27 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 AFDFD1A0099 for ; Thu, 31 Jul 2014 10:27:27 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6VHROdj070280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 Jul 2014 12:27:26 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53DA7458.5080301@usdonovans.com> Date: Thu, 31 Jul 2014 12:27:23 -0500 X-Mao-Original-Outgoing-Id: 428520443.779275-b3ea90e418a2f653442323939c50f667 Content-Transfer-Encoding: quoted-printable Message-Id: <30A10CA8-0B72-4878-8489-5A3156E070AA@nostrum.com> References: <53DA7458.5080301@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/J-upucskFPGLjY7DRuRs2ma7PF4 Cc: "dime@ietf.org" Subject: Re: [Dime] Issue #48 - M-bit gives wrong sementics X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 17:27:29 -0000 No objection On Jul 31, 2014, at 11:52 AM, Steve Donovan = wrote: > All, >=20 > The proposal coming out of the meeting in Toronto was to close this = issue with no changes to the existing text. >=20 > Let me know if there are objections to doing so, otherwise I'll close = the issue. >=20 > Regards, >=20 > Steve >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Thu Jul 31 10:41:34 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B1B1B293C for ; Thu, 31 Jul 2014 10:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 VoLopCypsOOo for ; Thu, 31 Jul 2014 10:41:32 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E318E1A02E3 for ; Thu, 31 Jul 2014 10:41:31 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id EF90E264A87; Thu, 31 Jul 2014 19:41:29 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id D2FCB27C0EB; Thu, 31 Jul 2014 19:41:29 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Thu, 31 Jul 2014 19:41:29 +0200 From: To: Steve Donovan , Ben Campbell Thread-Topic: [Dime] Issue #48 - M-bit gives wrong sementics Thread-Index: AQHPrN/c8eKL2MjNiE2lxR2wh9XRg5u6ThqAgAAld6U= Date: Thu, 31 Jul 2014 17:41:28 +0000 Message-ID: <19339_1406828489_53DA7FC9_19339_507_2_vpoow8l3d11jllgtnin7jy3y.1406828485751@email.android.com> References: <53DA7458.5080301@usdonovans.com>, <30A10CA8-0B72-4878-8489-5A3156E070AA@nostrum.com> In-Reply-To: <30A10CA8-0B72-4878-8489-5A3156E070AA@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.25.100319 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/RuvwZMmRCtTy0VmvNUs24h_IoGU Cc: "dime@ietf.org" Subject: Re: [Dime] Issue #48 - M-bit gives wrong sementics X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 17:41:34 -0000 Ok for me. Envoy=E9 depuis mon Sony Xperia SP d'Orange ---- Ben Campbell a =E9crit ---- No objection On Jul 31, 2014, at 11:52 AM, Steve Donovan wrot= e: > All, > > The proposal coming out of the meeting in Toronto was to close this issue= with no changes to the existing text. > > Let me know if there are objections to doing so, otherwise I'll close the= issue. > > Regards, > > Steve > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jul 31 11:49:05 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30351A0311 for ; Thu, 31 Jul 2014 11:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 yFdEP3S2eZSq for ; Thu, 31 Jul 2014 11:49:01 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8CD1A01FF for ; Thu, 31 Jul 2014 11:49:00 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id s18so2461166lam.28 for ; Thu, 31 Jul 2014 11:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=b34R6QwKIMBO0ytE3FPALeJOOLqs8Ijnm4GOBJaktZw=; b=y+ZvT/B9sXpM7CnopS5QYM78iP7AoUMNfuHIiXdEvqEtKUubV68qMI7Zg+S8EgBoFW vYbL06FfQEAyYjDr2FKFeWBN8tWdBgbaf7K9vxvGJdUINl57zbRTGKTuZVl6GdibYYs0 wi9M32ViAcgo9VdYigj6tAAkRyMptTJYeVWuAHev5XDqUDuedt5MRcrIr8B1usvBMTII O1sEKuVaY73mT7XG+dkgVjp7T7fRs7HQRFf30edbK4+cJxbo//Exzc9QhT1Q4/3zyCOn zxZK1/OLdPkFnevsRr3n9IOUdTZfj8YcgWfive5k3M/NszCNPKgNp52Me5b4ei+DZCp8 4hKg== X-Received: by 10.152.42.175 with SMTP id p15mr77760lal.73.1406832539004; Thu, 31 Jul 2014 11:48:59 -0700 (PDT) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPSA id xx9sm9419353lbb.30.2014.07.31.11.48.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jul 2014 11:48:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Jouni In-Reply-To: <19339_1406828489_53DA7FC9_19339_507_2_vpoow8l3d11jllgtnin7jy3y.1406828485751@email.android.com> Date: Thu, 31 Jul 2014 21:48:55 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1D45DC43-3C0A-48AA-A5AA-8A86AFA465AA@gmail.com> References: <53DA7458.5080301@usdonovans.com>, <30A10CA8-0B72-4878-8489-5A3156E070AA@nostrum.com> <19339_1406828489_53DA7FC9_19339_507_2_vpoow8l3d11jllgtnin7jy3y.1406828485751@email.android.com> To: X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/zGduaVfMFtXrQbCJn_UgzreAg_k Cc: "dime@ietf.org" , Ben Campbell Subject: Re: [Dime] Issue #48 - M-bit gives wrong sementics X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 18:49:04 -0000 OK++; On Jul 31, 2014, at 8:41 PM, = wrote: > Ok for me. >=20 > Envoy=E9 depuis mon Sony Xperia SP d'Orange >=20 > ---- Ben Campbell a =E9crit ---- >=20 >=20 > No objection >=20 > On Jul 31, 2014, at 11:52 AM, Steve Donovan = wrote: >=20 >> All, >>=20 >> The proposal coming out of the meeting in Toronto was to close this = issue with no changes to the existing text. >>=20 >> Let me know if there are objections to doing so, otherwise I'll close = the issue. >>=20 >> Regards, >>=20 >> Steve >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Thu Jul 31 12:05:34 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5197A1A0016 for ; Thu, 31 Jul 2014 12:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 VQzvVxNWNlNj for ; Thu, 31 Jul 2014 12:05:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2C9471A0009 for ; Thu, 31 Jul 2014 12:05:31 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6VJ5SXE079950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 Jul 2014 14:05:30 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <19412_1406822144_53DA6700_19412_635_1_6B7134B31289DC4FAF731D844122B36E6847D4@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Thu, 31 Jul 2014 14:05:28 -0500 X-Mao-Original-Outgoing-Id: 428526328.121385-95128ba62c65ee7bd874b64087841142 Content-Transfer-Encoding: quoted-printable Message-Id: <46BF325A-B5C3-42C1-8D7C-BFF033BBD4B1@nostrum.com> References: <53D640F6.5080502@gmail.com> <53D7F720.90503@usdonovans.com> <8374EACC-ACF7-4B22-9AD3-C174A890479F@nostrum.com> <53D9EA3C.5080301@gmail.com> <5735_1406816432_53DA50B0_5735_8214_1_6B7134B31289DC4FAF731D844122B36E68460D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <19412_1406822144_53DA6700_19412_635_1_6B7134B31289DC4FAF731D844122B36E6847D4@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Dixo4WP-3JHCdBnoX_UFWd1_Fi8 Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC: Base protocol vs application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 19:05:33 -0000 Thank you for clarifying that we disagree :-) Details inline: On Jul 31, 2014, at 10:55 AM, lionel.morand@orange.com wrote: > Hi Ben, >=20 > I disagree on the fact that the REQ 2 is not covered by the current = solution providing a generic solution at the application level, without = any impact on the base protocol. > A node that will implement DOIC will have to understand the = application conveying the DOIC AVP. Otherwise, it will not be able to = know what to do when receiving the overload report (e.g. drop the = request, divert, differ, etc.) as this behavior heavily depends on the = application. I disagree. We've gone to a great deal of trouble to separate things so = that an agent without application knowledge can take reasonable action. For example, an agent cannot just drop a request, with our without = application knowledge. It needs to _reject_ a request so that the client = (which already must have application knowledge) can do the right thing. = It can _divert_ a request in a way that is legal across applications. It = may lack knowledge on the best way to prioritize requests under overload = for a specific application, which is why I think agents should prefer = diversion over throttling. But it at least understands what's in a = session and what is not, and can make some decisions that are probably = at least reasonable, if not optimal. (Certainly it could do better with = application specific knowledge, but it should still be better than = nothing.) The idea of abatement algorithms is also intended to be application = independent. Algorithms don't say which messages get abated, only how = many. Ignoring the relay case for the moment (Don't worry, I will pick it up = again further down :-) ), we at least need to allow a proxy to = implement overload control based entirely on DIME specifications. It = should not have to wait for the owner of some application (e.g. 3GPP) to = describe specifics of how to optimize overload control for that = application. This is pretty clearly the intent of RFC 7068, as described = in section 6. >=20 > Now speaking about agent, as per the RFC6733, a Relay or a Redirect, = agent advertizing the Relay App Id (0xffffffff) cannot do much more than = performing look-up into their routing table to select of the next hop = for a given request. If several peers are available for a given entry in = the routing, they may perform some load balance of requests between = peers. But nothing else.=20 ( I'm intentionally ignoring redirect agents, because I think they are = effectively servers. Maybe they can become overloaded too, and should = probably be able to report that. But I think it's enough of an edge case = we can ignore it for the moment.) Relays are allowed to do what you say, and _also_ allowed to insert = specific AVPs that have been designated as "routing information" IMO, = DOIC AVPs should be treated as "routing information". Their purpose is = closely relate to the kind of routing decisions relays already make. Based on this discussion so far, I think in order to achieve our = application independence requirement, DOIC AVPs should be considered = extensions of the base protocol, not application AVPs. This would = require the draft to explicitly update RFC6733. I realize people would = rather use the normal application extension points of Diameter, but I do = not believe they are appropriate for DOIC. > Updating the RFC6733 to indicate that Relay and Redirect must now = support DOIC would be a non-sense as OLR are only meaningful at the = application level to know how to perform efficient overload control. And = an agent that would have to manage something at the application is = called a Proxy, even if the application specific behavior is only = related to the overload control functions.=20 > In the same line, a node that would be designed to relay any = application request and only provide overload control as enhanced = functionality would be a simple proxy that would have to advertize in = CER/CEA all the application-Id used in the network in which it is = deployed and support the abatement treatment to apply per application = (note: the same abatement treatment principle may be reused for multiple = applications). And this node can be reused for any application, as long = as it list of supported app-id and the corresponding abatement = treatments are kept up to date. >=20 > So, in summary, I can agree that your understanding of the REQ2 is not = the same than mine. I could even agree that your understanding is = correct if I'm forced to.=20 I plan to limit myself to persuasion, not force ;-) But in my interpretation of Req 2 (as an editor of RFC 7068), I think = that when you look at the carefully chosen term "node" (the meaning of = which was discussed rather heavily), and in the context of section 6, = treating DOIC AVPs as application AVPs fails to meet the requirement.=20 > And I would then agree that the REQ2 is not fulfilled by a solution at = the application level. But this would not change my position: I'm = perfectly fine with current approach and no update of the RFC6733 is = needed.=20 I would find it very unfortunate if we throw out a MUST level = requirement from RFC 7068 just because we don't want to extend the base = protocol. It's not a question of being able to extend it--any RFC can be = updated. It's not especially costly to do so. If we want to argue that = doing so would be _harmful_, that's different. I haven't seen such an = argument so far. From nobody Thu Jul 31 12:53:18 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4019F1A0054 for ; Thu, 31 Jul 2014 12:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.779 X-Spam-Level: X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 fVFqQZuZ7lRg for ; Thu, 31 Jul 2014 12:53:13 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [66.117.4.208]) (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 E4C7D1A0046 for ; Thu, 31 Jul 2014 12:53:13 -0700 (PDT) Received: from [64.31.33.37] (port=50412 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XCwPS-0004MW-F8 for dime@ietf.org; Thu, 31 Jul 2014 12:53:12 -0700 Message-ID: <53DA9EA2.4010906@usdonovans.com> Date: Thu, 31 Jul 2014 14:53:06 -0500 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dime@ietf.org" Content-Type: multipart/alternative; boundary="------------060905020904070006040706" X-OutGoing-Spam-Status: No, score=-2.9 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: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/x6eKatEv45BYZ-gbXE4GVfOe3ag Subject: [Dime] DOIC issue #58 Proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 19:53:16 -0000 This is a multi-part message in MIME format. --------------060905020904070006040706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, Issue #58 deals with the fact that there can be multiple senders of realm overload report for the same realm. Ulrich proposes one aspect of what is required in the issue description: "In deployments where more than one node is configured to take the role of a reporting node for realm-routed-request reports, reacting nodes may receive in different answer messages different realm-routed-request type OLRs inserted by the different reporting nodes. Although it is expected that the different reporting nodes report more or less the same content, it cannot be expected that reports are 100% synchronized. Especially sequence numbers may differ. To allow reacting nodes correctly detect outdates/replays/freshness of OLRs in this scenario, it is proposed that realm-routed-request type OLRs are extended to contain the Diameter Identity of the reporting node that inserted the realm-routed-request type OLR. (e.g. as already proposed in draft-donovan-dime-agent-overload-01 ). Reporting nodes that insert realm-routed-request type OLRs to answer messages MUST also insert their Diameter Identity. Reacting nodes MUST take the Diameter Identity received within the OLR into account in order to detect outdates/replays/freshness. " I agree with Ulrich that realm reports must include the identity of the DOIC node that sends the report. This would be an optional AVP only required for realm reports. It would not be required for host reports as the identity of the sender of the host report is implicitly defined by the origin-host in the answer message. I also agree that the Diameter Identity of the reporting node be used to determine if a received report is ignored or used to update existing state. To this end I propose that we add wording that for the duration of a realm report, the reacting node only listens for updates to the realm report from from the DOIC node that sent the realm report that resulted in the realm OCS being stored. The effect should be that the reacting node will accept a realm report from anyone when there is no active OLR for the realm but it will only listen to one reporting node when it has an active report. Steve --------------060905020904070006040706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All,

Issue #58 deals with the fact that there can be multiple senders of realm overload report for the same realm. 

Ulrich proposes one aspect of what is required in the issue description:

"In deployments where more than one node is configured to take the role of a reporting node for realm-routed-request reports, reacting nodes may receive in different answer messages different realm-routed-request type OLRs inserted by the different reporting nodes. Although it is expected that the different reporting nodes report more or less the same content, it cannot be expected that reports are 100% synchronized. Especially sequence numbers may differ. To allow reacting nodes correctly detect outdates/replays/freshness of OLRs in this scenario, it is proposed that realm-routed-request type OLRs are extended to contain the Diameter Identity of the reporting node that inserted the realm-routed-request type OLR. (e.g. as already proposed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert realm-routed-request type OLRs to answer messages MUST also insert their Diameter Identity. Reacting nodes MUST take the Diameter Identity received within the OLR into account in order to detect outdates/replays/freshness. "

I agree with Ulrich that realm reports must include the identity of the DOIC node that sends the report.  This would be an optional AVP only required for realm reports.  It would not be required for host reports as the identity of the sender of the host report is implicitly defined by the origin-host in the answer message.

I also agree that the Diameter Identity of the reporting node be used to determine if a received report is ignored or used to update existing state.  To this end I propose that we add wording that for the duration of a realm report, the reacting node only listens for updates to the realm report from from the DOIC node that sent the realm report that resulted in the realm OCS being stored.

The effect should be that the reacting node will accept a realm report from anyone when there is no active OLR for the realm but it will only listen to one reporting node when it has an active report.

Steve



--------------060905020904070006040706-- From nobody Thu Jul 31 13:39:02 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908E01A00FE for ; Thu, 31 Jul 2014 13:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 wk18EOos8Dzf for ; Thu, 31 Jul 2014 13:38:58 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 42E671A0084 for ; Thu, 31 Jul 2014 13:38:58 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6VKctQZ087585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 Jul 2014 15:38:57 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53DA9EA2.4010906@usdonovans.com> Date: Thu, 31 Jul 2014 15:38:55 -0500 X-Mao-Original-Outgoing-Id: 428531935.309541-d6d6b6a5ce080ba9878618722a1a1e70 Content-Transfer-Encoding: quoted-printable Message-Id: <8582F9E8-FA34-4CD9-AC11-0972132F1DDB@nostrum.com> References: <53DA9EA2.4010906@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ljkWy4_V2EIeEGFrC-tq72H7azU Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC issue #58 Proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 20:39:00 -0000 I don't think this problem is limited to realm reports. We already know "agent" reports will have a similar issue. But It can = happen for host reports in at least a few situations: -- Agents that send host reports on behalf of non-supporting servers, = when more than one such agent exists for a given server. -- Agents that modify host reports based on some local policy (e.g. the = mixed capabilities use case.) -- Diameter nodes made up as an aggregate of multiple "boxes". (e.g. a = blade-based system, a cluster behind a server front end), where they may = share a single diameter identity for some purposes. Beyond that, I think if we ever come up with an end-to-end security = solution that is useable for DOIC, it is also likely to require the = originating identity to be inserted into OLRs. Therefore, I think we should generalize this to say the following: =20 -- All OLRs should contain the diameter identity of the originator of = the report. -- If a reacting node has an active OLR for a given entity, it only pays = attention further reports for that entity. with the same originating = identity. In this context, "entity" means the "thing that is = overloaded", i.e. the realm for realm reports, and the host for host = reports. It's worth considering whether an agent that modifies an OLR needs to = change the originating identity to itself. Also whether there is any = value putting this in OC-S-F. On Jul 31, 2014, at 2:53 PM, Steve Donovan = wrote: > All, >=20 > Issue #58 deals with the fact that there can be multiple senders of = realm overload report for the same realm. =20 >=20 > Ulrich proposes one aspect of what is required in the issue = description: >=20 > "In deployments where more than one node is configured to take the = role of a reporting node for realm-routed-request reports, reacting = nodes may receive in different answer messages different = realm-routed-request type OLRs inserted by the different reporting = nodes. Although it is expected that the different reporting nodes report = more or less the same content, it cannot be expected that reports are = 100% synchronized. Especially sequence numbers may differ. To allow = reacting nodes correctly detect outdates/replays/freshness of OLRs in = this scenario, it is proposed that realm-routed-request type OLRs are = extended to contain the Diameter Identity of the reporting node that = inserted the realm-routed-request type OLR. (e.g. as already proposed in = draft-donovan-dime-agent-overload-01). Reporting nodes that insert = realm-routed-request type OLRs to answer messages MUST also insert their = Diameter Identity. Reacting nodes MUST take the Diameter Identity = received within the OLR into account in order to detect = outdates/replays/freshness. " >=20 > I agree with Ulrich that realm reports must include the identity of = the DOIC node that sends the report. This would be an optional AVP only = required for realm reports. It would not be required for host reports = as the identity of the sender of the host report is implicitly defined = by the origin-host in the answer message. >=20 > I also agree that the Diameter Identity of the reporting node be used = to determine if a received report is ignored or used to update existing = state. To this end I propose that we add wording that for the duration = of a realm report, the reacting node only listens for updates to the = realm report from from the DOIC node that sent the realm report that = resulted in the realm OCS being stored. >=20 > The effect should be that the reacting node will accept a realm report = from anyone when there is no active OLR for the realm but it will only = listen to one reporting node when it has an active report. >=20 > Steve >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Thu Jul 31 14:03:36 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5921A0171 for ; Thu, 31 Jul 2014 14:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 RmLqSfC4PmZF for ; Thu, 31 Jul 2014 14:03:33 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 41DE91A010A for ; Thu, 31 Jul 2014 14:03:33 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6VL3UcH089770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 31 Jul 2014 16:03:32 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: Ben Campbell Content-Type: text/plain; charset=us-ascii X-Mao-Original-Outgoing-Id: 428533409.577739-abef22d4cf908693cc88f8b2495388a4 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Message-Id: Date: Thu, 31 Jul 2014 16:03:29 -0500 To: "dime@ietf.org list" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7cDQLrcuPbfJ5h_9XGHTV72S1I8 Subject: [Dime] DOIC terminology thought X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 21:03:35 -0000 Hi, The DOIC agent use case draft that Steve and I submitted proposed the = terms Transaction Client and Transaction Server to talk about the roles = in the context of transaction direction, rather than in the context of = network purpose as in the way RFC 6733 defines "client" and "server". In an offline email, Dave proposed the alternatives of "Requestor" and = "Answerer". I like those better, since they capture the idea in a single = word, and avoid the temptation to introduce Yet Another Acronym (YAA). Thoughts?= From nobody Thu Jul 31 14:39:12 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C79401A008F for ; Thu, 31 Jul 2014 14:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 DDgECbLkXmEx for ; Thu, 31 Jul 2014 14:39:08 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9151B1A0171 for ; Thu, 31 Jul 2014 14:39:08 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id ty20so2557472lab.18 for ; Thu, 31 Jul 2014 14:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=37kOmv5nxW6qBptv+G6xC3nvjhb6YtdDnH2DUu+bnfA=; b=Ub6ihIKF04lKfyT7NxxOS0Ixgcg8ZZVrDYMep26JijGBz+eaCf9q8tNZSuT2u8+JuS e1W/dwphdFTaEDLfp+qxS9cDCpklG5wmIKX63O5dbt0daz+uUfD8GnU4kijWlqzR7cZO phr/B8djUawP5Pe52F90b4PcMxwIY+g0ayZij4NGbaUgyS3Gl2yod17zdEmYL1Ea/c7x r5HahFNHLgBpdfc4qYjo/cZP/Pk5lgJda1toMANy9jWet/WLOGdA5OcFxx/30VtN74fm etZnUf74h2NPhbabMaNaZzyhAgnxVfyG066eJNmarIB4AsiosDYoCfyeMXWRAKfsBpID kNmw== X-Received: by 10.152.7.70 with SMTP id h6mr992898laa.96.1406842746882; Thu, 31 Jul 2014 14:39:06 -0700 (PDT) Received: from [10.17.0.21] ([83.150.126.201]) by mx.google.com with ESMTPSA id ba16sm3574229lab.45.2014.07.31.14.39.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jul 2014 14:39:06 -0700 (PDT) Message-ID: <53DAB779.5000303@gmail.com> Date: Fri, 01 Aug 2014 00:39:05 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Campbell , lionel.morand@orange.com References: <53D640F6.5080502@gmail.com> <53D7F720.90503@usdonovans.com> <8374EACC-ACF7-4B22-9AD3-C174A890479F@nostrum.com> <53D9EA3C.5080301@gmail.com> <5735_1406816432_53DA50B0_5735_8214_1_6B7134B31289DC4FAF731D844122B36E68460D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <19412_1406822144_53DA6700_19412_635_1_6B7134B31289DC4FAF731D844122B36E6847D4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <46BF325A-B5C3-42C1-8D7C-BFF033BBD4B1@nostrum.com> In-Reply-To: <46BF325A-B5C3-42C1-8D7C-BFF033BBD4B1@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-JjGViwMj_SUVLrRWNHpAX6G42I Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC: Base protocol vs application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 21:39:10 -0000 Restating my view here.. 7/31/2014 10:05 PM, Ben Campbell kirjoitti: >> Now speaking about agent, as per the RFC6733, a Relay or a Redirect, agent advertizing the Relay App Id (0xffffffff) cannot do much more than performing look-up into their routing table to select of the next hop for a given request. If several peers are available for a given entry in the routing, they may perform some load balance of requests between peers. But nothing else. > > ( I'm intentionally ignoring redirect agents, because I think they are effectively servers. Maybe they can become overloaded too, and should probably be able to report that. But I think it's enough of an edge case we can ignore it for the moment.) > > Relays are allowed to do what you say, and _also_ allowed to insert specific AVPs that have been designated as "routing information" IMO, DOIC AVPs should be treated as "routing information". Their purpose is closely relate to the kind of routing decisions relays already make. A "node" as a proxy is somewhat trivial. It does not receive application messages it does not advertise. Thus a DOICable "node" that is a proxy implicitly supports DOIC for applications it advertises from external viewer point of views. Wheteher the proxy _implementation_ is actually able to do "DOIC stuff" on all applications it advertises, is another thing. A "node" as a DOICable relay can do DOIC stuff to _any_ application within certain limits. If the "DOIC stuff" is just applying the abatement, then that is OK for _any_ application depending on the abatement algorithm. If the "DOIC stuff" is beyond that e.g. adding/removing DOIC AVPs then the DOICable relay has to be application aware _internally_ i.e. a proxy.. otherwise it might e.g. cause trouble with applications whose messages' CCF has no *[AVP]. In that regard, I would have hard time understanding why such "relay" is not acting as a proxy to its peers. I agree more with Lionel that "relay" shall not fiddle around with non-routing AVPs. On the other hand, if everybody agrees that DOIC AVPs are _routing_information_ I have no issue relays fooling around with DOIC AVPs in the messages. The thing we need keep in mind is that if we have e.g. multiple agent nodes in a row, an agent on the path that is not DOICable MUST NOT get confused if other DOICable agents do weird stuff. So at the very end, what goes on wire is the key and has to be RFC6733 compliant. - Jouni > > Based on this discussion so far, I think in order to achieve our application independence requirement, DOIC AVPs should be considered extensions of the base protocol, not application AVPs. This would require the draft to explicitly update RFC6733. I realize people would rather use the normal application extension points of Diameter, but I do not believe they are appropriate for DOIC. > From nobody Thu Jul 31 14:45:25 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68051A0178 for ; Thu, 31 Jul 2014 14:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 n1GmJ2xJzShH for ; Thu, 31 Jul 2014 14:45:21 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C63F71A008F for ; Thu, 31 Jul 2014 14:45:21 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s6VLjH9r093338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 31 Jul 2014 16:45:19 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell In-Reply-To: <53DAB779.5000303@gmail.com> Date: Thu, 31 Jul 2014 16:45:16 -0500 X-Mao-Original-Outgoing-Id: 428535916.885079-d1f04c120f36937c377310b722bbbc45 Content-Transfer-Encoding: quoted-printable Message-Id: <5EFE4D16-4C2E-4583-8D40-5C70F9FE1FE7@nostrum.com> References: <53D640F6.5080502@gmail.com> <53D7F720.90503@usdonovans.com> <8374EACC-ACF7-4B22-9AD3-C174A890479F@nostrum.com> <53D9EA3C.5080301@gmail.com> <5735_1406816432_53DA50B0_5735_8214_1_6B7134B31289DC4FAF731D844122B36E68460D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <19412_1406822144_53DA6700_19412_635_1_6B7134B31289DC4FAF731D844122B36E6847D4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <46BF325A-B5C3-42C1-8D7C-BFF033BBD4B1@nostrum.com> <53DAB779.5000303@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qDqL2P_lyQfKibEHfEIijnTBaWc Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC: Base protocol vs application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jul 2014 21:45:23 -0000 On Jul 31, 2014, at 4:39 PM, Jouni Korhonen = wrote: > Restating my view here.. >=20 > 7/31/2014 10:05 PM, Ben Campbell kirjoitti: >>> Now speaking about agent, as per the RFC6733, a Relay or a Redirect, = agent advertizing the Relay App Id (0xffffffff) cannot do much more than = performing look-up into their routing table to select of the next hop = for a given request. If several peers are available for a given entry in = the routing, they may perform some load balance of requests between = peers. But nothing else. >>=20 >> ( I'm intentionally ignoring redirect agents, because I think they = are effectively servers. Maybe they can become overloaded too, and = should probably be able to report that. But I think it's enough of an = edge case we can ignore it for the moment.) >>=20 >> Relays are allowed to do what you say, and _also_ allowed to insert = specific AVPs that have been designated as "routing information" IMO, = DOIC AVPs should be treated as "routing information". Their purpose is = closely relate to the kind of routing decisions relays already make. >=20 > A "node" as a proxy is somewhat trivial. It does not receive = application messages it does not advertise. Thus a DOICable "node" that = is a proxy implicitly supports DOIC for applications it advertises from = external viewer point of views. Wheteher the proxy _implementation_ is = actually able to do "DOIC stuff" on all applications it advertises, is = another thing. I don't think we have much controversy about DOICable proxies. >=20 > A "node" as a DOICable relay can do DOIC stuff to _any_ application = within certain limits. If the "DOIC stuff" is just applying the = abatement, then that is OK for _any_ application depending on the = abatement algorithm. If the "DOIC stuff" is beyond that e.g. = adding/removing DOIC AVPs then the DOICable relay has to be application = aware _internally_ i.e. a proxy.. otherwise it might e.g. cause trouble = with applications whose messages' CCF has no *[AVP]. Adam did a survey way back when, and found that such applications are = vanishingly rare. (Was it just the watchdog application?). Hopefully = people won't try to define new applications without *[AVP]/ > In that regard, I would have hard time understanding why such "relay" = is not acting as a proxy to its peers. I agree more with Lionel that = "relay" shall not fiddle around with non-routing AVPs. On the other = hand, if everybody agrees that DOIC AVPs are _routing_information_ I = have no issue relays fooling around with DOIC AVPs in the messages. >=20 > The thing we need keep in mind is that if we have e.g. multiple agent = nodes in a row, an agent on the path that is not DOICable MUST NOT get = confused if other DOICable agents do weird stuff. So at the very end, = what goes on wire is the key and has to be RFC6733 compliant. I agree completely. >=20 > - Jouni >=20 >>=20 >> Based on this discussion so far, I think in order to achieve our = application independence requirement, DOIC AVPs should be considered = extensions of the base protocol, not application AVPs. This would = require the draft to explicitly update RFC6733. I realize people would = rather use the normal application extension points of Diameter, but I do = not believe they are appropriate for DOIC. >>=20 From nobody Thu Jul 31 22:37:12 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38831A0402 for ; Thu, 31 Jul 2014 22:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 QU36x4tHE4Xq for ; Thu, 31 Jul 2014 22:37:10 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD0A1A01E0 for ; Thu, 31 Jul 2014 22:37:09 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id c11so2804219lbj.19 for ; Thu, 31 Jul 2014 22:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5QYKbNvEC/xAetNvNPpGbkUzT5b8HeMiOO6hjTb61QI=; b=E1XpkYdailrZ88X9xcYl7zbfrD3+qHrGofgLr8QVtRO2oyee+NwUTfZsedKkA8cDZC iHg4mGla6QBToV6WEcuDXX8dvH6MrMPMGwh73iN/zzSFtRvACQ20ynlL/Wy4bpAS6uxF tozeI8i0SatWfTXDvUf118YiwYTs5P/yoVermQ8vz/aEqruTX3l1/Ny9J3SySUYcuQpw QPf+pxOIE9tNqbFj3jPe9M27jufH3uCk0k40yPRbyQpCnghzDap7FkLJ2VKOrfZibQN6 etdNO6TqWO99V7s8YsuZeZI653H7DGwEFtYygMjq8wiiF0SdBju3V2cpm3xmjXfJXabF XkcA== X-Received: by 10.112.170.10 with SMTP id ai10mr2694730lbc.93.1406871427961; Thu, 31 Jul 2014 22:37:07 -0700 (PDT) Received: from [10.17.0.21] ([83.150.126.201]) by mx.google.com with ESMTPSA id s1sm4117166las.49.2014.07.31.22.37.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jul 2014 22:37:07 -0700 (PDT) Message-ID: <53DB2782.4080909@gmail.com> Date: Fri, 01 Aug 2014 08:37:06 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Campbell References: <53D640F6.5080502@gmail.com> <53D7F720.90503@usdonovans.com> <8374EACC-ACF7-4B22-9AD3-C174A890479F@nostrum.com> <53D9EA3C.5080301@gmail.com> <5735_1406816432_53DA50B0_5735_8214_1_6B7134B31289DC4FAF731D844122B36E68460D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <19412_1406822144_53DA6700_19412_635_1_6B7134B31289DC4FAF731D844122B36E6847D4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <46BF325A-B5C3-42C1-8D7C-BFF033BBD4B1@nostrum.com> <53DAB779.5000303@gmail.com> <5EFE4D16-4C2E-4583-8D40-5C70F9FE1FE7@nostrum.com> In-Reply-To: <5EFE4D16-4C2E-4583-8D40-5C70F9FE1FE7@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dime/IVezttePszbFEQFUTkg3GdiOlE0 Cc: "dime@ietf.org" Subject: Re: [Dime] DOIC: Base protocol vs application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 05:37:11 -0000 Ben, 8/1/2014 12:45 AM, Ben Campbell kirjoitti: > > On Jul 31, 2014, at 4:39 PM, Jouni Korhonen wrote: > >> Restating my view here.. >> >> 7/31/2014 10:05 PM, Ben Campbell kirjoitti: >>>> Now speaking about agent, as per the RFC6733, a Relay or a Redirect, agent advertizing the Relay App Id (0xffffffff) cannot do much more than performing look-up into their routing table to select of the next hop for a given request. If several peers are available for a given entry in the routing, they may perform some load balance of requests between peers. But nothing else. >>> >>> ( I'm intentionally ignoring redirect agents, because I think they are effectively servers. Maybe they can become overloaded too, and should probably be able to report that. But I think it's enough of an edge case we can ignore it for the moment.) >>> >>> Relays are allowed to do what you say, and _also_ allowed to insert specific AVPs that have been designated as "routing information" IMO, DOIC AVPs should be treated as "routing information". Their purpose is closely relate to the kind of routing decisions relays already make. >> >> A "node" as a proxy is somewhat trivial. It does not receive application messages it does not advertise. Thus a DOICable "node" that is a proxy implicitly supports DOIC for applications it advertises from external viewer point of views. Wheteher the proxy _implementation_ is actually able to do "DOIC stuff" on all applications it advertises, is another thing. > > I don't think we have much controversy about DOICable proxies. > >> >> A "node" as a DOICable relay can do DOIC stuff to _any_ application within certain limits. If the "DOIC stuff" is just applying the abatement, then that is OK for _any_ application depending on the abatement algorithm. If the "DOIC stuff" is beyond that e.g. adding/removing DOIC AVPs then the DOICable relay has to be application aware _internally_ i.e. a proxy.. otherwise it might e.g. cause trouble with applications whose messages' CCF has no *[AVP]. > > Adam did a survey way back when, and found that such applications are vanishingly rare. (Was it just the watchdog application?). Hopefully people won't try to define new applications without *[AVP]/ I know. *[AVP] was just an example. Another example would be new applications that embed DOIC as a part of their formal CCF and there even changing the location of the DOIC AVP could break the CCF check. - Jouni >> In that regard, I would have hard time understanding why such "relay" is not acting as a proxy to its peers. I agree more with Lionel that "relay" shall not fiddle around with non-routing AVPs. On the other hand, if everybody agrees that DOIC AVPs are _routing_information_ I have no issue relays fooling around with DOIC AVPs in the messages. >> >> The thing we need keep in mind is that if we have e.g. multiple agent nodes in a row, an agent on the path that is not DOICable MUST NOT get confused if other DOICable agents do weird stuff. So at the very end, what goes on wire is the key and has to be RFC6733 compliant. > > I agree completely. > >> >> - Jouni >> >>> >>> Based on this discussion so far, I think in order to achieve our application independence requirement, DOIC AVPs should be considered extensions of the base protocol, not application AVPs. This would require the draft to explicitly update RFC6733. I realize people would rather use the normal application extension points of Diameter, but I do not believe they are appropriate for DOIC. >>> > From nobody Thu Jul 31 22:40:27 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723A81A01E0 for ; Thu, 31 Jul 2014 22:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 4MVjFoqDqOWz for ; Thu, 31 Jul 2014 22:40:22 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186A41A01BA for ; Thu, 31 Jul 2014 22:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13827; q=dns/txt; s=iport; t=1406871622; x=1408081222; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Jdy94l8EEHCNrdKLvx7hcBLhiUWiAuivruTECe3VeL8=; b=mXiDwTLkCXSTvAx099xT+MTr/R339MdAxp27ES9sZY4twNql3cREv3Eg oumvXvMEQfkdv9B+kVWg5W6WVbi/EZ0CrNf2Kz6TSbDalxcko8xz260AO Sdbq60eJuNH6xTWDpNee7CY9ImVXB0V52HNVwXumbXTeTX1QEzVhjQaOx g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAFABQn21OtJA2I/2dsb2JhbABSCYJHRlJXBMopgWKHSwGBChZ3hAMBAQEELVwCAQgOAwQBAQsLEgcyFAkIAgQBEggTiCcNyy0XjnEqNwEGBIMlgRwFjmyIYIV9kwSDSWyBRQ X-IronPort-AV: E=Sophos;i="5.01,777,1400025600"; d="scan'208,217";a="344411377" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-4.cisco.com with ESMTP; 01 Aug 2014 05:40:20 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s715eKZE029840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 05:40:20 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 00:40:20 -0500 From: "Nirav Salot (nsalot)" To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] DOIC issue #58 Proposal Thread-Index: AQHPrPj5lwrN9479MEmgKHB41eF0/5u7N7ZA Date: Fri, 1 Aug 2014 05:40:20 +0000 Message-ID: References: <53DA9EA2.4010906@usdonovans.com> In-Reply-To: <53DA9EA2.4010906@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.140.45] Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA018DDD444xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/4o_1O8bKI_Bvqhm-rLHNwQvjKVg Subject: Re: [Dime] DOIC issue #58 Proposal X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 05:40:26 -0000 --_000_A9CA33BB78081F478946E4F34BF9AAA018DDD444xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, For this issue, I don't agree to include identity of the DOIC node that sen= ds the report, into the realm reports. In my view, the issue mentioned below - of two agents not 100% synchronize = w.r.t the realm-report - is the related to "how agents synchronized between= themselves" and since that is not standardized we should not be developing= protocol solution for the case which occurs due to this out-of-standards s= olution. Besides, I don't see any issue due to slight miss-synchronization of the re= alm-reports between two agents since they should still represent the realm = load more or less accurately. Also if the agents are not synchronized and if they are playing the role of= DOIC reacting node then they will apply abatement algorithm based on diffe= rent values (for the same realm). So it does not matter if the client does = the same. Finally, I don't see any value-add of using the "identity of the node that = sends the realm-report" to discard the other report related to the same rea= lm. In other words, this same logic can be achieved using sequence-numbers = as well, i.e. when the overload-report of an realm is active, the client is= going to ignore all the reports of the same realm which has lower sequence= number value. So in essence, when two agents are sending realm-reports, on= e of the reports is automatically ignored by the client if their sequence n= umbers differ. So the outcome without including the "identity if the node t= hat sends realm report" is same as >The effect should be that the reacting node will accept a realm report fro= m anyone when there is no active OLR for the realm but it will only listen = to one reporting node when it has an active report. Regards, Nirav. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Friday, August 01, 2014 1:23 AM To: dime@ietf.org Subject: [Dime] DOIC issue #58 Proposal All, Issue #58 deals with the fact that there can be multiple senders of realm o= verload report for the same realm. Ulrich proposes one aspect of what is required in the issue description: "In deployments where more than one node is configured to take the role of = a reporting node for realm-routed-request reports, reacting nodes may recei= ve in different answer messages different realm-routed-request type OLRs in= serted by the different reporting nodes. Although it is expected that the d= ifferent reporting nodes report more or less the same content, it cannot be= expected that reports are 100% synchronized. Especially sequence numbers m= ay differ. To allow reacting nodes correctly detect outdates/replays/freshn= ess of OLRs in this scenario, it is proposed that realm-routed-request type= OLRs are extended to contain the Diameter Identity of the reporting node t= hat inserted the realm-routed-request type OLR. (e.g. as already proposed i= n draft-donovan-dime-agent-overload-01). Reporting nodes that insert realm-routed-req= uest type OLRs to answer messages MUST also insert their Diameter Identity.= Reacting nodes MUST take the Diameter Identity received within the OLR int= o account in order to detect outdates/replays/freshness. " I agree with Ulrich that realm reports must include the identity of the DOI= C node that sends the report. This would be an optional AVP only required = for realm reports. It would not be required for host reports as the identi= ty of the sender of the host report is implicitly defined by the origin-hos= t in the answer message. I also agree that the Diameter Identity of the reporting node be used to de= termine if a received report is ignored or used to update existing state. = To this end I propose that we add wording that for the duration of a realm = report, the reacting node only listens for updates to the realm report from= from the DOIC node that sent the realm report that resulted in the realm O= CS being stored. The effect should be that the reacting node will accept a realm report from= anyone when there is no active OLR for the realm but it will only listen t= o one reporting node when it has an active report. Steve --_000_A9CA33BB78081F478946E4F34BF9AAA018DDD444xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Steve,<= /p>

 <= /p>

For this issue, I donR= 17;t agree to include identity of the DOIC node that sends the report, into= the realm reports.

 <= /p>

In my view, the issue men= tioned below – of two agents not 100% synchronize w.r.t the realm-rep= ort – is the related to "how agents synchronized between themsel= ves" and since that is not standardized we should not be developing protocol so= lution for the case which occurs due to this out-of-standards solution.

 <= /p>

Besides, I don’t se= e any issue due to slight miss-synchronization of the realm-reports between= two agents since they should still represent the realm load more or less accurately.

 <= /p>

Also if the agents are no= t synchronized and if they are playing the role of DOIC reacting node then = they will apply abatement algorithm based on different values (for the same realm). So it does not matter if the client does the same.

 <= /p>

Finally, I don’t se= e any value-add of using the "identity of the node that sends the real= m-report" to discard the other report related to the same realm. In other words, this same logic can be achieved using sequence-numbers as wel= l, i.e. when the overload-report of an realm is active, the client is going= to ignore all the reports of the same realm which has lower sequence numbe= r value. So in essence, when two agents are sending realm-reports, one of the reports is automatically igno= red by the client if their sequence numbers differ. So the outcome without = including the "identity if the node that sends realm report" is s= ame as

>The effect should be that the reacting node will= accept a realm report from anyone when there is no active OLR for the real= m but it will only listen to one reporting node when it has an active repor= t.

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Friday, August 01, 2014 1:23 AM
To: dime@ietf.org
Subject: [Dime] DOIC issue #58 Proposal

 

All,

Issue #58 deals with the fact that there can be multiple senders of realm o= verload report for the same realm. 

Ulrich proposes one aspect of what is required in the issue description:
"In deployments where more than one node is configured to take the rol= e of a reporting node for realm-routed-request reports, reacting nodes may = receive in different answer messages different realm-routed-request type OL= Rs inserted by the different reporting nodes. Although it is expected that the different reporting nodes report m= ore or less the same content, it cannot be expected that reports are 100% s= ynchronized. Especially sequence numbers may differ. To allow reacting node= s correctly detect outdates/replays/freshness of OLRs in this scenario, it is proposed that realm-routed-request type OL= Rs are extended to contain the Diameter Identity of the reporting node that= inserted the realm-routed-request type OLR. (e.g. as already proposed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert rea= lm-routed-request type OLRs to answer messages MUST also insert their Diame= ter Identity. Reacting nodes MUST take the Diameter Identity received within the OLR into account in order t= o detect outdates/replays/freshness. "

I agree with Ulrich that realm reports must include the identity of the DOI= C node that sends the report.  This would be an optional AVP only requ= ired for realm reports.  It would not be required for host reports as = the identity of the sender of the host report is implicitly defined by the origin-host in the answer message.

I also agree that the Diameter Identity of the reporting node be used to de= termine if a received report is ignored or used to update existing state.&n= bsp; To this end I propose that we add wording that for the duration of a r= ealm report, the reacting node only listens for updates to the realm report from from the DOIC node that sent the real= m report that resulted in the realm OCS being stored.

The effect should be that the reacting node will accept a realm report from= anyone when there is no active OLR for the realm but it will only listen t= o one reporting node when it has an active report.

Steve


--_000_A9CA33BB78081F478946E4F34BF9AAA018DDD444xmbrcdx10ciscoc_--