Re: [Dime] [dime] #36: OC-Validity-Duration AVP

"TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> Mon, 10 February 2014 09:46 UTC

Return-Path: <jean-jacques.trottin@alcatel-lucent.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 086DB1A07CC for <dime@ietfa.amsl.com>; Mon, 10 Feb 2014 01:46:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 as4nx7CfwuHS for <dime@ietfa.amsl.com>; Mon, 10 Feb 2014 01:46:09 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFA41A07D3 for <dime@ietf.org>; Mon, 10 Feb 2014 01:46:07 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1A9k3r1008963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Feb 2014 03:46:04 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1A9k2sU002978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 10:46:02 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 10 Feb 2014 10:46:02 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com>
To: Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] [dime] #36: OC-Validity-Duration AVP
Thread-Index: AQHPIyiVRUleRbeSh0iImOK3F7m+mZqoSuqAgAAqeQCAANvNAIAABVqAgAABgQCAAC0EgIAACU8AgAShATCAAACAgIAAERww
Date: Mon, 10 Feb 2014 09:46:01 +0000
Message-ID: <E194C2E18676714DACA9C3A2516265D202663B5C@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <075.376f1b94eeb48f20f90d9724b0e70c0e@trac.tools.ietf.org> <52F3ABA5.30504@usdonovans.com> <6764_1391710024_52F3CF48_6764_4871_1_6B7134B31289DC4FAF731D844122B36E48EEEE@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <087A34937E64E74E848732CFF8354B9209772061@ESESSMB101.ericsson.se> <21997_1391758373_52F48C25_21997_132_1_c9aldckjsu8oeuya3nuk8i3w.1391758370310@email.android.com> <087A34937E64E74E848732CFF8354B92097720CF@ESESSMB101.ericsson.se> <18811_1391768364_52F4B32C_18811_19518_1_6B7134B31289DC4FAF731D844122B36E49093A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <41CF16CB-0761-4037-8426-168546CFF792@gmail.com> <E194C2E18676714DACA9C3A2516265D202663B14@FR712WXCHMBA11.zeu.alcatel-lucent.com> <087A34937E64E74E848732CFF8354B92097726DC@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B92097726DC@ESESSMB101.ericsson.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP
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 09:46:13 -0000

Hi MCruz

I have not yet thought to some wording enhancement, I wanted first to check is we have the same understanding.

I have noted in the proposal:
"The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32 and indicates in seconds the validity time of the overload report"
So I would prefer to use "validity duration", as the OC-Validity-Duration AVP indicates a duration, not a time. But elsewhere, what is important is the update of the validity time  when a new sequence number. 
Best regards

JJacques  


-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoyé : lundi 10 février 2014 10:36
À : dime@ietf.org
Objet : Re: [Dime] [dime] #36: OC-Validity-Duration AVP

Hello Jean-Jacques, et all,

I share your interpretation.
But, do you find this is still misleading in proposed text?

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: lunes, 10 de febrero de 2014 9:59
To: dime@ietf.org
Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP

Hi all

I agree to enhance the wording so by starting  from the new Lionel's wording.

