[Dime] draft-bertz-dime-rfc4006bis - adding a procedure for zero grants

Yuval Lifshitz <ylifshitz@sandvine.com> Wed, 29 June 2016 19:37 UTC

Return-Path: <ylifshitz@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 2152C12DED0 for <dime@ietfa.amsl.com>; Wed, 29 Jun 2016 12:37:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.345
X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 jVEuSu4qFyK5 for <dime@ietfa.amsl.com>; Wed, 29 Jun 2016 12:37:38 -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 ECE2512DEC7 for <dime@ietf.org>; Wed, 29 Jun 2016 12:37:37 -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, 29 Jun 2016 15:37:36 -0400
From: Yuval Lifshitz <ylifshitz@sandvine.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: draft-bertz-dime-rfc4006bis - adding a procedure for zero grants
Thread-Index: AdHSPOVQCliJhgoMTCegv0x0lUx+Qg==
Date: Wed, 29 Jun 2016 19:37:36 +0000
Message-ID: <C43C255C7106314F8D13D03FA20CFE4930C856F9@wtl-exchp-2.sandvine.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
x-originating-ip: []
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: multipart/alternative; boundary="_000_C43C255C7106314F8D13D03FA20CFE4930C856F9wtlexchp2sandvi_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/seoH6mRj7Zpx2KJXMqrMCsLVgPM>
Subject: [Dime] draft-bertz-dime-rfc4006bis - adding a procedure for zero grants
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jun 2016 19:37:40 -0000

Hello all,

In section 5.6.2 and 5.6.3 (redirect and restrict actions) a process is described for graceful degradation on the first interrogation when the subscriber has no funds:

"However, the

   user's account might be empty when this first interrogation is

   performed.  In this case, the subscriber can be offered a chance to

   replenish the account and continue the service.  The credit-control

   client receives a Credit-Control-Answer or service specific

   authorization answer with the Final-Unit-Indication and Validity-Time

   AVPs but no Granted-Service-Unit.  It immediately starts the graceful

   service termination without sending any message to the server.  An

   example of this case is illustrated in Appendix A."

The issue is, that this may also happen in consequent interrogations as well. For example:

- when the reported U-S-U of another service exceeds the G-S-U

- When direct debiting depleted the account

In this case, currently, the only option is to reply with DIAMETER_CREDIT_LIMIT_REACHED for the service, which does not allow for graceful service termination (e.g. no VT, action etc.).

Note that in 3GPP TS 32.299, between releases 11.3 and 11.4, the termination action procedure (section 6.5.3 there) was corrected to allow for zero G-S-U as an indication that the termination process should start immediately, without further interrogation.

Without this clarification, the common interpretation of a zero G-S-U was to exhaust the grant once traffic is seen, and send a final report.

In accordance to that, would recommend adopting that concept and add the following text to the end of section 5.6.1 in RFC4006:

"When zero quota has been granted by the credit-control server, the termination action SHOULD be enforced at the reception of the CCA message. Final Credit-Control-Request message SHOULD NOT be sent to the credit-control server in this case."

In sections 5.6.2 and 5.6.3, the following text should be added:

"The credit-control server MAY grant zero quota to credit-control client, as

   specified in the previous section for the TERMINATE action."

Appreciate your feedback,