Re: [Dime] Issue#30 status

Ben Campbell <ben@nostrum.com> Wed, 26 February 2014 15:13 UTC

Return-Path: <ben@nostrum.com>
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 2BD0E1A0688 for <dime@ietfa.amsl.com>; Wed, 26 Feb 2014 07:13:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 h7MhlS7DcShb for <dime@ietfa.amsl.com>; Wed, 26 Feb 2014 07:13:54 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DB41A067D for <dime@ietf.org>; Wed, 26 Feb 2014 07:13:54 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1QFDpOK011369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Feb 2014 09:13:52 -0600 (CST) (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.29]
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net>
Date: Wed, 26 Feb 2014 09:13:49 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <18EEB293-F277-48EF-86B0-49FED3A87CD0@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net> <B5E91287-7462-4531-9F48-C5F124C19BE3@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/L-hJ3UO8NKbZ7WrPKqlf74id5PQ
Cc: "dime@ietf.org list" <dime@ietf.org>
Subject: Re: [Dime] Issue#30 status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2014 15:13:57 -0000

On Feb 26, 2014, at 7:01 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:

> Steve,
>  
> that is neither correct nor did we agree so.
>  
> No OLR means “no change”, it does not mean “no overload”.
> When a reporting node is not in overload, it still is allowed to send OLRs (indicating no overload/ end of overload) just to make sure that the reacting node has up to date information (it needs not do so when it knows that the reacting node already has sufficiently up to date information).

I agree that this is technically true. But in the case where the reacting node has not been informed of an overload condition, or all such conditions have expired, "no chance" is the same as "no overload". And unless we choose to mandate an OLR in every answer (which would be much more costly than mandating OC-Supported-Features), we are back where we started.

>  
> Ulrich
>  
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] 
> Sent: Wednesday, February 26, 2014 1:35 PM
> To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
> Cc: dime@ietf.org list
> Subject: Re: [Dime] Issue#30 status
>  
> Ulrich,
> 
> An OLR is included in every answer message only when the reporting node is in an overload state.  There are no overload reports when the reacting node is not overloaded.
> 
> Steve
> 
> On 2/26/14 3:23 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Steve, Ben, all,
>  
> on 1) we seem to agree that OC-Supported-Features in answers is not required for loss i.e. not required for  draft-ietf-dime-ovli. We can  leave it up to drafts associated with new abatement algorithms to specify the requirement to include OC-Supported-Features in answers if so needed (I still don't see the need even for rate or other algorithms); that needs to be discussed when discussing those drafts.
>  
> On 2) I understand the usecase, but I'm not sure whether we have this requirement of selective proactive throttling (see e-mail from Lionel). Anyway, given the conclusion on #31, OLR will be included in all answer messages (exept when the reporting node is aware that the reacting node already knows). Therefore the reacting node can deduce support of DOIC by the reporting node from the presence of OLR (if OLR is present then DOIC is supported by the reporting node; if OLR is absent, then reacting node already knows whether or not DOIC is supported by the reporting node).
>  
> Ulrich
>  
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Ben Campbell
> Sent: Tuesday, February 25, 2014 12:02 AM
> To: Steve Donovan
> Cc: dime@ietf.org list
> Subject: Re: [Dime] Issue#30 status
>  
>  
> On Feb 24, 2014, at 2:12 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:
>  
> I can see two additional reasons for requiring OC-Supported-Features:
>  
> 1) If the reacting node needs to know in advance whether the type of overload abatement the reporting node will ask for.
>  
> this is not needed in the case of the loss abatement algorithm as the reacting node can just immediately start throttling the appropriate number of requests.  It does not require prior knowledge of the traffic sent.
>  
> There are abatement algorithms that do require the client to keep state about traffic sent to specific destinations.  We can, if we choose, leave it up to the drafts associated with the new abatement algorithms to specify the requirement to include OC-Supported-Features, as proposed by Ulrich.
>  
> 2) If the reacting node can use the absence of the OC-Supported-Features AVP in answer messages to know that there is no Diameter overload supported in the network and thus take other measures to protect the Diameter network.  For example, I can envision a client implementation that adapts to the knowledge of whether servers support overload.  In the case that the server does support overload the client can send unlimited traffic to the server, up to the point that the server sends an OLR.  If the client determines that the server does not support overload then it might have a configured maximum rate that it will send to the server.
>  
> My inclination is to include the OC-Supported-Features AVP in answers because most abatement algorithms will need it and because it can lead to better implementation client implementations.
>  
> +1 on both points
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>  
>