My comment is that we have  to clearly distinguish the "validity duration" given  by the OC-Validity-Duration AVP (eg 10 s) from the "validity time" (absolute value) at the end of which  the received OLR is no more applicable.
- If the reacting node receives a new sequence number at T1 and a validity duration of 10s, this will determine a validity time eg of T1+ 10s where the received OLR is applicable.
- If later at T2, it receives another OLR with the Same sequence number,  the validity time remains unchanged at  T1+10s (as stated in Lionel's proposal), this allows to ignore the OLRs with the same sequence number.
- If at T3, the reacting node receives another OLR with a new  sequence number and with the same value, 10 s, (or a new value, eg 15s)  for validity duration,  the validity time becomes  T3+10s (or T3+15s). So we can have situations where the sequence number is changed but the other content of OC-OLR AVP (reduction%, validity duration) itself has not changed: the effect is only to shift the validity time in the reacting node.
Do you share  all this understanding? 

So in the description, to be careful between validity duration and validity time that  may confuse.

Best regards

JJacques 


-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Envoyé : vendredi 7 février 2014 11:53 À : lionel.morand@orange.com Cc : dime@ietf.org Objet : Re: [Dime] [dime] #36: OC-Validity-Duration AVP


OK by me.

- JOuni

On Feb 7, 2014, at 12:19 PM, <lionel.morand@orange.com> wrote:

> Hi Maria Cruz,
> 
> I'm fine with the proposed clarification.
> My point is that some parts belong to the handling of the OLR itself and some other to the definition of the Validity duration.
> 
> Here is a proposal for clarification. Let me know if it covers your concern.
> 
> Regards,
> 
> Lionel
> 
> *******************
> 
> 4.3. OC-OLR AVP
> 
> [skip]
> 
>   The Sequence-Number AVP indicates the "freshness" of the OC-OLR AVP.
>   It is possible to replay the same OC-OLR AVP multiple times between
>   the overload control endpoints, however, when the OC-OLR AVP content
>   changes or sending endpoint otherwise wants the receiving endpoint to
>   update its overload control information, then the OC-Sequence-Number
>   AVP MUST contain a new greater value than the previously received.
>   The receiver SHOULD discard an OC-OLR AVP with a sequence number that
>   is less than previously received one.
> 
> [New]
> 
>   The OC-Validity-Duration AVP indicates the validity time of the overload
>   report associated with a specific sequence number, measured after reception
>   of the OC-OLR AVP. The validity time MUST NOT be updated after reception 
>   of subsequent OC-OLR AVPs with the same sequence number. The default value
>   for the OC-Validity-Duration AVP value is 5 (i.e., 5 seconds).  When the 
>   OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default value
>   applies.
> 
> [Skip]
> 
> 4.5. OC-Validity-Duration AVP
> 
> OLD:
>   The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
>   and describes the number of seconds the "new and fresh" OC-OLR AVP
>   and its content is valid since the reception of the new OC-OLR AVP.
>   The default value for the OC-Validity-Duration AVP value is 5 (i.e.,
>   5 seconds).  When the OC-Validity-Duration AVP is not present in the
>   OC-OLR AVP, the default value applies.  Validity duration values 0
>   (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used.
>   Invalid validity duration values are treated as if the OC-Validity-
>   Duration AVP were not present.
> 
> 
> NEW:
>   The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
>   and indicates in seconds the validity time of the overload report.
>   The number of seconds is measured after reception of the first 
>   OC-OLR AVP with a given value of OC-Sequence-Number AVP. 
>   The default value for the OC-Validity-Duration AVP is 5 (i.e.,
>   5 seconds).  When the OC-Validity-Duration AVP is not present in the
>   OC-OLR AVP, the default value applies. OC-Validity-Duration AVP values 0
>   (i.e., 0 second) and above 86400 (i.e., 24 hours) MUST NOT be used.
>   When invalid values are used, the default value for the OC-Validity-Duration
>   AVP applies.
> 
> 
> 
> 
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz 
> Bartolome Envoyé : vendredi 7 février 2014 08:38 À : dime@ietf.org 
> Objet : Re: [Dime] [dime] #36: OC-Validity-Duration AVP
> 
> Hello Lionel, all,
> 
> I would like to clarify what  "new and fresh", or even only "new" OC-OLR AVP mean in the text.
> It should be understood that it does not refer to the new (latest) received AVP, but just the one that contains (potentially) new values, what only happens for a new Sequence Number. In that line is the proposed text I provided.
> 
> Best regards
> /MCruz
> 
> -----Original Message-----
> From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
> Sent: viernes, 07 de febrero de 2014 8:33
> To: dime@ietf.org; Maria Cruz Bartolome
> Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP
> 
> Hi,
> 
> My point is just to say that we should make the difference between the definition and the use of the AVP.
> 
> And about the clarification, I would say that it is rather about how to populate the OC-OLR AVP or when a new sequence number should be used.
> 
> Regards,
> 
> Lionel
> 
> Envoyé depuis mon Sony Xperia SP d'Orange
> 
> Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> a écrit :
> 
> 
> Thanks Lionel,
> The comment equally applies in order to clarify when the Validity-Duration should include a new value.
> 
> Now:
>   The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
>   and describes the number of seconds the "new and fresh" OC-OLR AVP
>   and its content is valid since the reception of the new OC-OLR AVP.
> 
> Proposal:
>    The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
>    and describes the number of seconds the OC-OLR AVP and its content is
>    valid in relation to the reception of the first OC-OLR AVP with a
>    specific sequence number. For a given sequence number, the
>    OC-Validity-Duration shall always carry the same value.
> 
> 
> Best regards
> /MCruz
> 
> 
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of 
> lionel.morand@orange.com
> Sent: jueves, 06 de febrero de 2014 19:07
> To: Steve Donovan; dime@ietf.org
> Subject: Re: [Dime] [dime] #36: OC-Validity-Duration AVP
> 
> Hi Maria Cruz,
> 
> Hi Maria Cruz, Steve,
> 
> Be careful! The reference you are using seems to be odd.
> 
> The current text in the draft says:
> 
> 4.5. OC-Validity-Duration AVP
> 
> 
>   The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
>   and describes the number of seconds the "new and fresh" OC-OLR AVP
>   and its content is valid since the reception of the new OC-OLR AVP.
>   The default value for the OC-Validity-Duration AVP value is 5 (i.e.,
>   5 seconds).  When the OC-Validity-Duration AVP is not present in the
>   OC-OLR AVP, the default value applies.  Validity duration values 0
>   (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used.
>   Invalid validity duration values are treated as if the OC-Validity-
>   Duration AVP were not present.
> 
>   A timeout of the overload report has specific concerns that need to
>   be taken into account by the endpoint acting on the earlier received
>   overload report(s).  Section 4.7 discusses the impacts of timeout in
>   the scope of the traffic abatement algorithms.
> 
>   As a general guidance for implementations it is RECOMMENDED never to
>   let any overload report to timeout.  Following to this rule, an
>   overload endpoint should explicitly signal the end of overload
>   condition and not rely on the expiration of the validity time of the
>   overload report in the reacting node.  This leaves no need for the
>   reacting node to reason or guess the overload condition of the
>   reporting node.
> 
> I think that the definition of the OC-Validity-Duration AVP should remain independent of the notion of Sequence-Number.
> The sequence number does not change the value of the OC-Validity-Duration AVP. It indicates that the OLR has to be updated or not. And if it is, a new duration will be there (either implicit or explicit with the OC-Validity-Duration AVP).
> 
> So if something needs to be clarified (I haven't checked), it should be in the handling of the OLR.
> 
> Regards,
> 
> Lionel
> 
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan 
> Envoyé : jeudi 6 février 2014 16:35 À : dime@ietf.org Objet : Re:
> [Dime] [dime] #36: OC-Validity-Duration AVP
> 
> This change looks pretty straight forward to me.  I'll add it to the -02 version of the draft unless I hear objections soon.
> 
> Steve
> On 2/6/14 4:44 AM, dime issue tracker wrote:
> #36: OC-Validity-Duration AVP
> 
> In draft-ietf-dime-ovli-01 chapter 4.5, the statement that describes when  the OC-Validity-Duration AVP needs to be updated is ambiguous.
> 
> Now:
>    The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
>    and describes the number of seconds the OC-OLR AVP and its content is
>    valid since the reception of the new OC-OLR AVP (as indicated by the
>    OC-Sequence-Number AVP).
> 
> Proposal:
>    The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32
>    and describes the number of seconds the OC-OLR AVP and its content is
>    valid in relation to the reception of the first OC-OLR AVP with a
>    specific sequence number. For a given sequence number, the
>    OC-Validity-Duration shall always carry the same value.
> 
> 
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> 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
> _______________________________________________
> 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
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> 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

_______________________________________________
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