[Dime] U-S-U exceeding G-S-U and RFC4006bis

Dave Dolson <ddolson@sandvine.com> Mon, 27 June 2016 14:19 UTC

Return-Path: <ddolson@sandvine.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 43BE312D52C for <dime@ietfa.amsl.com>; Mon, 27 Jun 2016 07:19:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id k2usLY6-FUFs for <dime@ietfa.amsl.com>; Mon, 27 Jun 2016 07:19:58 -0700 (PDT)
Received: from mail1.sandvine.com (mail1.sandvine.com []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BB6212D593 for <dime@ietf.org>; Mon, 27 Jun 2016 07:19:50 -0700 (PDT)
Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Mon, 27 Jun 2016 10:19:48 -0400
From: Dave Dolson <ddolson@sandvine.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: U-S-U exceeding G-S-U and RFC4006bis
Thread-Index: AdHQfvVTjXLP8kslRyGUSAR4/Mvp9Q==
Date: Mon, 27 Jun 2016 14:19:47 +0000
Message-ID: <E8355113905631478EFF04F5AA706E9830FD2151@wtl-exchp-2.sandvine.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/3hsA4JMylGuZzLhifxUT9zEzfKY>
Subject: [Dime] U-S-U exceeding G-S-U and RFC4006bis
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2016 14:19:59 -0000

I propose that RFC4006bis include some clarification about reporting of used units.

The first paragraph of section 5.3 in RFC4006 says,
    "... a new Credit-
    Control-Request MUST be sent to the credit-control server when the
    credit reservation has been wholly consumed, or upon expiration of
    the Validity-Time."

In practice, a credit reservation is seldom precisely consumed. When the reservation is exceeded, it is exceeded by a non-zero amount.

The standard doesn't explicitly say whether the client may report a USU greater than the earlier GSU, but it seems to be implicitly allowed.

I propose adding this clarifying paragraph to section 5.3:

    In the case that the used units exceed the granted units at the time
    of reporting, the client SHOULD report all used units; if
    the client does not report all used units, it MUST save
    those used units for reporting in the next grant.

Later language in the section says, "The credit-control server MUST deduct the used amount from the end
user's account." I propose softening it to this:

    The credit-control server MUST deduct the used amount from the end
    user's account. In the case that the used units exceed the available
    credit, whether to allow the end-user into a deficit is a matter
    of local policy.