Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?

Jouni Korhonen <jouni.nospam@gmail.com> Mon, 10 February 2014 16:07 UTC

Return-Path: <jouni.nospam@gmail.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 A715F1A086D for <dime@ietfa.amsl.com>; Mon, 10 Feb 2014 08:07:05 -0800 (PST)
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 yVko3YF8wojF for <dime@ietfa.amsl.com>; Mon, 10 Feb 2014 08:07:02 -0800 (PST)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C4A1C1A0320 for <dime@ietf.org>; Mon, 10 Feb 2014 08:07:01 -0800 (PST)
Received: by mail-la0-f43.google.com with SMTP id pv20so5018579lab.30 for <dime@ietf.org>; Mon, 10 Feb 2014 08:07:01 -0800 (PST)
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=ZUlF+u8CTDIwP21tnaP/+51JSoLxtNCo29WHmdbhkFw=; b=X4ZnAyNg2HGDFuLM4MZnN5wAKhZ3vbGpaNfZUgjNapfH1NiVUiZFXtzwjFuSXgvPMu UnJ8QsxB6hdxQJc0B1s6LyXBCfPwuUr5P61ATy+fPH1A403Dk0mP4FJDgYpUlmrOlEUM WgOk8DSr9ex+teZ+bMrDQHhI5YLjyPG+AWzCtREfQVfc9LZOfIKjBObnqQNxfMz571tu nZJBJy2lMK1uG3RIPM1GSZ9ai0XGHgVNnirhZ+zgAHs2EuIzxiJXQJh7iiDjHKda8oO/ iCx2q7waucq5GwzW6NknTV1YRx0/bA9Lu0WuKs5l72JIoHtZ+rv2MhX0Gb1PZrm/3paz Z4vQ==
X-Received: by 10.112.90.5 with SMTP id bs5mr748279lbb.66.1392048420954; Mon, 10 Feb 2014 08:07:00 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id 10sm22917544lan.5.2014.02.10.08.06.56 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 08:06:57 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen <jouni.nospam@gmail.com>
In-Reply-To: <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>
Date: Mon, 10 Feb 2014 18:06:56 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B28458B2-D601-4914-B51D-C05C61B3DCB8@gmail.com>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org> <A27A0204-5080-46F6-B1F4-B4FE1CB1AD5D@gmail.com> <889030ED-A32B-442D-BE2D-674950AA769E@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.1510)
Cc: "dime@ietf.org list" <dime@ietf.org>, draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #45: Why is a validity duration of 0 disallowed?
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: Mon, 10 Feb 2014 16:07:05 -0000

Ben,

Propose some text and we can see how it fits in.

- Jouni


On Feb 10, 2014, at 5:53 PM, Ben Campbell <ben@nostrum.com> wrote:

> 
> On Feb 10, 2014, at 5:12 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:
> 
>> 
>> On Feb 7, 2014, at 11:54 PM, dime issue tracker <trac+dime@trac.tools.ietf.org> wrote:
>> 
>>> #45: Why is a validity duration of 0 disallowed?
>>> 
>>> Section 4.5 disallows a validity duration of zero. Why do we want to
>>> disallow that? It would allow a quick way of ending any existing overload
>>> condition without worrying about the semantics of the abatement algorithm.
>>> (We currently use a reduction percentage of zero to end an overload
>>> condition--but that's specific to the loss algorithm and might not make
>>> sense for all future ones.)
>> 
>> Right. Avoiding two ways of ending overload condition was the reason.
>> I am OK to have validity duration 0 as an additional method ending the
>> overload condition based on the reasoning above.
>> 
> 
> I would go further and make duration 0 the _preferred_ way, for two reasons:
> 
> 1) It's algorithm independent. (reduction-percentage of 0 is specific to algorithms that use reduction percentage.)
> 
> 2) Explicit signaling of the end of an overload condition becomes semantically identical to the expiration of an overload condition. This allows a simpler implementation.
> 
>