From wwwrun@rfc-editor.org Mon Dec 3 15:34:32 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0946521F8921 for ; Mon, 3 Dec 2012 15:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.01 X-Spam-Level: X-Spam-Status: No, score=-102.01 tagged_above=-999 required=5 tests=[AWL=0.590, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qHV5598LbuP for ; Mon, 3 Dec 2012 15:34:31 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id AA1D321F88C2 for ; Mon, 3 Dec 2012 15:34:31 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 7162172E039; Mon, 3 Dec 2012 15:26:22 -0800 (PST) To: glenzorn@gmail.com, sunseawq@huawei.com, violeta.cakulev@alcatel-lucent.com, rbonica@juniper.net, bclaise@cisco.com, jouni.nospam@gmail.com, lionel.morand@orange.com From: RFC Errata System Message-Id: <20121203232622.7162172E039@rfc-editor.org> Date: Mon, 3 Dec 2012 15:26:22 -0800 (PST) X-Mailman-Approved-At: Tue, 04 Dec 2012 00:22:46 -0800 Cc: dime@ietf.org, dr.nimool@yahoo.com, rfc-editor@rfc-editor.org Subject: [Dime] [Technical Errata Reported] RFC6734 (3424) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 23:34:32 -0000 The following errata report has been submitted for RFC6734, "Diameter Attribute-Value Pairs for Cryptographic Key Transport". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6734&eid=3424 -------------------------------------- Type: Technical Reported by: haji Section: how Original Text ------------- good Corrected Text -------------- bad Notes ----- hi Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6734 (draft-ietf-dime-local-keytran-14) -------------------------------------- Title : Diameter Attribute-Value Pairs for Cryptographic Key Transport Publication Date : October 2012 Author(s) : G. Zorn, Q. Wu, V. Cakulev Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG From ben@nostrum.com Tue Dec 4 13:41:12 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16CC321F8BBF for ; Tue, 4 Dec 2012 13:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Dyuy4P7jvZu for ; Tue, 4 Dec 2012 13:41:11 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 16F3521F8BBE for ; Tue, 4 Dec 2012 13:41:11 -0800 (PST) Received: from [10.0.1.14] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qB4Lf1bP015442 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Dec 2012 15:41:01 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: Date: Tue, 4 Dec 2012 15:41:01 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0C2E333F-B55B-4AC0-AF2F-CF95459D1860@nostrum.com> References: <5E7FEE8E-F6E8-4470-8823-E97382C73661@gmail.com> To: jouni korhonen , Eric McMurry , ERIC C NOEL X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: dime@ietf.org Subject: Re: [Dime] diameter overload control requirements review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2012 21:41:12 -0000 Hi, Sorry for the late response--I just got back from holiday. I've removed = sections that I don't think need further comment: On Nov 27, 2012, at 5:32 AM, jouni korhonen = wrote: > Eric, >=20 > See responses inline. >=20 > On Nov 27, 2012, at 3:17 AM, Eric McMurry wrote: >>>=20 [...] >>> o Explain IPX and provide appropriate references so that the reader >>> can get the context. >>=20 >> Is that level of detail necessary to get the use case across? = Perhaps you have some text you would like to include here? >=20 > I would only say something along the lines: >=20 > IPX (IP eXchange) [IR.34] is an Inter-Operator IP Backbone that = provides > roaming interconnection network between mobile operators and service > providers. The IPX is also used to transport Diameter signaling = between > operators [IR.88]. >=20 > Feel free to modify & shorten. >=20 Are we assuming that the IPX is operating at the Diameter layer, rather = than just providing IP transport? I know there may be instances of both, = but we should be explicit what we are considering in the draft. [...] >>> Section 7. Solution Requirements >>>=20 >>> o Req 2: I would also add here that the solution MUST NOT have = assumptions >>> on how some applications are _implemented_ today compared how they = are >>> specified. >>=20 >> sounds reasonable. Are you thinking about relays here? I think it is = still relevant question wether a pure relay is an element that will ever = be used. >=20 > Actually I was not thinking about relays. Just in general. It is so > easy to draw conclusions with the few implementations one is familiar > with. >=20 I think I must be missing something here. I don't see how we can avoid = assuming that implementations actually implement the specs in general. I = can see calling out specific exceptions where there may be known = problems. So I think I would suggest stating the opposite: Something to the effect = of "We assume implementations fully comply with RFC 6733 except where = otherwise noted." [...] >>> o Req18: How do you prevent other from benefiting? Say, the others = do the >>> work and the ones that do not still get the benefit network not = being >>> overloaded in general.. and they do not need to move a limb. >>=20 >> this one is tricky. It comes straight from the SIP overload control = requirements (RFC 5390) so perhaps someone from that group can better = answer this (Janet, Eric?). I believe that the goal is not to prevent = benefit to elements that do not support the mechanism. Rather, it is to = require the mechanism attempt to treat those elements fairly with = respect to the elements that do support the mechanism. >>=20 >> One hopes that having some elements in a network that do support an = overload control mechanism will benefit all of the network. >=20 > Right. Maybe someone who contributed to SIP overload can shift their > ideas & reasoning on this requirement into this document? I'm not sure I see the problem with the existing language--it's pretty = clear that non-supporting nodes should not benefit _more_ than = supporting ones. Maybe we should say "MUST NOT _unfairly_ benefit"? >=20 >>> o Req28: The lack of e2e security makes this requirement hard to = meet.=20 >>> Also, would this mean we need a way to prove the authenticity of the >>> provided overload information? What would be the cost of that? >>=20 >> perhaps someone should work on e2e security ;-) >>=20 >> I agree this would be difficult for e2e overload signaling. It's = important though because the potential harm from attacks goes up = substantially with an overload control mechanism in place. A single = malicious message could deny large amounts of service. >=20 > Maybe we just need to point out the lack of e2e security and its = implications > regarding this requirement? That's like one sentence or so. Also, keep in mind the requirement is to not make things worse (i.e. no = _new_ issues.). This is not the same as a requirement to have no issues = at all. This does seem to have implications on the e2e vs hbh question. I think = we can authenticate information hbh, since we should have a protected = transport between peers. >=20 >>> Section 9. Security Considerations >>>=20 >>> o Quite a few of these vulnerabilities boil down to the fact that we >>> cannot prove the ownership & authenticity of the provided overload >>> control information. I would state that there.. >>=20 >> okay, I will add some text to that effect in the summary. >=20 It's also worth mentioning the differing impacts on the hbh vs e2e = approaches.=20 Thanks! Ben.= From laurent.thiebaut@alcatel-lucent.com Wed Dec 5 00:20:59 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685E221F8C8D for ; Wed, 5 Dec 2012 00:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhkrDwbkj9-b for ; Wed, 5 Dec 2012 00:20:58 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB6021F8C02 for ; Wed, 5 Dec 2012 00:20:57 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qB58J4k5007212 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 5 Dec 2012 09:20:44 +0100 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 5 Dec 2012 09:20:39 +0100 From: "THIEBAUT, LAURENT (LAURENT)" To: Ben Campbell , jouni korhonen , Eric McMurry , ERIC C NOEL Date: Wed, 5 Dec 2012 09:18:27 +0100 Thread-Topic: [Dime] diameter overload control requirements review Thread-Index: Ac3SaBegEb4tzrwNT5+clbDb51ktygAWFK/A Message-ID: <170E8FCC2134BD42B539B47798ABF8F026C0BE3948@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> References: <5E7FEE8E-F6E8-4470-8823-E97382C73661@gmail.com> <0C2E333F-B55B-4AC0-AF2F-CF95459D1860@nostrum.com> In-Reply-To: <0C2E333F-B55B-4AC0-AF2F-CF95459D1860@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_170E8FCC2134BD42B539B47798ABF8F026C0BE3948FRMRSSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "dime@ietf.org" Subject: Re: [Dime] diameter overload control requirements review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 08:20:59 -0000 --_000_170E8FCC2134BD42B539B47798ABF8F026C0BE3948FRMRSSXCHMBSA_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all about > IPX (IP eXchange) [IR.34] is an Inter-Operator IP Backbone that provide= s > roaming interconnection network between mobile operators and service > providers. The IPX is also used to transport Diameter signaling between > operators [IR.88]. Are we assuming that the IPX is operating at the Diameter layer, rather tha= n just providing IP transport? I know there may be instances of both, but w= e should be explicit what we are considering in the draft. LTH : What about following text IPX (IP eXchange) [IR.34] is an Inter-Operator IP Backbone that provides ro= aming interconnection network between mobile operators and service provider= s. The IPX *may also be* used to transport *and relay/proxy* Diameter signa= ling between operators [IR.88]. Best regards Laurent ALCATEL-LUCENT -----Message d'origine----- De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Ben= Campbell Envoy=E9 : mardi 4 d=E9cembre 2012 22:41 =C0 : jouni korhonen; Eric McMurry; ERIC C NOEL Cc : dime@ietf.org Objet : Re: [Dime] diameter overload control requirements review Hi, Sorry for the late response--I just got back from holiday. I've removed sec= tions that I don't think need further comment: On Nov 27, 2012, at 5:32 AM, jouni korhonen wrote: > Eric, > > See responses inline. > > On Nov 27, 2012, at 3:17 AM, Eric McMurry wrote: >>> [...] >>> o Explain IPX and provide appropriate references so that the reader >>> can get the context. >> >> Is that level of detail necessary to get the use case across? Perhaps y= ou have some text you would like to include here? > > I would only say something along the lines: > > IPX (IP eXchange) [IR.34] is an Inter-Operator IP Backbone that provide= s > roaming interconnection network between mobile operators and service > providers. The IPX is also used to transport Diameter signaling between > operators [IR.88]. > > Feel free to modify & shorten. > Are we assuming that the IPX is operating at the Diameter layer, rather tha= n just providing IP transport? I know there may be instances of both, but w= e should be explicit what we are considering in the draft. [...] >>> Section 7. Solution Requirements >>> >>> o Req 2: I would also add here that the solution MUST NOT have assumpti= ons >>> on how some applications are _implemented_ today compared how they are >>> specified. >> >> sounds reasonable. Are you thinking about relays here? I think it is st= ill relevant question wether a pure relay is an element that will ever be u= sed. > > Actually I was not thinking about relays. Just in general. It is so > easy to draw conclusions with the few implementations one is familiar > with. > I think I must be missing something here. I don't see how we can avoid assu= ming that implementations actually implement the specs in general. I can se= e calling out specific exceptions where there may be known problems. So I think I would suggest stating the opposite: Something to the effect of= "We assume implementations fully comply with RFC 6733 except where otherwi= se noted." [...] >>> o Req18: How do you prevent other from benefiting? Say, the others do t= he >>> work and the ones that do not still get the benefit network not being >>> overloaded in general.. and they do not need to move a limb. >> >> this one is tricky. It comes straight from the SIP overload control req= uirements (RFC 5390) so perhaps someone from that group can better answer t= his (Janet, Eric?). I believe that the goal is not to prevent benefit to e= lements that do not support the mechanism. Rather, it is to require the me= chanism attempt to treat those elements fairly with respect to the elements= that do support the mechanism. >> >> One hopes that having some elements in a network that do support an over= load control mechanism will benefit all of the network. > > Right. Maybe someone who contributed to SIP overload can shift their > ideas & reasoning on this requirement into this document? I'm not sure I see the problem with the existing language--it's pretty clea= r that non-supporting nodes should not benefit _more_ than supporting ones.= Maybe we should say "MUST NOT _unfairly_ benefit"? > >>> o Req28: The lack of e2e security makes this requirement hard to meet. >>> Also, would this mean we need a way to prove the authenticity of the >>> provided overload information? What would be the cost of that? >> >> perhaps someone should work on e2e security ;-) >> >> I agree this would be difficult for e2e overload signaling. It's import= ant though because the potential harm from attacks goes up substantially wi= th an overload control mechanism in place. A single malicious message coul= d deny large amounts of service. > > Maybe we just need to point out the lack of e2e security and its implicat= ions > regarding this requirement? That's like one sentence or so. Also, keep in mind the requirement is to not make things worse (i.e. no _ne= w_ issues.). This is not the same as a requirement to have no issues at all= . This does seem to have implications on the e2e vs hbh question. I think we = can authenticate information hbh, since we should have a protected transpor= t between peers. > >>> Section 9. Security Considerations >>> >>> o Quite a few of these vulnerabilities boil down to the fact that we >>> cannot prove the ownership & authenticity of the provided overload >>> control information. I would state that there.. >> >> okay, I will add some text to that effect in the summary. > It's also worth mentioning the differing impacts on the hbh vs e2e approach= es. Thanks! Ben. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_170E8FCC2134BD42B539B47798ABF8F026C0BE3948FRMRSSXCHMBSA_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

 

Hello all

about

>=A0=A0 IPX (IP eXchange) [IR.34] is an Inter= -Operator IP Backbone that provides

>=A0=A0 roaming interconnection network betwe= en mobile operators and service

>=A0=A0 providers. The IPX is also used to tr= ansport Diameter signaling between

>=A0=A0 operators [IR.88].<= /font>

Are we assuming that the IPX is ope= rating at the Diameter layer, rather than just providing IP transport? I know ther= e may be instances of both, but we should be explicit what we are considering= in the draft.

LTH : What about following tex= t

IPX (IP = eXchange) [IR.34] is an Inter-Operator IP Backbone that provides roaming interconnect= ion network between mobile operators and service providers. The IPX *may also be* used to transport *and relay/proxy* Diameter signaling between operators [IR.88].

 

 

Best regards

Laurent

ALCATEL-LUCENT

 

-----Message d'origine-----
De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part d= e Ben Campbell
Envoy=E9 : mardi 4 d=E9cembre 2012 22:41
=C0 : jouni korhonen; Eric McMurry; ERIC C NOEL
Cc : dime@ietf.org
Objet : Re: [Dime] diameter overload control requirements review

 

Hi,

 

Sorry for the late response--I just got back fro= m holiday. I've removed sections that I don't think need further comment:

 

On Nov 27, 2012, at 5:32 AM, jouni korhonen <= jouni.nospam@gmail.com> wrote:

 

> Eric,

>

> See responses inline.

>

> On Nov 27, 2012, at 3:17 AM, Eric McMurry w= rote:

>>>

 

[...]

 

>>> o Explain IPX and provide appropria= te references so that the reader

>>> can get the context.

>>

>> Is that level of detail necessary to ge= t the use case across?=A0 Perhaps you have some text you would like to include he= re?

>

> I would only say something along the lines:=

>

>=A0=A0 IPX (IP eXchange) [IR.34] is an Inter= -Operator IP Backbone that provides

> =A0=A0roaming interconnection network betwe= en mobile operators and service

>=A0=A0 providers. The IPX is also used to tr= ansport Diameter signaling between

>=A0=A0 operators [IR.88].<= /font>

>

> Feel free to modify & shorten.

>

 

Are we assuming that the IPX is operating at the Diameter layer, rather than just providing IP transport? I know there may b= e instances of both, but we should be explicit what we are considering in the draft.

 

 

[...]

 

 

>>> Section 7. Solution Requirements

>>>

>>> o Req 2: I would also add here that= the solution MUST NOT have assumptions

>>> on how some applications are _implemented_ today compared how they are

>>> specified.=

>>

>> sounds reasonable.=A0 Are you thinking = about relays here? I think it is still relevant question wether a pure relay is a= n element that will ever be used.

>

> Actually I was not thinking about relays. J= ust in general. It is so

> easy to draw conclusions with the few implementations one is familiar

> with.

>

 

I think I must be missing something here. I don'= t see how we can avoid assuming that implementations actually implement the specs= in general. I can see calling out specific exceptions where there may be known problems.

 

So I think I would suggest stating the opposite: Something to the effect of "We assume implementations fully comply wit= h RFC 6733 except where otherwise noted."

 

[...]

 

 

>>> o Req18: How do you prevent other f= rom benefiting? Say, the others do the

>>> work and the ones that do not still= get the benefit network not being

>>> overloaded in general.. and they do= not need to move a limb.

>>

>> this one is tricky.=A0 It comes straigh= t from the SIP overload control requirements (RFC 5390) so perhaps someone from th= at group can better answer this (Janet, Eric?).=A0 I believe that the goal is = not to prevent benefit to elements that do not support the mechanism.=A0 Rather, i= t is to require the mechanism attempt to treat those elements fairly with respec= t to the elements that do support the mechanism.

>>

>> One hopes that having some elements in = a network that do support an overload control mechanism will benefit all of t= he network.

>

> Right. Maybe someone who contributed to SIP overload can shift their

> ideas & reasoning on this requirement i= nto this document?

 

I'm not sure I see the problem with the existing language--it's pretty clear that non-supporting nodes should not benefit _m= ore_ than supporting ones.=A0 Maybe we should say "MUST NOT _unfairly_ benefit"?

>

 

 

>>> o Req28: The lack of e2e security m= akes this requirement hard to meet.

>>> Also, would this mean we need a way= to prove the authenticity of the

>>> provided overload information? What= would be the cost of that?

>>

>> perhaps someone should work on e2e secu= rity ;-)

>>

>> I agree this would be difficult for e2e overload signaling.=A0 It's important though because the potential harm fro= m attacks goes up substantially with an overload control mechanism in place.= =A0 A single malicious message could deny large amounts of service.

>

> Maybe we just need to point out the lack of= e2e security and its implications

> regarding this requirement? That's like one sentence or so.

 

Also, keep in mind the requirement is to not mak= e things worse (i.e. no _new_ issues.). This is not the same as a requirement= to have no issues at all.

 

This does seem to have implications on the e2e v= s hbh question. I think we can authenticate information hbh, since we should have= a protected transport between peers.

 

>

>>> Section 9. Security Considerations<= o:p>

>>>

>>> o Quite a few of these vulnerabilit= ies boil down to the fact that we

>>> cannot prove the ownership & authenticity of the provided overload

>>> control information. I would state = that there..

>>

>> okay, I will add some text to that effe= ct in the summary.

>

 

It's also worth mentioning the differing impacts= on the hbh vs e2e approaches.

 

Thanks!

 

Ben.

_______________________________________________<= o:p>

DiME mailing list

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime<= /o:p>

--_000_170E8FCC2134BD42B539B47798ABF8F026C0BE3948FRMRSSXCHMBSA_-- From ben@nostrum.com Wed Dec 5 09:23:45 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9377B21F8CA0 for ; Wed, 5 Dec 2012 09:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZkUg2QxzlcD for ; Wed, 5 Dec 2012 09:23:44 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7835521F8C14 for ; Wed, 5 Dec 2012 09:23:44 -0800 (PST) Received: from [10.12.11.37] ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qB5HNH21049977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Dec 2012 11:23:17 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <170E8FCC2134BD42B539B47798ABF8F026C0BE3948@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> Date: Wed, 5 Dec 2012 11:23:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E7FEE8E-F6E8-4470-8823-E97382C73661@gmail.com> <0C2E333F-B55B-4AC0-AF2F-CF95459D1860@nostrum.com> <170E8FCC2134BD42B539B47798ABF8F026C0BE3948@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> To: "THIEBAUT, LAURENT (LAURENT)" X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" , ERIC C NOEL Subject: Re: [Dime] diameter overload control requirements review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 17:23:45 -0000 On Dec 5, 2012, at 2:18 AM, "THIEBAUT, LAURENT (LAURENT)" = wrote: > =20 > =20 > Hello all > about > > IPX (IP eXchange) [IR.34] is an Inter-Operator IP Backbone that = provides > > roaming interconnection network between mobile operators and = service > > providers. The IPX is also used to transport Diameter signaling = between > > operators [IR.88]. > Are we assuming that the IPX is operating at the Diameter layer, = rather than just providing IP transport? I know there may be instances = of both, but we should be explicit what we are considering in the draft. > LTH : What about following text > IPX (IP eXchange) [IR.34] is an Inter-Operator IP Backbone that = provides roaming interconnection network between mobile operators and = service providers. The IPX *may also be*used to transport *and = relay/proxy* Diameter signaling between operators [IR.88]. I think the language is close to right, although we might want to be = more explicit in what we mean by "used to transport...Diameter". I = _think_ we are talking about transporting IP traffic, where Diameter = might be one of the application layer protocols carried (possibly among = others). More importantly, does the working group wish to consider both use = cases? They are fairly different, as in the "transport" case, the = carriers have have a direct peering relationship at the _Diameter_ = layer, regardless of the route taken by IP packets. In the "relay/proxy" = case, the carriers have a (trusted or otherwise) third party between = them.=20 > =20 > =20 > Best regards > Laurent > ALCATEL-LUCENT > =20 > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Ben Campbell > Envoy=E9 : mardi 4 d=E9cembre 2012 22:41 > =C0 : jouni korhonen; Eric McMurry; ERIC C NOEL > Cc : dime@ietf.org > Objet : Re: [Dime] diameter overload control requirements review > =20 > Hi, > =20 > Sorry for the late response--I just got back from holiday. I've = removed sections that I don't think need further comment: > =20 > On Nov 27, 2012, at 5:32 AM, jouni korhonen = wrote: > =20 > > Eric, > > > > See responses inline. > > > > On Nov 27, 2012, at 3:17 AM, Eric McMurry wrote: > >>> > =20 > [...] > =20 > >>> o Explain IPX and provide appropriate references so that the = reader > >>> can get the context. > >> > >> Is that level of detail necessary to get the use case across? = Perhaps you have some text you would like to include here? > > > > I would only say something along the lines: > > > > IPX (IP eXchange) [IR.34] is an Inter-Operator IP Backbone that = provides > > roaming interconnection network between mobile operators and = service > > providers. The IPX is also used to transport Diameter signaling = between > > operators [IR.88]. > > > > Feel free to modify & shorten. > > > =20 > Are we assuming that the IPX is operating at the Diameter layer, = rather than just providing IP transport? I know there may be instances = of both, but we should be explicit what we are considering in the draft. > =20 > =20 > [...] > =20 > =20 > >>> Section 7. Solution Requirements > >>> > >>> o Req 2: I would also add here that the solution MUST NOT have = assumptions > >>> on how some applications are _implemented_ today compared how they = are > >>> specified. > >> > >> sounds reasonable. Are you thinking about relays here? I think it = is still relevant question wether a pure relay is an element that will = ever be used. > > > > Actually I was not thinking about relays. Just in general. It is so > > easy to draw conclusions with the few implementations one is = familiar > > with. > > > =20 > I think I must be missing something here. I don't see how we can avoid = assuming that implementations actually implement the specs in general. I = can see calling out specific exceptions where there may be known = problems. > =20 > So I think I would suggest stating the opposite: Something to the = effect of "We assume implementations fully comply with RFC 6733 except = where otherwise noted." > =20 > [...] > =20 > =20 > >>> o Req18: How do you prevent other from benefiting? Say, the others = do the > >>> work and the ones that do not still get the benefit network not = being > >>> overloaded in general.. and they do not need to move a limb. > >> > >> this one is tricky. It comes straight from the SIP overload = control requirements (RFC 5390) so perhaps someone from that group can = better answer this (Janet, Eric?). I believe that the goal is not to = prevent benefit to elements that do not support the mechanism. Rather, = it is to require the mechanism attempt to treat those elements fairly = with respect to the elements that do support the mechanism. > >> > >> One hopes that having some elements in a network that do support an = overload control mechanism will benefit all of the network. > > > > Right. Maybe someone who contributed to SIP overload can shift their > > ideas & reasoning on this requirement into this document? > =20 > I'm not sure I see the problem with the existing language--it's pretty = clear that non-supporting nodes should not benefit _more_ than = supporting ones. Maybe we should say "MUST NOT _unfairly_ benefit"? > > > =20 > =20 > >>> o Req28: The lack of e2e security makes this requirement hard to = meet. > >>> Also, would this mean we need a way to prove the authenticity of = the > >>> provided overload information? What would be the cost of that? > >> > >> perhaps someone should work on e2e security ;-) > >> > >> I agree this would be difficult for e2e overload signaling. It's = important though because the potential harm from attacks goes up = substantially with an overload control mechanism in place. A single = malicious message could deny large amounts of service. > > > > Maybe we just need to point out the lack of e2e security and its = implications > > regarding this requirement? That's like one sentence or so. > =20 > Also, keep in mind the requirement is to not make things worse (i.e. = no _new_ issues.). This is not the same as a requirement to have no = issues at all. > =20 > This does seem to have implications on the e2e vs hbh question. I = think we can authenticate information hbh, since we should have a = protected transport between peers. > =20 > > > >>> Section 9. Security Considerations > >>> > >>> o Quite a few of these vulnerabilities boil down to the fact that = we > >>> cannot prove the ownership & authenticity of the provided overload > >>> control information. I would state that there.. > >> > >> okay, I will add some text to that effect in the summary. > > > =20 > It's also worth mentioning the differing impacts on the hbh vs e2e = approaches. > =20 > Thanks! > =20 > Ben. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Wed Dec 5 12:06:41 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2D521F8539 for ; Wed, 5 Dec 2012 12:06:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ0VPdaHGFyA for ; Wed, 5 Dec 2012 12:06:40 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id F2D1121F86AA for ; Wed, 5 Dec 2012 12:06:39 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so4799111lah.31 for ; Wed, 05 Dec 2012 12:06:38 -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:x-mailer; bh=8N3zhGIA6CY80KbK7++p7XlHzgGnSP72OubkW2OvcSg=; b=DDtsyfsdZPXxjB7/1yrR+xbIrrMNBtRJlM6yY34pJt7wJ8rMH61eYEEbwJjAczTFlQ l6juactI4XYLl6BvvrWy1I58JQVGtWAsmr5okAE6D7za9aiHJ0OXrdE+Qihiv3SLFH58 pzUDblCWlEmCuY2RsEpYJ/a8NsQ2mgspW2HP6+hR/uE2xg8ghFN6a2/RK8uyDAiC10H9 vpIBvV5UYF1/bsC4b3MIrUM28QtPeOdD7ZHY6VNJNjXkfVKLmZaUdRTJWvRA3L7GdtIZ tiExZBA/txbyaWzu84GUELHKkX1rnc/n+SAG8TJxi+/iIawPUoxMG8YwbZIo8MD+PTXk UJnQ== Received: by 10.112.23.136 with SMTP id m8mr7912379lbf.16.1354737998741; Wed, 05 Dec 2012 12:06:38 -0800 (PST) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPS id ee5sm2623087lbb.14.2012.12.05.12.06.35 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Dec 2012 12:06:37 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: Date: Wed, 5 Dec 2012 22:06:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9C971FC2-2E7C-4608-8BDF-4289D316C3BC@gmail.com> References: <5E7FEE8E-F6E8-4470-8823-E97382C73661@gmail.com> <0C2E333F-B55B-4AC0-AF2F-CF95459D1860@nostrum.com> <170E8FCC2134BD42B539B47798ABF8F026C0BE3948@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> To: Ben Campbell X-Mailer: Apple Mail (2.1499) Cc: dime@ietf.org, ERIC C NOEL Subject: Re: [Dime] diameter overload control requirements review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 20:06:41 -0000 Hi Ben, I think WG (and I) should be more interested in the Diameter layer. Lets = not get too much into detail what IPX really is, since it has a tendency = to cause headache. - Jouni On Dec 5, 2012, at 7:23 PM, Ben Campbell wrote: >=20 > On Dec 5, 2012, at 2:18 AM, "THIEBAUT, LAURENT (LAURENT)" = wrote: >=20 >>=20 >>=20 >> Hello all >> about >>> IPX (IP eXchange) [IR.34] is an Inter-Operator IP Backbone that = provides >>> roaming interconnection network between mobile operators and service >>> providers. The IPX is also used to transport Diameter signaling = between >>> operators [IR.88]. >> Are we assuming that the IPX is operating at the Diameter layer, = rather than just providing IP transport? I know there may be instances = of both, but we should be explicit what we are considering in the draft. >> LTH : What about following text >> IPX (IP eXchange) [IR.34] is an Inter-Operator IP Backbone that = provides roaming interconnection network between mobile operators and = service providers. The IPX *may also be*used to transport *and = relay/proxy* Diameter signaling between operators [IR.88]. >=20 > I think the language is close to right, although we might want to be = more explicit in what we mean by "used to transport...Diameter". I = _think_ we are talking about transporting IP traffic, where Diameter = might be one of the application layer protocols carried (possibly among = others). >=20 > More importantly, does the working group wish to consider both use = cases? They are fairly different, as in the "transport" case, the = carriers have have a direct peering relationship at the _Diameter_ = layer, regardless of the route taken by IP packets. In the "relay/proxy" = case, the carriers have a (trusted or otherwise) third party between = them.=20 >=20 >>=20 >>=20 >> Best regards >> Laurent >> ALCATEL-LUCENT >>=20 >> -----Message d'origine----- >> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Ben Campbell >> Envoy=E9 : mardi 4 d=E9cembre 2012 22:41 >> =C0 : jouni korhonen; Eric McMurry; ERIC C NOEL >> Cc : dime@ietf.org >> Objet : Re: [Dime] diameter overload control requirements review >>=20 >> Hi, >>=20 >> Sorry for the late response--I just got back from holiday. I've = removed sections that I don't think need further comment: >>=20 >> On Nov 27, 2012, at 5:32 AM, jouni korhonen = wrote: >>=20 >>> Eric, >>>=20 >>> See responses inline. >>>=20 >>> On Nov 27, 2012, at 3:17 AM, Eric McMurry wrote: >>>>>=20 >>=20 >> [...] >>=20 >>>>> o Explain IPX and provide appropriate references so that the = reader >>>>> can get the context. >>>>=20 >>>> Is that level of detail necessary to get the use case across? = Perhaps you have some text you would like to include here? >>>=20 >>> I would only say something along the lines: >>>=20 >>> IPX (IP eXchange) [IR.34] is an Inter-Operator IP Backbone that = provides >>> roaming interconnection network between mobile operators and service >>> providers. The IPX is also used to transport Diameter signaling = between >>> operators [IR.88]. >>>=20 >>> Feel free to modify & shorten. >>>=20 >>=20 >> Are we assuming that the IPX is operating at the Diameter layer, = rather than just providing IP transport? I know there may be instances = of both, but we should be explicit what we are considering in the draft. >>=20 >>=20 >> [...] >>=20 >>=20 >>>>> Section 7. Solution Requirements >>>>>=20 >>>>> o Req 2: I would also add here that the solution MUST NOT have = assumptions >>>>> on how some applications are _implemented_ today compared how they = are >>>>> specified. >>>>=20 >>>> sounds reasonable. Are you thinking about relays here? I think it = is still relevant question wether a pure relay is an element that will = ever be used. >>>=20 >>> Actually I was not thinking about relays. Just in general. It is so >>> easy to draw conclusions with the few implementations one is = familiar >>> with. >>>=20 >>=20 >> I think I must be missing something here. I don't see how we can = avoid assuming that implementations actually implement the specs in = general. I can see calling out specific exceptions where there may be = known problems. >>=20 >> So I think I would suggest stating the opposite: Something to the = effect of "We assume implementations fully comply with RFC 6733 except = where otherwise noted." >>=20 >> [...] >>=20 >>=20 >>>>> o Req18: How do you prevent other from benefiting? Say, the others = do the >>>>> work and the ones that do not still get the benefit network not = being >>>>> overloaded in general.. and they do not need to move a limb. >>>>=20 >>>> this one is tricky. It comes straight from the SIP overload = control requirements (RFC 5390) so perhaps someone from that group can = better answer this (Janet, Eric?). I believe that the goal is not to = prevent benefit to elements that do not support the mechanism. Rather, = it is to require the mechanism attempt to treat those elements fairly = with respect to the elements that do support the mechanism. >>>>=20 >>>> One hopes that having some elements in a network that do support an = overload control mechanism will benefit all of the network. >>>=20 >>> Right. Maybe someone who contributed to SIP overload can shift their >>> ideas & reasoning on this requirement into this document? >>=20 >> I'm not sure I see the problem with the existing language--it's = pretty clear that non-supporting nodes should not benefit _more_ than = supporting ones. Maybe we should say "MUST NOT _unfairly_ benefit"? >>>=20 >>=20 >>=20 >>>>> o Req28: The lack of e2e security makes this requirement hard to = meet. >>>>> Also, would this mean we need a way to prove the authenticity of = the >>>>> provided overload information? What would be the cost of that? >>>>=20 >>>> perhaps someone should work on e2e security ;-) >>>>=20 >>>> I agree this would be difficult for e2e overload signaling. It's = important though because the potential harm from attacks goes up = substantially with an overload control mechanism in place. A single = malicious message could deny large amounts of service. >>>=20 >>> Maybe we just need to point out the lack of e2e security and its = implications >>> regarding this requirement? That's like one sentence or so. >>=20 >> Also, keep in mind the requirement is to not make things worse (i.e. = no _new_ issues.). This is not the same as a requirement to have no = issues at all. >>=20 >> This does seem to have implications on the e2e vs hbh question. I = think we can authenticate information hbh, since we should have a = protected transport between peers. >>=20 >>>=20 >>>>> Section 9. Security Considerations >>>>>=20 >>>>> o Quite a few of these vulnerabilities boil down to the fact that = we >>>>> cannot prove the ownership & authenticity of the provided overload >>>>> control information. I would state that there.. >>>>=20 >>>> okay, I will add some text to that effect in the summary. >>>=20 >>=20 >> It's also worth mentioning the differing impacts on the hbh vs e2e = approaches. >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From ben@nostrum.com Wed Dec 5 12:23:51 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F1521F8B9A for ; Wed, 5 Dec 2012 12:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRMp6V-4r1lv for ; Wed, 5 Dec 2012 12:23:50 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1EB21F89E4 for ; Wed, 5 Dec 2012 12:23:49 -0800 (PST) Received: from [10.12.11.37] ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qB5KNWim069630 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Dec 2012 14:23:32 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <9C971FC2-2E7C-4608-8BDF-4289D316C3BC@gmail.com> Date: Wed, 5 Dec 2012 14:23:31 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <49770946-98B6-432D-AC17-6263DCDA3D41@nostrum.com> References: <5E7FEE8E-F6E8-4470-8823-E97382C73661@gmail.com> <0C2E333F-B55B-4AC0-AF2F-CF95459D1860@nostrum.com> <170E8FCC2134BD42B539B47798ABF8F026C0BE3948@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <9C971FC2-2E7C-4608-8BDF-4289D316C3BC@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: dime@ietf.org, ERIC C NOEL Subject: Re: [Dime] diameter overload control requirements review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 20:23:51 -0000 On Dec 5, 2012, at 2:06 PM, Jouni Korhonen = wrote: >=20 > Hi Ben, >=20 > I think WG (and I) should be more interested in the Diameter layer. = Lets not get too much into detail what IPX really is, since it has a = tendency to cause headache. >=20 Hi Jouni, While we might not care too much about the IPX details, we do need to = document the use case we are considering, since it drives some of the = requirements. I infer from your comment that, for the sake of = requirements, we should assume the presence of a third-party agent for = the interconnect case? If so, we can probably model that as a = third-party agent without worrying about the rest of IPX. OTOH, the transport-only model really doesn't add requirements beyond = the base, other than perhaps a security consideration comment about = stronger need to use a protected transport since one cannot assume a = trusted network. But people should be doing that anyway ;-) > - Jouni >=20 > On Dec 5, 2012, at 7:23 PM, Ben Campbell wrote: >=20 >>=20 >> On Dec 5, 2012, at 2:18 AM, "THIEBAUT, LAURENT (LAURENT)" = wrote: >>=20 >>>=20 >>>=20 >>> Hello all >>> about >>>> IPX (IP eXchange) [IR.34] is an Inter-Operator IP Backbone that = provides >>>> roaming interconnection network between mobile operators and = service >>>> providers. The IPX is also used to transport Diameter signaling = between >>>> operators [IR.88]. >>> Are we assuming that the IPX is operating at the Diameter layer, = rather than just providing IP transport? I know there may be instances = of both, but we should be explicit what we are considering in the draft. >>> LTH : What about following text >>> IPX (IP eXchange) [IR.34] is an Inter-Operator IP Backbone that = provides roaming interconnection network between mobile operators and = service providers. The IPX *may also be*used to transport *and = relay/proxy* Diameter signaling between operators [IR.88]. >>=20 >> I think the language is close to right, although we might want to be = more explicit in what we mean by "used to transport...Diameter". I = _think_ we are talking about transporting IP traffic, where Diameter = might be one of the application layer protocols carried (possibly among = others). >>=20 >> More importantly, does the working group wish to consider both use = cases? They are fairly different, as in the "transport" case, the = carriers have have a direct peering relationship at the _Diameter_ = layer, regardless of the route taken by IP packets. In the "relay/proxy" = case, the carriers have a (trusted or otherwise) third party between = them.=20 >>=20 >>>=20 >>>=20 >>> Best regards >>> Laurent >>> ALCATEL-LUCENT >>>=20 >>> -----Message d'origine----- >>> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Ben Campbell >>> Envoy=E9 : mardi 4 d=E9cembre 2012 22:41 >>> =C0 : jouni korhonen; Eric McMurry; ERIC C NOEL >>> Cc : dime@ietf.org >>> Objet : Re: [Dime] diameter overload control requirements review >>>=20 >>> Hi, >>>=20 >>> Sorry for the late response--I just got back from holiday. I've = removed sections that I don't think need further comment: >>>=20 >>> On Nov 27, 2012, at 5:32 AM, jouni korhonen = wrote: >>>=20 >>>> Eric, >>>>=20 >>>> See responses inline. >>>>=20 >>>> On Nov 27, 2012, at 3:17 AM, Eric McMurry wrote: >>>>>>=20 >>>=20 >>> [...] >>>=20 >>>>>> o Explain IPX and provide appropriate references so that the = reader >>>>>> can get the context. >>>>>=20 >>>>> Is that level of detail necessary to get the use case across? = Perhaps you have some text you would like to include here? >>>>=20 >>>> I would only say something along the lines: >>>>=20 >>>> IPX (IP eXchange) [IR.34] is an Inter-Operator IP Backbone that = provides >>>> roaming interconnection network between mobile operators and = service >>>> providers. The IPX is also used to transport Diameter signaling = between >>>> operators [IR.88]. >>>>=20 >>>> Feel free to modify & shorten. >>>>=20 >>>=20 >>> Are we assuming that the IPX is operating at the Diameter layer, = rather than just providing IP transport? I know there may be instances = of both, but we should be explicit what we are considering in the draft. >>>=20 >>>=20 >>> [...] >>>=20 >>>=20 >>>>>> Section 7. Solution Requirements >>>>>>=20 >>>>>> o Req 2: I would also add here that the solution MUST NOT have = assumptions >>>>>> on how some applications are _implemented_ today compared how = they are >>>>>> specified. >>>>>=20 >>>>> sounds reasonable. Are you thinking about relays here? I think it = is still relevant question wether a pure relay is an element that will = ever be used. >>>>=20 >>>> Actually I was not thinking about relays. Just in general. It is so >>>> easy to draw conclusions with the few implementations one is = familiar >>>> with. >>>>=20 >>>=20 >>> I think I must be missing something here. I don't see how we can = avoid assuming that implementations actually implement the specs in = general. I can see calling out specific exceptions where there may be = known problems. >>>=20 >>> So I think I would suggest stating the opposite: Something to the = effect of "We assume implementations fully comply with RFC 6733 except = where otherwise noted." >>>=20 >>> [...] >>>=20 >>>=20 >>>>>> o Req18: How do you prevent other from benefiting? Say, the = others do the >>>>>> work and the ones that do not still get the benefit network not = being >>>>>> overloaded in general.. and they do not need to move a limb. >>>>>=20 >>>>> this one is tricky. It comes straight from the SIP overload = control requirements (RFC 5390) so perhaps someone from that group can = better answer this (Janet, Eric?). I believe that the goal is not to = prevent benefit to elements that do not support the mechanism. Rather, = it is to require the mechanism attempt to treat those elements fairly = with respect to the elements that do support the mechanism. >>>>>=20 >>>>> One hopes that having some elements in a network that do support = an overload control mechanism will benefit all of the network. >>>>=20 >>>> Right. Maybe someone who contributed to SIP overload can shift = their >>>> ideas & reasoning on this requirement into this document? >>>=20 >>> I'm not sure I see the problem with the existing language--it's = pretty clear that non-supporting nodes should not benefit _more_ than = supporting ones. Maybe we should say "MUST NOT _unfairly_ benefit"? >>>>=20 >>>=20 >>>=20 >>>>>> o Req28: The lack of e2e security makes this requirement hard to = meet. >>>>>> Also, would this mean we need a way to prove the authenticity of = the >>>>>> provided overload information? What would be the cost of that? >>>>>=20 >>>>> perhaps someone should work on e2e security ;-) >>>>>=20 >>>>> I agree this would be difficult for e2e overload signaling. It's = important though because the potential harm from attacks goes up = substantially with an overload control mechanism in place. A single = malicious message could deny large amounts of service. >>>>=20 >>>> Maybe we just need to point out the lack of e2e security and its = implications >>>> regarding this requirement? That's like one sentence or so. >>>=20 >>> Also, keep in mind the requirement is to not make things worse (i.e. = no _new_ issues.). This is not the same as a requirement to have no = issues at all. >>>=20 >>> This does seem to have implications on the e2e vs hbh question. I = think we can authenticate information hbh, since we should have a = protected transport between peers. >>>=20 >>>>=20 >>>>>> Section 9. Security Considerations >>>>>>=20 >>>>>> o Quite a few of these vulnerabilities boil down to the fact that = we >>>>>> cannot prove the ownership & authenticity of the provided = overload >>>>>> control information. I would state that there.. >>>>>=20 >>>>> okay, I will add some text to that effect in the summary. >>>>=20 >>>=20 >>> It's also worth mentioning the differing impacts on the hbh vs e2e = approaches. >>>=20 >>> Thanks! >>>=20 >>> Ben. >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >=20 From jouni.nospam@gmail.com Wed Dec 5 23:28:09 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB6421F8D68 for ; Wed, 5 Dec 2012 23:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTRh0VmXjpB9 for ; Wed, 5 Dec 2012 23:28:08 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7BE21F8D57 for ; Wed, 5 Dec 2012 23:28:08 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so5305834lbk.31 for ; Wed, 05 Dec 2012 23:28:07 -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:x-mailer; bh=0bny76UaMYpIvrOUpAT/4MRWpbbIfnzmo6EB2i24zxc=; b=HRhyqiUUiuGCXd0L2B2YOI7PLYGi+nFPjKLklt6Qnc4XeS/kUaP+qcbMF9eOBDgBVB YqDuyFUbPBKtG2q/+yaBzLIbHp5maCDYk/7BpycPV/hBZzDqDBGjScJ+CVUI2SIxKi/S K242ssuKPr/X7Gcmst5V3fXTJje1nKD6ppbNuJhJCK+XFPPJybMy3cZog8PL7830Y2Hv yNduPmpks5x6j1zYyyzMFWy3ZslGqt+5RbP1A/Ab96iiToqcnp1Uh6uQLjOt0BeNVW9S /Cj60ikxS0RsjEo3O0gboBNXINLi9saLg44H/EvGi/GdzjqdvYqAIw8m+5MiWuFORUeP SwbA== Received: by 10.152.46.161 with SMTP id w1mr616460lam.27.1354778887131; Wed, 05 Dec 2012 23:28:07 -0800 (PST) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPS id d5sm3077033lbk.10.2012.12.05.23.28.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Dec 2012 23:28:04 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: <49770946-98B6-432D-AC17-6263DCDA3D41@nostrum.com> Date: Thu, 6 Dec 2012 09:28:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E7FEE8E-F6E8-4470-8823-E97382C73661@gmail.com> <0C2E333F-B55B-4AC0-AF2F-CF95459D1860@nostrum.com> <170E8FCC2134BD42B539B47798ABF8F026C0BE3948@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <9C971FC2-2E7C-4608-8BDF-4289D316C3BC@gmail.com> <49770946-98B6-432D-AC17-6263DCDA3D41@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1499) Cc: dime@ietf.org, ERIC C NOEL Subject: Re: [Dime] diameter overload control requirements review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 07:28:09 -0000 Hi, On Dec 5, 2012, at 10:23 PM, Ben Campbell wrote: > On Dec 5, 2012, at 2:06 PM, Jouni Korhonen = wrote: >=20 >>=20 >> Hi Ben, >>=20 >> I think WG (and I) should be more interested in the Diameter layer. = Lets not get too much into detail what IPX really is, since it has a = tendency to cause headache. >>=20 >=20 > Hi Jouni, >=20 > While we might not care too much about the IPX details, we do need to = document the use case we are considering, since it drives some of the = requirements. I infer from your comment that, for the Sure. An there intermediating proxies & relays that are run by 3rd = parties come into picture. > sake of requirements, we should assume the presence of a third-party = agent for the interconnect case? If so, we can probably model that as a = third-party agent without worrying about the rest of IPX. More or less. However, as the IPX is the current interconnection network = of choice for many mobile operators, we should have references in place = and the text that such network is used for interconnection. I would not = go deeper than this myself. > OTOH, the transport-only model really doesn't add requirements beyond = the base, other than perhaps a security consideration comment about = stronger need to use a protected transport since one cannot assume a = trusted network. But people should be doing that anyway ;-) Righty. - Jouni >=20 >=20 >> - Jouni >>=20 >> On Dec 5, 2012, at 7:23 PM, Ben Campbell wrote: >>=20 >>>=20 >>> On Dec 5, 2012, at 2:18 AM, "THIEBAUT, LAURENT (LAURENT)" = wrote: >>>=20 >>>>=20 >>>>=20 >>>> Hello all >>>> about >>>>> IPX (IP eXchange) [IR.34] is an Inter-Operator IP Backbone that = provides >>>>> roaming interconnection network between mobile operators and = service >>>>> providers. The IPX is also used to transport Diameter signaling = between >>>>> operators [IR.88]. >>>> Are we assuming that the IPX is operating at the Diameter layer, = rather than just providing IP transport? I know there may be instances = of both, but we should be explicit what we are considering in the draft. >>>> LTH : What about following text >>>> IPX (IP eXchange) [IR.34] is an Inter-Operator IP Backbone that = provides roaming interconnection network between mobile operators and = service providers. The IPX *may also be*used to transport *and = relay/proxy* Diameter signaling between operators [IR.88]. >>>=20 >>> I think the language is close to right, although we might want to be = more explicit in what we mean by "used to transport...Diameter". I = _think_ we are talking about transporting IP traffic, where Diameter = might be one of the application layer protocols carried (possibly among = others). >>>=20 >>> More importantly, does the working group wish to consider both use = cases? They are fairly different, as in the "transport" case, the = carriers have have a direct peering relationship at the _Diameter_ = layer, regardless of the route taken by IP packets. In the "relay/proxy" = case, the carriers have a (trusted or otherwise) third party between = them.=20 >>>=20 >>>>=20 >>>>=20 >>>> Best regards >>>> Laurent >>>> ALCATEL-LUCENT >>>>=20 >>>> -----Message d'origine----- >>>> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la = part de Ben Campbell >>>> Envoy=E9 : mardi 4 d=E9cembre 2012 22:41 >>>> =C0 : jouni korhonen; Eric McMurry; ERIC C NOEL >>>> Cc : dime@ietf.org >>>> Objet : Re: [Dime] diameter overload control requirements review >>>>=20 >>>> Hi, >>>>=20 >>>> Sorry for the late response--I just got back from holiday. I've = removed sections that I don't think need further comment: >>>>=20 >>>> On Nov 27, 2012, at 5:32 AM, jouni korhonen = wrote: >>>>=20 >>>>> Eric, >>>>>=20 >>>>> See responses inline. >>>>>=20 >>>>> On Nov 27, 2012, at 3:17 AM, Eric McMurry wrote: >>>>>>>=20 >>>>=20 >>>> [...] >>>>=20 >>>>>>> o Explain IPX and provide appropriate references so that the = reader >>>>>>> can get the context. >>>>>>=20 >>>>>> Is that level of detail necessary to get the use case across? = Perhaps you have some text you would like to include here? >>>>>=20 >>>>> I would only say something along the lines: >>>>>=20 >>>>> IPX (IP eXchange) [IR.34] is an Inter-Operator IP Backbone that = provides >>>>> roaming interconnection network between mobile operators and = service >>>>> providers. The IPX is also used to transport Diameter signaling = between >>>>> operators [IR.88]. >>>>>=20 >>>>> Feel free to modify & shorten. >>>>>=20 >>>>=20 >>>> Are we assuming that the IPX is operating at the Diameter layer, = rather than just providing IP transport? I know there may be instances = of both, but we should be explicit what we are considering in the draft. >>>>=20 >>>>=20 >>>> [...] >>>>=20 >>>>=20 >>>>>>> Section 7. Solution Requirements >>>>>>>=20 >>>>>>> o Req 2: I would also add here that the solution MUST NOT have = assumptions >>>>>>> on how some applications are _implemented_ today compared how = they are >>>>>>> specified. >>>>>>=20 >>>>>> sounds reasonable. Are you thinking about relays here? I think = it is still relevant question wether a pure relay is an element that = will ever be used. >>>>>=20 >>>>> Actually I was not thinking about relays. Just in general. It is = so >>>>> easy to draw conclusions with the few implementations one is = familiar >>>>> with. >>>>>=20 >>>>=20 >>>> I think I must be missing something here. I don't see how we can = avoid assuming that implementations actually implement the specs in = general. I can see calling out specific exceptions where there may be = known problems. >>>>=20 >>>> So I think I would suggest stating the opposite: Something to the = effect of "We assume implementations fully comply with RFC 6733 except = where otherwise noted." >>>>=20 >>>> [...] >>>>=20 >>>>=20 >>>>>>> o Req18: How do you prevent other from benefiting? Say, the = others do the >>>>>>> work and the ones that do not still get the benefit network not = being >>>>>>> overloaded in general.. and they do not need to move a limb. >>>>>>=20 >>>>>> this one is tricky. It comes straight from the SIP overload = control requirements (RFC 5390) so perhaps someone from that group can = better answer this (Janet, Eric?). I believe that the goal is not to = prevent benefit to elements that do not support the mechanism. Rather, = it is to require the mechanism attempt to treat those elements fairly = with respect to the elements that do support the mechanism. >>>>>>=20 >>>>>> One hopes that having some elements in a network that do support = an overload control mechanism will benefit all of the network. >>>>>=20 >>>>> Right. Maybe someone who contributed to SIP overload can shift = their >>>>> ideas & reasoning on this requirement into this document? >>>>=20 >>>> I'm not sure I see the problem with the existing language--it's = pretty clear that non-supporting nodes should not benefit _more_ than = supporting ones. Maybe we should say "MUST NOT _unfairly_ benefit"? >>>>>=20 >>>>=20 >>>>=20 >>>>>>> o Req28: The lack of e2e security makes this requirement hard to = meet. >>>>>>> Also, would this mean we need a way to prove the authenticity of = the >>>>>>> provided overload information? What would be the cost of that? >>>>>>=20 >>>>>> perhaps someone should work on e2e security ;-) >>>>>>=20 >>>>>> I agree this would be difficult for e2e overload signaling. It's = important though because the potential harm from attacks goes up = substantially with an overload control mechanism in place. A single = malicious message could deny large amounts of service. >>>>>=20 >>>>> Maybe we just need to point out the lack of e2e security and its = implications >>>>> regarding this requirement? That's like one sentence or so. >>>>=20 >>>> Also, keep in mind the requirement is to not make things worse = (i.e. no _new_ issues.). This is not the same as a requirement to have = no issues at all. >>>>=20 >>>> This does seem to have implications on the e2e vs hbh question. I = think we can authenticate information hbh, since we should have a = protected transport between peers. >>>>=20 >>>>>=20 >>>>>>> Section 9. Security Considerations >>>>>>>=20 >>>>>>> o Quite a few of these vulnerabilities boil down to the fact = that we >>>>>>> cannot prove the ownership & authenticity of the provided = overload >>>>>>> control information. I would state that there.. >>>>>>=20 >>>>>> okay, I will add some text to that effect in the summary. >>>>>=20 >>>>=20 >>>> It's also worth mentioning the differing impacts on the hbh vs e2e = approaches. >>>>=20 >>>> Thanks! >>>>=20 >>>> Ben. >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>=20 >=20 From jean-jacques.trottin@alcatel-lucent.com Thu Dec 6 05:17:00 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04AD21F8759 for ; Thu, 6 Dec 2012 05:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZ+Df0oGTkQZ for ; Thu, 6 Dec 2012 05:16:58 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6E28721F8662 for ; Thu, 6 Dec 2012 05:16:58 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qB6DGuRP028871 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 6 Dec 2012 14:16:57 +0100 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 6 Dec 2012 14:16:45 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Date: Thu, 6 Dec 2012 14:16:44 +0100 Thread-Topic: Dime: Diameter Overload IETF requirements, review Thread-Index: Ac3Ts/BAQEyu8MTiRFuiZHheD1/f7Q== Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_C472E6A4C17FA14E90533C0369A4798B20EB463C6FFRMRSSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 13:17:00 -0000 --_000_C472E6A4C17FA14E90533C0369A4798B20EB463C6FFRMRSSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all In the objective of relying on IETF specifications to handle Diameter overl= oad for 3GPP applications, as Alcatel-Lucent, we did an analysis of the dra= ft-ietf-dime-overload-reqs-01. We consider the list of REQs described in the IETF draft as quite extensive= and all REQs relevant. We have the few additional comments to submit to th= e upcoming Dime review: * We suggest to put more emphasis in REQ1 on the fact this is both fo= r load (preventive) and overload (reactive). A possible writing: REQ 1: The overload mechanism MUST provide a communication method for Dia= meter nodes to exchange load and overload information. * About REQ 2 ("The overload mechanism MUST be useable with any exist= ing or future Diameter application. It MUST NOT require specification chan= ges for existing Diameter applications"), an existing application may evolv= e to support an overload mechanism, especially when the overload handling m= ay rely on certain application dependent behaviors (which would be within 3= GPP scope for applications defined by 3GPP). It also may have a consistency= issue with REQ13 "allowing for the possibility of increased feedback for i= nformation piggybacked" as the piggybacking mechanism may impact the applic= ation. May be a solution is to suppress this second part of the REQ2 (" It = MUST NOT require specification changes for existing Diameter applications")= or review the wording. * On REQ 26, we have the following reading we consider important: the= specifications of the diameter load/overload control can only give an over= all guidance. Actual and precise specification of the "which message types = might be desirable to send or process over others during times of overload"= should be left for each application to define (for " ... Diameter specifi= c considerations). If this reading of REQ 26 is shared, a possible rewordin= g could be: REQ 26: The generic specification for the overload mechanism SHOULD offer = overall guidance on which message types might be desirable to send or proce= ss over others during times of overload, based on Diameter-specific conside= rations. For example, it may be more beneficial to process messages for ex= isting sessions ahead of new sessions. A precise specification of the relat= ive priorities of message types in case of overload would anyhow be under t= he responsibility of each application. * We expressed the point that overload handling should take into acco= unt that some messages may have a high priority (eg when related to an emer= gency or a high priority user"). This handling would be application depen= dent and so entering the REQ 26 as an overall guidance but it could be ment= ioned in REQ 26 as an example with the possible wording " For example, it may be more beneficial to process messages for existing s= essions ahead of new sessions and to give priority to requests associated w= ith emergency sessions or with high priority users" * Last sentence of REQ 35 appears unclear, wording may be reviewed or= this sentence may be suppressed. . Best regards JJacques Trottin Alcatel-Lucent delegate to 3GPP CT4 --_000_C472E6A4C17FA14E90533C0369A4798B20EB463C6FFRMRSSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear all
&nb= sp;
 
In the objective of relying on IETF specifications to handle Diameter = overload for 3GPP applications, as Alcatel-Lucent, we did an analysis of th= e draft-ietf-dime-overload-reqs-01= .
 
We consider the list of REQs described in the IETF draft as quite exte= nsive and all REQs relevant. We have the few additional comments to submit = to the upcoming Dime review:
 
  • We suggest to put more emphasis in REQ1 on the fact this is = both for load (preventive) and overload (reactive). A possible writing:
    •
REQ 1:   The overload mechanism MUST provide a= communication method for Diameter nodes to exchange load and overload information.
 
  • About REQ 2 (“The overload = mechanism MUST be useable with any existing or future Diameter application.=   It MUST NOT require specification changes for existing Diameter appl= ications”), an existing application may evolve to support an overload mechanism, especially when the overload handl= ing may rely on certain application dependent behaviors (which would be within 3GPP scope for applications defined by 3GPP). It also may have a consistency issue with REQ13 “allowing for the possibility of increased feedback for informat= ion piggybacked” as the piggybacking mechanism may impact the application. May be = a solution is to suppress thi= s second part of the REQ2 (“ It= MUST NOT require specification changes for existing Diameter applications”) or review the wording.
    • <= /ul>
     
    • On REQ 26, we have the following reading we consider important: the spe= cifications of the diameter load/overload control can only give an overall = guidance. Actual and precise specification of the = “which message types might be desirable to send or process over others during time= s of overload” should be left for each application to define (for “ …  Diameter specific considerations). If this reading of REQ 26 is shared, a possible rewording could be:
    REQ = 26:  The generic specification for the = overload mechanism SHOULD offer overall guid= ance on which message types might be desirable to send or process over others during times of overload, based on Diameter-specific considerations<= /font>.  For example, it may be more beneficial to process messages fo= r existing sessions ahead of new sessions. A precise specification of the relative priorities = of message types in case of overload would anyhow be under the responsibili= ty of each application.
     
    • We expressed the point that overload handling should take into account = that some messages may have a high priority (eg when related to an emergenc= y or a high priority user”).  This handling would  be appli= cation dependent and so entering the REQ 26 as an overall guidance but it could be mentioned in REQ 26 as an example with the= possible wording
      •
    “ For example, it may be more beneficial= to process messages for existing sessions ahead of new sessions and = to give p= riority to requests associated with emergency sessions or with high priority users”
     
    • Last sentence of REQ 35 appears unclear, wording may be reviewed or thi= s sentence may be suppressed.
      •
     
    .
    Best regards
     
    JJacques Trottin
    Alcatel-Lucent delegate to 3GPP CT4
    &nb= sp;
     
     
     --_000_C472E6A4C17FA14E90533C0369A4798B20EB463C6FFRMRSSXCHMBSA_-- From emcmurry@computer.org Thu Dec 6 06:05:34 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED4021F86EC for ; Thu, 6 Dec 2012 06:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.06 X-Spam-Level: X-Spam-Status: No, score=-2.06 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkOPgVLWQYy9 for ; Thu, 6 Dec 2012 06:05:33 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9695421F86BD for ; Thu, 6 Dec 2012 06:05:33 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1Tgc4y-000GjV-UG; Thu, 06 Dec 2012 14:05:33 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id C1ED1ABD593; Thu, 6 Dec 2012 08:05:30 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18zpOz51ud8FDecCW+EgZw1DjpZRM69SlE= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFgwKWEEXNgO; Thu, 6 Dec 2012 08:05:30 -0600 (CST) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 74557ABD57F; Thu, 6 Dec 2012 08:05:30 -0600 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_3B5729C0-7948-4593-A712-A6671DB08503" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric McMurry In-Reply-To: Date: Thu, 6 Dec 2012 08:05:29 -0600 Message-Id: <23E0ABAF-E856-44A9-8F6D-C88B8CAB2A57@computer.org> References: To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" X-Mailer: Apple Mail (2.1499) Cc: dime@ietf.org Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 14:05:35 -0000 --Apple-Mail=_3B5729C0-7948-4593-A712-A6671DB08503 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for the comments! responses inline. Eric On Dec 6, 2012, at 7:16 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: > Dear all > =20 > =20 > In the objective of relying on IETF specifications to handle Diameter = overload for 3GPP applications, as Alcatel-Lucent, we did an analysis of = thedraft-ietf-dime-overload-reqs-01. > =20 > We consider the list of REQs described in the IETF draft as quite = extensive and all REQs relevant. We have the few additional comments to = submit to the upcoming Dime review: > =20 > We suggest to put more emphasis in REQ1 on the fact this is both for = load (preventive) and overload (reactive). A possible writing: > REQ 1: The overload mechanism MUST provide a communication method = for Diameter nodes to exchange load andoverload information. > =20 sounds reasonable to me. > About REQ 2 (=93The overload mechanism MUST be useable with any = existing or future Diameter application. It MUST NOT require = specification changes for existing Diameter applications=94), an = existing application may evolve to support an overload mechanism, = especially when the overload handling may rely on certain application = dependent behaviors (which would be within 3GPP scope for applications = defined by 3GPP). It also may have a consistency issue with REQ13 = =93allowing for the possibility of increased feedback for information = piggybacked=94as the piggybacking mechanism may impact the application. = May be a solution is to suppress this second part of the REQ2 (=93 It = MUST NOT require specification changes for existing Diameter = applications=94) or review the wording. The intent of this was not to say that applications can not be changed = to make use of overload control, just that they won't be required to. I = think with either of the proposed mechanisms based on these = requirements, this would be met. They can be used without any = alteration to applications. That said, overload control will work = better with consideration for how each application can be impacted and = how it should respond. =20 The second part of REQ 13 is only commentary on the scaling properties = of existing messaging, but in general piggybacking can be done without = impacting applications. This requires a * [ AVP ] in the applications = messages though. Adam did a survey of all the applications he could = find when he was writing the proposed mechanism and did not find any = examples where this was not the case (and this is recommended by the = base protocol). > =20 > On REQ 26, we have the following reading we consider important: the = specifications of the diameter load/overload control can only give an = overall guidance. Actual and precise specification of the =93which = message types might be desirable to send or process over others during = times of overload=94 should be left for each application to define (for = =93 =85 Diameter specific considerations). If this reading of REQ 26 is = shared, apossible rewording could be: > REQ 26: The generic specification for the overload mechanism SHOULD = offer overall guidance on which message types might be desirable to send = or process over others during times of overload, based on = Diameter-specific considerations. For example, it may be more = beneficial to process messages for existing sessions ahead of new = sessions. A precise specification of the relative priorities of message = types in case of overload would anyhow be under the responsibility of = each application. I believe that was the point it was trying to get across. I think your = last sentence would add some clarity. > =20 > We expressed the point that overload handling should take into account = that some messages may have a high priority (eg when related to an = emergency or a high priority user=94). This handling would be = application dependent and so entering the REQ 26 as an overall guidance = but it could be mentioned in REQ 26 as an example with the possible = wording > =93 For example, it may be more beneficial to process messages for = existing sessions ahead of new sessions and to give priority to requests = associated with emergency sessions or with high priority users=94 I don't have any issue with that. What was there was intended as only = the simplest example. There are many ways to do this. Adding one more = example shouldn't hurt, but we probably don't want to go down the path = of listing possibilities here. > =20 > Last sentence of REQ 35 appears unclear, wording may be reviewed or = this sentence may be suppressed. We can probably strike that. What do you think, Ben? > =20 > . > Best regards > =20 > JJacques Trottin > Alcatel-Lucent delegate to 3GPP CT4 > =20 > =20 > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --Apple-Mail=_3B5729C0-7948-4593-A712-A6671DB08503 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 jean-jacques.trott= in@ALCATEL-LUCENT.COM> wrote:
    Dear all
     
     
    In = the objective of relying on IETF specifications to handle Diameter = overload for 3GPP applications, as Alcatel-Lucent, we did an analysis of = thedraft-ietf-dime-overload-reqs-01.
     
    We = consider the list of REQs described in the IETF draft as quite extensive = and all REQs relevant. We have the few additional comments to submit to = the upcoming Dime review:
     
    • We suggest to put more emphasis in REQ1 on = the fact this is both for load (preventive) and overload (reactive). = A pos= sible writing:
    REQ 1:   The overload mechanism MUST provide a = communication method for Diameter nodes to exchange load andoverload = information.
     

    sounds reasonable to me.
    • About REQ 2 (=93The overload mechanism = MUST be useable with any existing or future Diameter application.  = It MUST NOT require specification changes for existing Diameter = applications=94), an existing application may = evolve to support an overload mechanism, especially when the overload = handling may rely on certain application dependent behaviors (which would be = within 3GPP scope for applications = defined by 3GPP). It also may have a consistency issue with REQ13 =93allowing for the possibility of increased feedback for = information piggybacked=94as the piggybacking mechanism may = impact the application. May be a solution = is to suppress this = second part of the REQ2 (=93 It MUST NOT require = specification changes for existing Diameter applications=94) or review the = wording.

    The = intent of this was not to say that applications can not be changed to = make use of overload control, just that they won't be required to. =  I think with either of the proposed mechanisms based on these = requirements, this would be met.  They can be used without any = alteration to applications.  That said, overload control will work = better with consideration for how each application can be impacted and = how it should respond.  

    The second part = of REQ 13 is only commentary on the scaling properties of existing = messaging, but in general piggybacking can be done without impacting = applications.  This requires a * [ AVP ] in the applications = messages though.  Adam did a survey of all the applications he = could find when he was writing the proposed mechanism and did not find = any examples where this was not the case (and this is recommended by the = base protocol).

     
    • On REQ 26, we have the following reading we consider = important: the specifications of the diameter load/overload control can = only give an overall guidance. Actual and precise specification of the =93which message types might be desirable to send or = process over others during times of overload=94 should be left for = each application to define (for =93 =85  Diameter specific = considerations). If this reading of REQ 26 is shared, apossible rewording could = be:
    REQ 26:  The generic specification for = the overload mechanism SHOULD offer overall guidance on which = message types might be desirable to send or process over others during = times of overload, based on Diameter-specific = considerations.  For example, it may be more = beneficial to process messages for existing sessions ahead of new = sessions. A precise specification of the relative priorities of = message types in case of overload would anyhow be under the = responsibility of each = application.

    <= div>I believe that was the point it was trying to get across.  I = think your last sentence would add some = clarity.


     
    • We expressed the point that overload handling should = take into account that some messages may have a high priority (eg when = related to an emergency or a high priority user=94).  This handling = would  be application dependent and so entering the REQ 26 as an = overall guidance but it could be mentioned in REQ 26 as an example with = the possible wording
    =93 For = example, it may be more = beneficial to process messages for existing sessions ahead of new = sessions and to give priority to requests = associated with emergency sessions or with high priority = users=94
    I don't have any issue with that.  What was there was = intended as only the simplest example.  There are many ways to do = this.  Adding one more example shouldn't hurt, but we probably = don't want to go down the path of listing possibilities = here.

     
    • Last sentence of REQ 35 appears unclear, = wording may be reviewed or this sentence may be = suppressed.

    = We can probably strike that.  What do you think, = Ben?

     
    .
    Best = regards
     
    JJacques = Trottin
    Alcatel-Lucent delegate to 3GPP CT4
     
     
     
    _____________________________________= __________
    DiME mailing list
    DiME@ietf.org
    https://www.ietf.org/m= ailman/listinfo/dime

    = --Apple-Mail=_3B5729C0-7948-4593-A712-A6671DB08503-- From ben@nostrum.com Thu Dec 6 06:38:50 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEB921F86DC for ; Thu, 6 Dec 2012 06:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGjAumQsm76C for ; Thu, 6 Dec 2012 06:38:49 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9117F21F86CE for ; Thu, 6 Dec 2012 06:38:49 -0800 (PST) Received: from [10.0.1.14] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qB6Ecg66092091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Dec 2012 08:38:43 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <23E0ABAF-E856-44A9-8F6D-C88B8CAB2A57@computer.org> Date: Thu, 6 Dec 2012 08:38:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4E7C93CF-3471-402C-9F79-0165575A53C0@nostrum.com> References: <23E0ABAF-E856-44A9-8F6D-C88B8CAB2A57@computer.org> To: Eric McMurry X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: dime@ietf.org Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 14:38:50 -0000 On Dec 6, 2012, at 8:05 AM, Eric McMurry wrote: >>=20 >> =20 >> =95 Last sentence of REQ 35 appears unclear, wording may be = reviewed or this sentence may be suppressed. >=20 > We can probably strike that. What do you think, Ben? The point was to say that sharing data between non-adjacent nodes might = require a different mechanism than exchanging between adjacent nodes. = But, whether that is true or not, it's not necessary to say it here. I = concur with striking it. From laurent.thiebaut@alcatel-lucent.com Thu Dec 6 07:52:54 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02FB621F8682 for ; Thu, 6 Dec 2012 07:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.55 X-Spam-Level: X-Spam-Status: No, score=-7.55 tagged_above=-999 required=5 tests=[AWL=1.302, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, WEIRD_QUOTING=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWtscPeFSLkh for ; Thu, 6 Dec 2012 07:52:50 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4D621F8538 for ; Thu, 6 Dec 2012 07:52:44 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qB6FfAH1027223 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 Dec 2012 16:49:09 +0100 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 6 Dec 2012 16:48:02 +0100 From: "THIEBAUT, LAURENT (LAURENT)" To: Eric McMurry , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" Date: Thu, 6 Dec 2012 16:48:00 +0100 Thread-Topic: [Dime] Dime: Diameter Overload IETF requirements, review Thread-Index: Ac3TusuunSJZEqN9SqqEx3YmfVE7EwADHOXQ Message-ID: <170E8FCC2134BD42B539B47798ABF8F026C0C43982@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> References: <23E0ABAF-E856-44A9-8F6D-C88B8CAB2A57@computer.org> In-Reply-To: <23E0ABAF-E856-44A9-8F6D-C88B8CAB2A57@computer.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_170E8FCC2134BD42B539B47798ABF8F026C0C43982FRMRSSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 15:52:54 -0000 --_000_170E8FCC2134BD42B539B47798ABF8F026C0C43982FRMRSSXCHMBSA_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all About Req2, we understand that based on the usage of the *[ AVP ], there is= no need to update the ""ABNF"" of the protocol describing the various Diam= eter applications! Nevertheless the behaviour of the application, i.e. the= SW using that "unchanged protocol" will have to be changed anyhow to suppo= rt Diameter overload control. Can we reword Req2 into The overload mechanism MUST be useable with any existing or future Diameter= application. It MUST NOT require specification changes for existing Diame= ter applications *but is likely to require a change of the behaviour of an = entity supporting a Diameter application and the Diameter overload mechanis= m.* This "is likely" is NOT an IETF normative wording (MUST, SHOULD,...) as the= part of the sentence that is being added is more of an explanatory / clari= fication nature (I hope). Best regards Laurent ALCATEL-LUCENT ________________________________ De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Eri= c McMurry Envoy=E9 : jeudi 6 d=E9cembre 2012 15:05 =C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Cc : dime@ietf.org Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review Thanks for the comments! responses inline. Eric On Dec 6, 2012, at 7:16 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" > wrote: Dear all In the objective of relying on IETF specifications to handle Diameter overl= oad for 3GPP applications, as Alcatel-Lucent, we did an analysis of thedraf= t-ietf-dime-overload-reqs-01. We consider the list of REQs described in the IETF draft as quite extensive= and all REQs relevant. We have the few additional comments to submit to th= e upcoming Dime review: * We suggest to put more emphasis in REQ1 on the fact this is both for l= oad (preventive) and overload (reactive). A possible writing: REQ 1: The overload mechanism MUST provide a communication method for Dia= meter nodes to exchange load andoverload information. sounds reasonable to me. * About REQ 2 ("The overload mechanism MUST be useable with any existing= or future Diameter application. It MUST NOT require specification changes= for existing Diameter applications"), an existing application may evolve t= o support an overload mechanism, especially when the overload handling may = rely on certain application dependent behaviors (which would be within 3GPP= scope for applications defined by 3GPP). It also may have a consistency is= sue with REQ13 "allowing for the possibility of increased feedback for info= rmation piggybacked"as the piggybacking mechanism may impact the applicatio= n. May be a solution is to suppress this second part of the REQ2 (" It MUST= NOT require specification changes for existing Diameter applications") or = review the wording. The intent of this was not to say that applications can not be changed to m= ake use of overload control, just that they won't be required to. I think = with either of the proposed mechanisms based on these requirements, this wo= uld be met. They can be used without any alteration to applications. That= said, overload control will work better with consideration for how each ap= plication can be impacted and how it should respond. The second part of REQ 13 is only commentary on the scaling properties of e= xisting messaging, but in general piggybacking can be done without impactin= g applications. This requires a * [ AVP ] in the applications messages tho= ugh. Adam did a survey of all the applications he could find when he was w= riting the proposed mechanism and did not find any examples where this was = not the case (and this is recommended by the base protocol). * On REQ 26, we have the following reading we consider important: the sp= ecifications of the diameter load/overload control can only give an overall= guidance. Actual and precise specification of the "which message types mig= ht be desirable to send or process over others during times of overload" sh= ould be left for each application to define (for " ... Diameter specific c= onsiderations). If this reading of REQ 26 is shared, apossible rewording co= uld be: REQ 26: The generic specification for the overload mechanism SHOULD offer = overall guidance on which message types might be desirable to send or proce= ss over others during times of overload, based on Diameter-specific conside= rations. For example, it may be more beneficial to process messages for ex= isting sessions ahead of new sessions. A precise specification of the relat= ive priorities of message types in case of overload would anyhow be under t= he responsibility of each application. I believe that was the point it was trying to get across. I think your las= t sentence would add some clarity. * We expressed the point that overload handling should take into account= that some messages may have a high priority (eg when related to an emergen= cy or a high priority user"). This handling would be application dependen= t and so entering the REQ 26 as an overall guidance but it could be mention= ed in REQ 26 as an example with the possible wording " For example, it may be more beneficial to process messages for existing s= essions ahead of new sessions and to give priority to requests associated w= ith emergency sessions or with high priority users" I don't have any issue with that. What was there was intended as only the = simplest example. There are many ways to do this. Adding one more example= shouldn't hurt, but we probably don't want to go down the path of listing = possibilities here. * Last sentence of REQ 35 appears unclear, wording may be reviewed or th= is sentence may be suppressed. We can probably strike that. What do you think, Ben? . Best regards JJacques Trottin Alcatel-Lucent delegate to 3GPP CT4 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_170E8FCC2134BD42B539B47798ABF8F026C0C43982FRMRSSXCHMBSA_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

     

     

    Hello all

    About Req2, we understand that based on the usage of the *[ AVP= ], there is no need to update the ““ABNF”” of the prot= ocol describing the various Diameter applications!=A0 Nevertheless the behaviour of the application, i.e. the SW= using that “unchanged protocol” will have to be changed anyhow to sup= port Diameter overload control. Can we reword Req2 into

    The overload mechanism MUST be usea= ble with any existing or future Diameter application.  It MUST NOT require specification changes for existing Diameter applications *but is likely = to require a change of the behaviour of an entity supporting a Diameter application an= d the Diameter overload mechanism.*

     

    This “is likely” is NOT an IETF normative wording (= MUST, SHOULD,…) as the part of the sentence that is being added is more of an explanatory /= clarification nature (I hope).

    Best regards

    Laurent
    ALCATEL-LUCENT

    De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Eric McMurry
    Envoy=E9 : jeudi 6 d=E9= cembre 2012 15:05
    =C0 : TROTTIN, JEAN-JAC= QUES (JEAN-JACQUES)
    Cc : dime@ietf.org
    Objet : Re: [Dime] Dime= : Diameter Overload IETF requirements, review

     

    Thanks for the comments!

     

    responses inline.

     

    Eric

     

     

    On Dec 6, 2012, at 7:16 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trotti= n@ALCATEL-LUCENT.COM> wrote:



    Dear all=

    <= span style=3D'font-size:12.0pt;color:navy'> =

     

    In the objective of relying on IETF specifications to ha= ndle Diameter overload for 3GPP applications, as Alcatel-Lucent, we did an analy= sis of thedraft-ietf-dime-overload= -reqs-01.

     

    We consider the list of REQs described in the IETF draft= as quite extensive and all REQs relevant. We have the few additional comments = to submit to the upcoming Dime review:

     

    • We suggest to put more emphasis in REQ1 on the fac= t this is both for load (preventive) and overload (reactive). A possible writing:

    REQ 1:   The overload mechanism MUST provide a communication method for Diameter nodes t= o exchange load andoverload information.

     

     

    sounds reasonable to me.



    • About REQ 2 (“The overload mechani= sm MUST be useable with any existing or future Diameter application.  It MUS= T NOT require specification changes for existing Diameter applications&#= 8221;), an existing application may evolve to support an overload mechanism, especially when the overload handling may rely on certain application dependent behaviors (which would be within 3GPP scope for applications defin= ed by 3GPP). It also may have a consistency issue with REQ13 “allowing for the possibility of increased feedback for information piggybacked&= #8221;as the piggybacking mechanism may impact the application. May be <= /span>a solution is to suppress this secon= d part of the REQ2 <= span style=3D'font-size:10.0pt'>(“ It MUST NOT require specification = changes for existing Diameter applications”) or review the wording.

     

    The intent of this was not to say that applications can not be chan= ged to make use of overload control, just that they won't be required to.  = ;I think with either of the proposed mechanisms based on these requirements, t= his would be met.  They can be used without any alteration to applications= .  That said, overload control will work better with consideration for h= ow each application can be impacted and how it should respond.  

     

    The second part of REQ 13 is only commentary on the scaling propert= ies of existing messaging, but in general piggybacking can be done without impacting applications.  This requires a * [ AVP ] in the applications messages though.  Adam did a survey of all the applications he could f= ind when he was writing the proposed mechanism and did not find any examples wh= ere this was not the case (and this is recommended by the base protocol).<= /o:p>



     

    • On REQ 26, we have the following reading we consider important: the specifications of the diameter load/overload control can only give an overall guidance. Actual and precise specification of th= e “which message types m= ight be desirable to send or process over others during times of overload̶= 1; shou= ld be left for each application to define (for “ …  Diamet= er specific considerations). If this reading of RE= Q 26 is shared, apossible rewording could be:<= /o:p>

    REQ 26:  The=  generic specification for = the overload mechanism SHOULD offer overall guidance on which message types might be desirable to send or process over others during time= s of overload, = = based on Diameter-specific considerations.  For example, it may= be more beneficial to process messages for existing sessions ahead of new sessions. A precise specification of the relative priorities o= f message types in case of overload would anyhow be under the responsibility = of each application.

     

    I believe that was the point it was trying to get across.  I t= hink your last sentence would add some clarity.

     



     

    • We expressed the point that overload handli= ng should take into account that some messages may have a high priority (= eg when related to an emergency or a high priority user”).  Th= is handling would  be application dependent and so entering the REQ = 26 as an overall guidance but it could be mentioned in REQ 26 as an examp= le with the possible wording

    <= span style=3D'font-size:10.0pt;color:blue'>“ For example, it may be= more beneficial to process messages for existing sessions ahead of new sessions<= span class=3Dapple-converted-space> and to give priority to requests associ= ated with emergency sessions or with high priority users”

     

    I don't have any issue with that.  What was there was intended= as only the simplest example.  There are many ways to do this.  Addi= ng one more example shouldn't hurt, but we probably don't want to go down the = path of listing possibilities here.



     

    • Last sentence of REQ 35 appears unclear, wo= rding may be reviewed or this sentence may be suppressed.<= /font>

     

    We can probably strike that.  What do you think, Ben?



     

    .

    Best regards<= span style=3D'font-size:10.0pt;font-family:Arial'>

     

    JJacques Trottin

    Alcatel-Lucent delegate to 3GPP CT4

    <= span style=3D'font-size:12.0pt;color:navy'> =

     

     

    _______________________________________________
    DiME mailing list
    DiME@ietf.org
    https://www.ietf.org= /mailman/listinfo/dime

     

    --_000_170E8FCC2134BD42B539B47798ABF8F026C0C43982FRMRSSXCHMBSA_-- From ben@nostrum.com Thu Dec 6 08:03:40 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E799F21F8653 for ; Thu, 6 Dec 2012 08:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100, WEIRD_QUOTING=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCkCn-EADhsj for ; Thu, 6 Dec 2012 08:03:40 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E34E921F859D for ; Thu, 6 Dec 2012 08:03:39 -0800 (PST) Received: from [10.0.1.14] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qB6G2mqB001600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Dec 2012 10:02:48 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <170E8FCC2134BD42B539B47798ABF8F026C0C43982@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> Date: Thu, 6 Dec 2012 10:02:50 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> References: <23E0ABAF-E856-44A9-8F6D-C88B8CAB2A57@computer.org> <170E8FCC2134BD42B539B47798ABF8F026C0C43982@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> To: "THIEBAUT, LAURENT (LAURENT)" X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 16:03:41 -0000 On Dec 6, 2012, at 9:48 AM, "THIEBAUT, LAURENT (LAURENT)" = wrote: > =20 > =20 > Hello all > About Req2, we understand that based on the usage of the *[ AVP ], = there is no need to update the =93=93ABNF=94=94 of the protocol = describing the various Diameter applications! Nevertheless the = behaviour of the application, i.e. the SW using that =93unchanged = protocol=94 will have to be changed anyhow to support Diameter overload = control. Can we reword Req2 into > The overload mechanism MUST be useable with any existing or future = Diameter application. It MUST NOT require specification changes for = existing Diameter applications *but is likely to require a change of the = behaviour of an entity supporting a Diameter application and the = Diameter overload mechanism.* > =20 > This =93is likely=94 is NOT an IETF normative wording (MUST, SHOULD,=85)= as the part of the sentence that is being added is more of an = explanatory / clarification nature (I hope). I have mixed feelings about this, and I think it has to do with the = definition of "application". If we do this right, the _base_ Diameter = overload control behavior should come to any application, old or new, = for "free", assuming the definition of that application included the *[ = AVP ] construction. That's in the strict sense of what constitutes a = "Diameter Application". If the application would benefit from more = application specific behaviors, they can always add them. OTOH, the definition of an "interface" that uses one or more = "applications" is highly likely to change, if for no reason that to = require support of OC. I propose an indented paragraph with a couple of sentences to explain = this, rather than making it part of the same sentence as the normative = requirement. > Best regards > Laurent=20 > ALCATEL-LUCENT > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Eric McMurry > Envoy=E9 : jeudi 6 d=E9cembre 2012 15:05 > =C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES) > Cc : dime@ietf.org > Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review > =20 > Thanks for the comments! > =20 > responses inline. > =20 > Eric > =20 > =20 > On Dec 6, 2012, at 7:16 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: >=20 >=20 > Dear all > =20 > =20 > In the objective of relying on IETF specifications to handle Diameter = overload for 3GPP applications, as Alcatel-Lucent, we did an analysis of = thedraft-ietf-dime-overload-reqs-01. > =20 > We consider the list of REQs described in the IETF draft as quite = extensive and all REQs relevant. We have the few additional comments to = submit to the upcoming Dime review: > =20 > =95 We suggest to put more emphasis in REQ1 on the fact this is = both for load (preventive) and overload (reactive). A possible writing: > REQ 1: The overload mechanism MUST provide a communication method = for Diameter nodes to exchange load andoverload information. > =20 > =20 > sounds reasonable to me. >=20 >=20 > =95 About REQ 2 (=93The overload mechanism MUST be useable with = any existing or future Diameter application. It MUST NOT require = specification changes for existing Diameter applications=94), an = existing application may evolve to support an overload mechanism, = especially when the overload handling may rely on certain application = dependent behaviors (which would be within 3GPP scope for applications = defined by 3GPP). It also may have a consistency issue with REQ13 = =93allowing for the possibility of increased feedback for information = piggybacked=94as the piggybacking mechanism may impact the application. = May be a solution is to suppress this second part of the REQ2 (=93 It = MUST NOT require specification changes for existing Diameter = applications=94) or review the wording. > =20 > The intent of this was not to say that applications can not be changed = to make use of overload control, just that they won't be required to. I = think with either of the proposed mechanisms based on these = requirements, this would be met. They can be used without any = alteration to applications. That said, overload control will work = better with consideration for how each application can be impacted and = how it should respond. =20 > =20 > The second part of REQ 13 is only commentary on the scaling properties = of existing messaging, but in general piggybacking can be done without = impacting applications. This requires a * [ AVP ] in the applications = messages though. Adam did a survey of all the applications he could = find when he was writing the proposed mechanism and did not find any = examples where this was not the case (and this is recommended by the = base protocol). >=20 >=20 > =20 > =95 On REQ 26, we have the following reading we consider = important: the specifications of the diameter load/overload control can = only give an overall guidance. Actual and precise specification of the = =93which message types might be desirable to send or process over others = during times of overload=94 should be left for each application to = define (for =93 =85 Diameter specific considerations). If this reading = of REQ 26 is shared, apossible rewording could be: > REQ 26: The generic specification for the overload mechanism SHOULD = offer overall guidance on which message types might be desirable to send = or process over others during times of overload, based on = Diameter-specific considerations. For example, it may be more = beneficial to process messages for existing sessions ahead of new = sessions. A precise specification of the relative priorities of message = types in case of overload would anyhow be under the responsibility of = each application. > =20 > I believe that was the point it was trying to get across. I think = your last sentence would add some clarity. > =20 >=20 >=20 > =20 > =95 We expressed the point that overload handling should take = into account that some messages may have a high priority (eg when = related to an emergency or a high priority user=94). This handling = would be application dependent and so entering the REQ 26 as an overall = guidance but it could be mentioned in REQ 26 as an example with the = possible wording > =93 For example, it may be more beneficial to process messages for = existing sessions ahead of new sessions and to give priority to requests = associated with emergency sessions or with high priority users=94 > =20 > I don't have any issue with that. What was there was intended as only = the simplest example. There are many ways to do this. Adding one more = example shouldn't hurt, but we probably don't want to go down the path = of listing possibilities here. >=20 >=20 > =20 > =95 Last sentence of REQ 35 appears unclear, wording may be = reviewed or this sentence may be suppressed. > =20 > We can probably strike that. What do you think, Ben? >=20 >=20 > =20 > . > Best regards > =20 > JJacques Trottin > Alcatel-Lucent delegate to 3GPP CT4 > =20 > =20 > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange.com Thu Dec 6 09:50:40 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F9821F8695 for ; Thu, 6 Dec 2012 09:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, WEIRD_QUOTING=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iz4+wQa+m0p for ; Thu, 6 Dec 2012 09:50:38 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 725E321F866F for ; Thu, 6 Dec 2012 09:50:37 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 556623B4AAB; Thu, 6 Dec 2012 18:50:36 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 399F94C063; Thu, 6 Dec 2012 18:50:36 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Thu, 6 Dec 2012 18:50:35 +0100 From: To: Ben Campbell , "THIEBAUT, LAURENT (LAURENT)" Thread-Topic: [Dime] Dime: Diameter Overload IETF requirements, review Thread-Index: Ac3TusuunSJZEqN9SqqEx3YmfVE7EwADHOXQ///3BgD//+RS0A== Date: Thu, 6 Dec 2012 17:50:34 +0000 Message-ID: <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <23E0ABAF-E856-44A9-8F6D-C88B8CAB2A57@computer.org> <170E8FCC2134BD42B539B47798ABF8F026C0C43982@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> In-Reply-To: <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.6.172131 Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 17:50:40 -0000 Hi, I think that we should not misuse "application" and "specification" here. T= he problem is not about change in the specification but about change in the= Diameter application.=20 In my understanding, the intention of the second sentence of REQ2 is to say= that the support of OC mechanism must not imply major extensions of existi= ng Diameter Applications, which would cause the definition of a new applica= tion and the allocation of a new Application-id, as per RFC6733. But of course, if required, existing applications can be slightly enhanced = to support OC without major impacts (e.g. using optional AVPs), and then no= need for new Application-id, and then the related specification will have = to be updated to describe how to support this new feature. If my understanding is correct, would the following change be agreeable? OLD: REQ 2: The overload [control] mechanism MUST be useable with any exist= ing or future Diameter application. It MUST NOT require specification changes for existing Diameter applications. NEW: REQ 2: The overload [control] mechanism MUST be useable with any exist= ing or future Diameter application. Support of this mechanism over ex= isting Diameter applications MUST NOT require major changes that would= lead to the need to define a new Diameter application. By the way, I think that we are working on a mechanism to control overload = and not a mechanism for overload, right. Should "overload mechanism" be rep= laced by "overload control mechanism" all over the document? Lionel -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de B= en Campbell Envoy=E9=A0: jeudi 6 d=E9cembre 2012 17:03 =C0=A0: THIEBAUT, LAURENT (LAURENT) Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Dime: Diameter Overload IETF requirements, review On Dec 6, 2012, at 9:48 AM, "THIEBAUT, LAURENT (LAURENT)" wrote: >=20=20 >=20=20 > Hello all > About Req2, we understand that based on the usage of the *[ AVP ], there = is no need to update the ""ABNF"" of the protocol describing the various Di= ameter applications! Nevertheless the behaviour of the application, i.e. t= he SW using that "unchanged protocol" will have to be changed anyhow to sup= port Diameter overload control. Can we reword Req2 into > The overload mechanism MUST be useable with any existing or future Diamet= er application. It MUST NOT require specification changes for existing Dia= meter applications *but is likely to require a change of the behaviour of a= n entity supporting a Diameter application and the Diameter overload mechan= ism.* >=20=20 > This "is likely" is NOT an IETF normative wording (MUST, SHOULD,.) as the= part of the sentence that is being added is more of an explanatory / clari= fication nature (I hope). I have mixed feelings about this, and I think it has to do with the definit= ion of "application". If we do this right, the _base_ Diameter overload co= ntrol behavior should come to any application, old or new, for "free", assu= ming the definition of that application included the *[ AVP ] construction.= That's in the strict sense of what constitutes a "Diameter Application". I= f the application would benefit from more application specific behaviors, t= hey can always add them. OTOH, the definition of an "interface" that uses one or more "applications"= is highly likely to change, if for no reason that to require support of OC. I propose an indented paragraph with a couple of sentences to explain this,= rather than making it part of the same sentence as the normative requireme= nt. > Best regards > Laurent=20 > ALCATEL-LUCENT > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de E= ric McMurry > Envoy=E9 : jeudi 6 d=E9cembre 2012 15:05 > =C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES) > Cc : dime@ietf.org > Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review >=20=20 > Thanks for the comments! >=20=20 > responses inline. >=20=20 > Eric >=20=20 >=20=20 > On Dec 6, 2012, at 7:16 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" wrote: >=20 >=20 > Dear all >=20=20 >=20=20 > In the objective of relying on IETF specifications to handle Diameter ove= rload for 3GPP applications, as Alcatel-Lucent, we did an analysis of thedr= aft-ietf-dime-overload-reqs-01. >=20=20 > We consider the list of REQs described in the IETF draft as quite extensi= ve and all REQs relevant. We have the few additional comments to submit to = the upcoming Dime review: >=20=20 > . We suggest to put more emphasis in REQ1 on the fact this is both for l= oad (preventive) and overload (reactive). A possible writing: > REQ 1: The overload mechanism MUST provide a communication method for D= iameter nodes to exchange load andoverload information. >=20=20 >=20=20 > sounds reasonable to me. >=20 >=20 > . About REQ 2 ("The overload mechanism MUST be useable with any existing= or future Diameter application. It MUST NOT require specification changes= for existing Diameter applications"), an existing application may evolve t= o support an overload mechanism, especially when the overload handling may = rely on certain application dependent behaviors (which would be within 3GPP= scope for applications defined by 3GPP). It also may have a consistency is= sue with REQ13 "allowing for the possibility of increased feedback for info= rmation piggybacked"as the piggybacking mechanism may impact the applicatio= n. May be a solution is to suppress this second part of the REQ2 (" It MUST= NOT require specification changes for existing Diameter applications") or = review the wording. >=20=20 > The intent of this was not to say that applications can not be changed to= make use of overload control, just that they won't be required to. I thin= k with either of the proposed mechanisms based on these requirements, this = would be met. They can be used without any alteration to applications. Th= at said, overload control will work better with consideration for how each = application can be impacted and how it should respond.=20=20 >=20=20 > The second part of REQ 13 is only commentary on the scaling properties of= existing messaging, but in general piggybacking can be done without impact= ing applications. This requires a * [ AVP ] in the applications messages t= hough. Adam did a survey of all the applications he could find when he was= writing the proposed mechanism and did not find any examples where this wa= s not the case (and this is recommended by the base protocol). >=20 >=20 >=20=20 > . On REQ 26, we have the following reading we consider important: the sp= ecifications of the diameter load/overload control can only give an overall= guidance. Actual and precise specification of the "which message types mig= ht be desirable to send or process over others during times of overload" sh= ould be left for each application to define (for " . Diameter specific con= siderations). If this reading of REQ 26 is shared, apossible rewording coul= d be: > REQ 26: The generic specification for the overload mechanism SHOULD offe= r overall guidance on which message types might be desirable to send or pro= cess over others during times of overload, based on Diameter-specific consi= derations. For example, it may be more beneficial to process messages for = existing sessions ahead of new sessions. A precise specification of the rel= ative priorities of message types in case of overload would anyhow be under= the responsibility of each application. >=20=20 > I believe that was the point it was trying to get across. I think your l= ast sentence would add some clarity. >=20=20 >=20 >=20 >=20=20 > . We expressed the point that overload handling should take into account= that some messages may have a high priority (eg when related to an emergen= cy or a high priority user"). This handling would be application dependen= t and so entering the REQ 26 as an overall guidance but it could be mention= ed in REQ 26 as an example with the possible wording > " For example, it may be more beneficial to process messages for existing= sessions ahead of new sessions and to give priority to requests associated= with emergency sessions or with high priority users" >=20=20 > I don't have any issue with that. What was there was intended as only th= e simplest example. There are many ways to do this. Adding one more examp= le shouldn't hurt, but we probably don't want to go down the path of listin= g possibilities here. >=20 >=20 >=20=20 > . Last sentence of REQ 35 appears unclear, wording may be reviewed or th= is sentence may be suppressed. >=20=20 > We can probably strike that. What do you think, Ben? >=20 >=20 >=20=20 > . > Best regards >=20=20 > JJacques Trottin > Alcatel-Lucent delegate to 3GPP CT4 >=20=20 >=20=20 >=20=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20=20 > _______________________________________________ > 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 confiden= tielles 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 el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From emcmurry@computer.org Thu Dec 6 10:12:54 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4292821F87E1 for ; Thu, 6 Dec 2012 10:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAYTC5qcWj2d for ; Thu, 6 Dec 2012 10:12:53 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9594121F87FD for ; Thu, 6 Dec 2012 10:12:53 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1TgfwL-000NTt-0y; Thu, 06 Dec 2012 18:12:53 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 7B581ABF7B1; Thu, 6 Dec 2012 12:12:50 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/Ieo4/HtaJz+960u9m2hRWWiJL8vCYxRo= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GH5TFk78jAm8; Thu, 6 Dec 2012 12:12:50 -0600 (CST) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 5FEBDABF7A7; Thu, 6 Dec 2012 12:12:50 -0600 (CST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric McMurry In-Reply-To: <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Thu, 6 Dec 2012 12:12:50 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> References: <23E0ABAF-E856-44A9-8F6D-C88B8CAB2A57@computer.org> <170E8FCC2134BD42B539B47798ABF8F026C0C43982@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1499) Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 18:12:54 -0000 On Dec 6, 2012, at 11:50 , lionel.morand@orange.com wrote: > Hi, >=20 > I think that we should not misuse "application" and "specification" = here. The problem is not about change in the specification but about = change in the Diameter application.=20 >=20 > In my understanding, the intention of the second sentence of REQ2 is = to say that the support of OC mechanism must not imply major extensions = of existing Diameter Applications, which would cause the definition of a = new application and the allocation of a new Application-id, as per = RFC6733. >=20 > But of course, if required, existing applications can be slightly = enhanced to support OC without major impacts (e.g. using optional AVPs), = and then no need for new Application-id, and then the related = specification will have to be updated to describe how to support this = new feature. >=20 > If my understanding is correct, would the following change be = agreeable? >=20 > OLD: >=20 > REQ 2: The overload [control] mechanism MUST be useable with any = existing or > future Diameter application. It MUST NOT require > specification changes for existing Diameter applications. >=20 > NEW: >=20 > REQ 2: The overload [control] mechanism MUST be useable with any = existing or > future Diameter application. Support of this mechanism over = existing > Diameter applications MUST NOT require major changes that = would lead > to the need to define a new Diameter application. sounds reasonable, but it's a bit less strong. It would be good for the = mechanism to work without requiring any changes to applications. This = is achievable and I think both proposed mechanisms could be used over, = or alongside, existing applications without any changes to the = applications. Applications may provide additional specification on top = of this, which the requirements do not at all prevent now. I gather = some would like additional language spelling this out though. >=20 >=20 > By the way, I think that we are working on a mechanism to control = overload and not a mechanism for overload, right. Should "overload = mechanism" be replaced by "overload control mechanism" all over the = document? >=20 I suppose we have plenty of mechanisms for overload already. I think I had intended to do just this at one point, but it must have = fallen out of my head. >=20 [...]= From laurent.thiebaut@alcatel-lucent.com Thu Dec 6 10:24:45 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB30C21F8691 for ; Thu, 6 Dec 2012 10:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[AWL=-1.349, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, WEIRD_QUOTING=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnI7njmgnemW for ; Thu, 6 Dec 2012 10:24:44 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 0570A21F8676 for ; Thu, 6 Dec 2012 10:24:38 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qB6IOVRL005901 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 6 Dec 2012 19:24:34 +0100 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 6 Dec 2012 19:24:33 +0100 From: "THIEBAUT, LAURENT (LAURENT)" To: "lionel.morand@orange.com" , Ben Campbell Date: Thu, 6 Dec 2012 19:24:32 +0100 Thread-Topic: [Dime] Dime: Diameter Overload IETF requirements, review Thread-Index: Ac3TusuunSJZEqN9SqqEx3YmfVE7EwADHOXQ///3BgD//+RS0P//rT8g Message-ID: <170E8FCC2134BD42B539B47798ABF8F026C0C43A6A@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> References: <23E0ABAF-E856-44A9-8F6D-C88B8CAB2A57@computer.org> <170E8FCC2134BD42B539B47798ABF8F026C0C43982@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 18:24:46 -0000 Hello Lionel The point was not on the protocol itself (so the change you mentioned was n= ot per se requested/hinted by our text). We wanted to highlight that even though there are no new application relate= d AVP being required (because the generic "overload-control" AVP provides e= nough signalling capability for load/overload control), there will be a nee= d for a standard group (e.g. 3GPP for 3GPP based applications) to define th= e *behaviour* of the Diameter (client/server) application upon reception of= this "overload-control" AVP. Said otherwise, even though there is the * [AVP], the diameter overload con= trol AVP and generic specifications we are going to define is not a free me= al for the definition of the application. =20 Best regards Laurent ALCATEL-LUCENT=20 -----Message d'origine----- De=A0: lionel.morand@orange.com [mailto:lionel.morand@orange.com]=20 Envoy=E9=A0: jeudi 6 d=E9cembre 2012 18:51 =C0=A0: Ben Campbell; THIEBAUT, LAURENT (LAURENT) Cc=A0: dime@ietf.org Objet=A0: RE: [Dime] Dime: Diameter Overload IETF requirements, review Hi, I think that we should not misuse "application" and "specification" here. T= he problem is not about change in the specification but about change in the= Diameter application.=20 In my understanding, the intention of the second sentence of REQ2 is to say= that the support of OC mechanism must not imply major extensions of existi= ng Diameter Applications, which would cause the definition of a new applica= tion and the allocation of a new Application-id, as per RFC6733. But of course, if required, existing applications can be slightly enhanced = to support OC without major impacts (e.g. using optional AVPs), and then no= need for new Application-id, and then the related specification will have = to be updated to describe how to support this new feature. If my understanding is correct, would the following change be agreeable? OLD: REQ 2: The overload [control] mechanism MUST be useable with any exist= ing or future Diameter application. It MUST NOT require specification changes for existing Diameter applications. NEW: REQ 2: The overload [control] mechanism MUST be useable with any exist= ing or future Diameter application. Support of this mechanism over ex= isting Diameter applications MUST NOT require major changes that would= lead to the need to define a new Diameter application. By the way, I think that we are working on a mechanism to control overload = and not a mechanism for overload, right. Should "overload mechanism" be rep= laced by "overload control mechanism" all over the document? Lionel -----Message d'origine----- De=A0: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de B= en Campbell Envoy=E9=A0: jeudi 6 d=E9cembre 2012 17:03 =C0=A0: THIEBAUT, LAURENT (LAURENT) Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Dime: Diameter Overload IETF requirements, review On Dec 6, 2012, at 9:48 AM, "THIEBAUT, LAURENT (LAURENT)" wrote: > =20 > =20 > Hello all > About Req2, we understand that based on the usage of the *[ AVP ], there = is no need to update the ""ABNF"" of the protocol describing the various Di= ameter applications! Nevertheless the behaviour of the application, i.e. t= he SW using that "unchanged protocol" will have to be changed anyhow to sup= port Diameter overload control. Can we reword Req2 into > The overload mechanism MUST be useable with any existing or future Diamet= er application. It MUST NOT require specification changes for existing Dia= meter applications *but is likely to require a change of the behaviour of a= n entity supporting a Diameter application and the Diameter overload mechan= ism.* > =20 > This "is likely" is NOT an IETF normative wording (MUST, SHOULD,.) as the= part of the sentence that is being added is more of an explanatory / clari= fication nature (I hope). I have mixed feelings about this, and I think it has to do with the definit= ion of "application". If we do this right, the _base_ Diameter overload co= ntrol behavior should come to any application, old or new, for "free", assu= ming the definition of that application included the *[ AVP ] construction.= That's in the strict sense of what constitutes a "Diameter Application". I= f the application would benefit from more application specific behaviors, t= hey can always add them. OTOH, the definition of an "interface" that uses one or more "applications"= is highly likely to change, if for no reason that to require support of OC= . I propose an indented paragraph with a couple of sentences to explain this,= rather than making it part of the same sentence as the normative requireme= nt. > Best regards > Laurent=20 > ALCATEL-LUCENT > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de E= ric McMurry > Envoy=E9 : jeudi 6 d=E9cembre 2012 15:05 > =C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES) > Cc : dime@ietf.org > Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review > =20 > Thanks for the comments! > =20 > responses inline. > =20 > Eric > =20 > =20 > On Dec 6, 2012, at 7:16 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" wrote: >=20 >=20 > Dear all > =20 > =20 > In the objective of relying on IETF specifications to handle Diameter ove= rload for 3GPP applications, as Alcatel-Lucent, we did an analysis of thedr= aft-ietf-dime-overload-reqs-01. > =20 > We consider the list of REQs described in the IETF draft as quite extensi= ve and all REQs relevant. We have the few additional comments to submit to = the upcoming Dime review: > =20 > . We suggest to put more emphasis in REQ1 on the fact this is both for l= oad (preventive) and overload (reactive). A possible writing: > REQ 1: The overload mechanism MUST provide a communication method for D= iameter nodes to exchange load andoverload information. > =20 > =20 > sounds reasonable to me. >=20 >=20 > . About REQ 2 ("The overload mechanism MUST be useable with any existing= or future Diameter application. It MUST NOT require specification changes= for existing Diameter applications"), an existing application may evolve t= o support an overload mechanism, especially when the overload handling may = rely on certain application dependent behaviors (which would be within 3GPP= scope for applications defined by 3GPP). It also may have a consistency is= sue with REQ13 "allowing for the possibility of increased feedback for info= rmation piggybacked"as the piggybacking mechanism may impact the applicatio= n. May be a solution is to suppress this second part of the REQ2 (" It MUST= NOT require specification changes for existing Diameter applications") or = review the wording. > =20 > The intent of this was not to say that applications can not be changed to= make use of overload control, just that they won't be required to. I thin= k with either of the proposed mechanisms based on these requirements, this = would be met. They can be used without any alteration to applications. Th= at said, overload control will work better with consideration for how each = application can be impacted and how it should respond. =20 > =20 > The second part of REQ 13 is only commentary on the scaling properties of= existing messaging, but in general piggybacking can be done without impact= ing applications. This requires a * [ AVP ] in the applications messages t= hough. Adam did a survey of all the applications he could find when he was= writing the proposed mechanism and did not find any examples where this wa= s not the case (and this is recommended by the base protocol). >=20 >=20 > =20 > . On REQ 26, we have the following reading we consider important: the sp= ecifications of the diameter load/overload control can only give an overall= guidance. Actual and precise specification of the "which message types mig= ht be desirable to send or process over others during times of overload" sh= ould be left for each application to define (for " . Diameter specific con= siderations). If this reading of REQ 26 is shared, apossible rewording coul= d be: > REQ 26: The generic specification for the overload mechanism SHOULD offe= r overall guidance on which message types might be desirable to send or pro= cess over others during times of overload, based on Diameter-specific consi= derations. For example, it may be more beneficial to process messages for = existing sessions ahead of new sessions. A precise specification of the rel= ative priorities of message types in case of overload would anyhow be under= the responsibility of each application. > =20 > I believe that was the point it was trying to get across. I think your l= ast sentence would add some clarity. > =20 >=20 >=20 > =20 > . We expressed the point that overload handling should take into account= that some messages may have a high priority (eg when related to an emergen= cy or a high priority user"). This handling would be application dependen= t and so entering the REQ 26 as an overall guidance but it could be mention= ed in REQ 26 as an example with the possible wording > " For example, it may be more beneficial to process messages for existing= sessions ahead of new sessions and to give priority to requests associated= with emergency sessions or with high priority users" > =20 > I don't have any issue with that. What was there was intended as only th= e simplest example. There are many ways to do this. Adding one more examp= le shouldn't hurt, but we probably don't want to go down the path of listin= g possibilities here. >=20 >=20 > =20 > . Last sentence of REQ 35 appears unclear, wording may be reviewed or th= is sentence may be suppressed. > =20 > We can probably strike that. What do you think, Ben? >=20 >=20 > =20 > . > Best regards > =20 > JJacques Trottin > Alcatel-Lucent delegate to 3GPP CT4 > =20 > =20 > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > =20 > _______________________________________________ > 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 confiden= tielles 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 el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From lionel.morand@orange.com Thu Dec 6 10:32:31 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A699F21F87E9 for ; Thu, 6 Dec 2012 10:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cpWy43vEe-D for ; Thu, 6 Dec 2012 10:32:31 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B806521F86C8 for ; Thu, 6 Dec 2012 10:32:30 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 02218324B10; Thu, 6 Dec 2012 19:32:30 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D99D44C017; Thu, 6 Dec 2012 19:32:29 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Thu, 6 Dec 2012 19:32:29 +0100 From: To: Eric McMurry Thread-Topic: [Dime] Dime: Diameter Overload IETF requirements, review Thread-Index: Ac3TusuunSJZEqN9SqqEx3YmfVE7EwADHOXQ///3BgD//+RS0IAAQAAA///tC2A= Date: Thu, 6 Dec 2012 18:32:29 +0000 Message-ID: <28892_1354818749_50C0E4BD_28892_4479_1_6B7134B31289DC4FAF731D844122B36E0BF868@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <23E0ABAF-E856-44A9-8F6D-C88B8CAB2A57@computer.org> <170E8FCC2134BD42B539B47798ABF8F026C0C43982@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> In-Reply-To: <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.6.172131 Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 18:32:31 -0000 Hi Eric, Please see below. Regard, Lionel -----Message d'origine----- De=A0: Eric McMurry [mailto:emcmurry@computer.org]=20 Envoy=E9=A0: jeudi 6 d=E9cembre 2012 19:13 =C0=A0: MORAND Lionel OLNC/OLN Cc=A0: Ben Campbell; THIEBAUT, LAURENT (LAURENT); dime@ietf.org Objet=A0: Re: [Dime] Dime: Diameter Overload IETF requirements, review On Dec 6, 2012, at 11:50 , lionel.morand@orange.com wrote: > Hi, >=20 > I think that we should not misuse "application" and "specification" here.= The problem is not about change in the specification but about change in t= he Diameter application.=20 >=20 > In my understanding, the intention of the second sentence of REQ2 is to s= ay that the support of OC mechanism must not imply major extensions of exis= ting Diameter Applications, which would cause the definition of a new appli= cation and the allocation of a new Application-id, as per RFC6733. >=20 > But of course, if required, existing applications can be slightly enhance= d to support OC without major impacts (e.g. using optional AVPs), and then = no need for new Application-id, and then the related specification will hav= e to be updated to describe how to support this new feature. >=20 > If my understanding is correct, would the following change be agreeable? >=20 > OLD: >=20 > REQ 2: The overload [control] mechanism MUST be useable with any exist= ing or > future Diameter application. It MUST NOT require > specification changes for existing Diameter applications. >=20 > NEW: >=20 > REQ 2: The overload [control] mechanism MUST be useable with any exist= ing or > future Diameter application. Support of this mechanism over ex= isting > Diameter applications MUST NOT require major changes that would= lead > to the need to define a new Diameter application. sounds reasonable, but it's a bit less strong. It would be good for the me= chanism to work without requiring any changes to applications. This is ach= ievable and I think both proposed mechanisms could be used over, or alongsi= de, existing applications without any changes to the applications. Applica= tions may provide additional specification on top of this, which the requir= ements do not at all prevent now. I gather some would like additional lang= uage spelling this out though. [LM] Both solutions consider "piggybacking" and piggybacking of any new inf= o over existing commands is actually a change into the Diameter application= . But what we want is to make this change as smooth as possible for existin= g application. And it is the requirement that I read in REQ2. Now if it is about "alongside" i.e. with no protocol change at all on exist= ing application, the second sentence REQ2 would be anyway irrelevant becaus= e you could say that for any other protocol e.g. "this mechanism MUST NOT r= equire specification changes for existing SIP or HTTP or whatever" >=20=09=20 > By the way, I think that we are working on a mechanism to control overloa= d and not a mechanism for overload, right. Should "overload mechanism" be r= eplaced by "overload control mechanism" all over the document? >=20 I suppose we have plenty of mechanisms for overload already. I think I had intended to do just this at one point, but it must have falle= n out of my head. >=20 [...] ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From ben@nostrum.com Thu Dec 6 10:41:58 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B504821F853A for ; Thu, 6 Dec 2012 10:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100, WEIRD_QUOTING=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W++gO-RKLPV1 for ; Thu, 6 Dec 2012 10:41:57 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A2D9821F8532 for ; Thu, 6 Dec 2012 10:41:57 -0800 (PST) Received: from [10.0.1.14] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qB6If4EJ019457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Dec 2012 12:41:05 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Thu, 6 Dec 2012 12:41:07 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <87BCF41E-7B77-4A56-A09D-8139F79E6EF5@nostrum.com> References: <23E0ABAF-E856-44A9-8F6D-C88B8CAB2A57@computer.org> <170E8FCC2134BD42B539B47798ABF8F026C0C43982@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 18:41:58 -0000 On Dec 6, 2012, at 11:50 AM, wrote: > Hi, >=20 > I think that we should not misuse "application" and "specification" = here. The problem is not about change in the specification but about = change in the Diameter application.=20 >=20 > In my understanding, the intention of the second sentence of REQ2 is = to say that the support of OC mechanism must not imply major extensions = of existing Diameter Applications, which would cause the definition of a = new application and the allocation of a new Application-id, as per = RFC6733. >=20 > But of course, if required, existing applications can be slightly = enhanced to support OC without major impacts (e.g. using optional AVPs), = and then no need for new Application-id, and then the related = specification will have to be updated to describe how to support this = new feature. >=20 > If my understanding is correct, would the following change be = agreeable? >=20 > OLD: >=20 > REQ 2: The overload [control] mechanism MUST be useable with any = existing or > future Diameter application. It MUST NOT require > specification changes for existing Diameter applications. >=20 > NEW: >=20 > REQ 2: The overload [control] mechanism MUST be useable with any = existing or > future Diameter application. Support of this mechanism = over existing > Diameter applications MUST NOT require major changes that = would lead > to the need to define a new Diameter application. WFM >=20 >=20 > By the way, I think that we are working on a mechanism to control = overload and not a mechanism for overload, right. Should "overload = mechanism" be replaced by "overload control mechanism" all over the = document? >=20 Agreed. Overload can happen just fine without any help from us :-) >=20 > Lionel >=20 > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Ben Campbell > Envoy=E9 : jeudi 6 d=E9cembre 2012 17:03 > =C0 : THIEBAUT, LAURENT (LAURENT) > Cc : dime@ietf.org > Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review >=20 >=20 > On Dec 6, 2012, at 9:48 AM, "THIEBAUT, LAURENT (LAURENT)" = wrote: >=20 >>=20 >>=20 >> Hello all >> About Req2, we understand that based on the usage of the *[ AVP ], = there is no need to update the ""ABNF"" of the protocol describing the = various Diameter applications! Nevertheless the behaviour of the = application, i.e. the SW using that "unchanged protocol" will have to be = changed anyhow to support Diameter overload control. Can we reword Req2 = into >> The overload mechanism MUST be useable with any existing or future = Diameter application. It MUST NOT require specification changes for = existing Diameter applications *but is likely to require a change of the = behaviour of an entity supporting a Diameter application and the = Diameter overload mechanism.* >>=20 >> This "is likely" is NOT an IETF normative wording (MUST, SHOULD,.) as = the part of the sentence that is being added is more of an explanatory / = clarification nature (I hope). >=20 > I have mixed feelings about this, and I think it has to do with the = definition of "application". If we do this right, the _base_ Diameter = overload control behavior should come to any application, old or new, = for "free", assuming the definition of that application included the *[ = AVP ] construction. That's in the strict sense of what constitutes a = "Diameter Application". If the application would benefit from more = application specific behaviors, they can always add them. >=20 > OTOH, the definition of an "interface" that uses one or more = "applications" is highly likely to change, if for no reason that to = require support of OC. >=20 > I propose an indented paragraph with a couple of sentences to explain = this, rather than making it part of the same sentence as the normative = requirement. >=20 >> Best regards >> Laurent=20 >> ALCATEL-LUCENT >> De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Eric McMurry >> Envoy=E9 : jeudi 6 d=E9cembre 2012 15:05 >> =C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES) >> Cc : dime@ietf.org >> Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review >>=20 >> Thanks for the comments! >>=20 >> responses inline. >>=20 >> Eric >>=20 >>=20 >> On Dec 6, 2012, at 7:16 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: >>=20 >>=20 >> Dear all >>=20 >>=20 >> In the objective of relying on IETF specifications to handle Diameter = overload for 3GPP applications, as Alcatel-Lucent, we did an analysis of = thedraft-ietf-dime-overload-reqs-01. >>=20 >> We consider the list of REQs described in the IETF draft as quite = extensive and all REQs relevant. We have the few additional comments to = submit to the upcoming Dime review: >>=20 >> . We suggest to put more emphasis in REQ1 on the fact this is = both for load (preventive) and overload (reactive). A possible writing: >> REQ 1: The overload mechanism MUST provide a communication method = for Diameter nodes to exchange load andoverload information. >>=20 >>=20 >> sounds reasonable to me. >>=20 >>=20 >> . About REQ 2 ("The overload mechanism MUST be useable with any = existing or future Diameter application. It MUST NOT require = specification changes for existing Diameter applications"), an existing = application may evolve to support an overload mechanism, especially when = the overload handling may rely on certain application dependent = behaviors (which would be within 3GPP scope for applications defined by = 3GPP). It also may have a consistency issue with REQ13 "allowing for the = possibility of increased feedback for information piggybacked"as the = piggybacking mechanism may impact the application. May be a solution is = to suppress this second part of the REQ2 (" It MUST NOT require = specification changes for existing Diameter applications") or review the = wording. >>=20 >> The intent of this was not to say that applications can not be = changed to make use of overload control, just that they won't be = required to. I think with either of the proposed mechanisms based on = these requirements, this would be met. They can be used without any = alteration to applications. That said, overload control will work = better with consideration for how each application can be impacted and = how it should respond. =20 >>=20 >> The second part of REQ 13 is only commentary on the scaling = properties of existing messaging, but in general piggybacking can be = done without impacting applications. This requires a * [ AVP ] in the = applications messages though. Adam did a survey of all the applications = he could find when he was writing the proposed mechanism and did not = find any examples where this was not the case (and this is recommended = by the base protocol). >>=20 >>=20 >>=20 >> . On REQ 26, we have the following reading we consider = important: the specifications of the diameter load/overload control can = only give an overall guidance. Actual and precise specification of the = "which message types might be desirable to send or process over others = during times of overload" should be left for each application to define = (for " . Diameter specific considerations). If this reading of REQ 26 = is shared, apossible rewording could be: >> REQ 26: The generic specification for the overload mechanism SHOULD = offer overall guidance on which message types might be desirable to send = or process over others during times of overload, based on = Diameter-specific considerations. For example, it may be more = beneficial to process messages for existing sessions ahead of new = sessions. A precise specification of the relative priorities of message = types in case of overload would anyhow be under the responsibility of = each application. >>=20 >> I believe that was the point it was trying to get across. I think = your last sentence would add some clarity. >>=20 >>=20 >>=20 >>=20 >> . We expressed the point that overload handling should take into = account that some messages may have a high priority (eg when related to = an emergency or a high priority user"). This handling would be = application dependent and so entering the REQ 26 as an overall guidance = but it could be mentioned in REQ 26 as an example with the possible = wording >> " For example, it may be more beneficial to process messages for = existing sessions ahead of new sessions and to give priority to requests = associated with emergency sessions or with high priority users" >>=20 >> I don't have any issue with that. What was there was intended as = only the simplest example. There are many ways to do this. Adding one = more example shouldn't hurt, but we probably don't want to go down the = path of listing possibilities here. >>=20 >>=20 >>=20 >> . Last sentence of REQ 35 appears unclear, wording may be = reviewed or this sentence may be suppressed. >>=20 >> We can probably strike that. What do you think, Ben? >>=20 >>=20 >>=20 >> . >> Best regards >>=20 >> JJacques Trottin >> Alcatel-Lucent delegate to 3GPP CT4 >>=20 >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > 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, > France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >=20 > 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, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. >=20 From emcmurry@computer.org Thu Dec 6 10:46:19 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E7521F8801 for ; Thu, 6 Dec 2012 10:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fO98Cz9ruQYE for ; Thu, 6 Dec 2012 10:46:19 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3CE21F8545 for ; Thu, 6 Dec 2012 10:46:19 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1TggSg-000J6k-IY; Thu, 06 Dec 2012 18:46:18 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 5E353ABFC8E; Thu, 6 Dec 2012 12:46:16 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18M7UiBUHba5R0fpCZ5GSJtDZNXSxNuGuc= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fw9jcOgzReXL; Thu, 6 Dec 2012 12:46:16 -0600 (CST) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 4A7A8ABFC85; Thu, 6 Dec 2012 12:46:16 -0600 (CST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric McMurry In-Reply-To: <28892_1354818749_50C0E4BD_28892_4479_1_6B7134B31289DC4FAF731D844122B36E0BF868@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Thu, 6 Dec 2012 12:46:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <81E2AD4F-9FED-498D-ACA2-538C6ED53B7E@computer.org> References: <23E0ABAF-E856-44A9-8F6D-C88B8CAB2A57@computer.org> <170E8FCC2134BD42B539B47798ABF8F026C0C43982@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> <28892_1354818749_50C0E4BD_28892_4479_1_6B7134B31289DC4FAF731D844122B36E0BF868@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1499) Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 18:46:19 -0000 Thanks Lionel. comments inline. Eric On Dec 6, 2012, at 12:32 , lionel.morand@orange.com wrote: > Hi Eric, >=20 > Please see below. >=20 > Regard, >=20 > Lionel >=20 > -----Message d'origine----- > De : Eric McMurry [mailto:emcmurry@computer.org]=20 > Envoy=E9 : jeudi 6 d=E9cembre 2012 19:13 > =C0 : MORAND Lionel OLNC/OLN > Cc : Ben Campbell; THIEBAUT, LAURENT (LAURENT); dime@ietf.org > Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review >=20 >=20 > On Dec 6, 2012, at 11:50 , lionel.morand@orange.com wrote: >=20 >> Hi, >>=20 >> I think that we should not misuse "application" and "specification" = here. The problem is not about change in the specification but about = change in the Diameter application.=20 >>=20 >> In my understanding, the intention of the second sentence of REQ2 is = to say that the support of OC mechanism must not imply major extensions = of existing Diameter Applications, which would cause the definition of a = new application and the allocation of a new Application-id, as per = RFC6733. >>=20 >> But of course, if required, existing applications can be slightly = enhanced to support OC without major impacts (e.g. using optional AVPs), = and then no need for new Application-id, and then the related = specification will have to be updated to describe how to support this = new feature. >>=20 >> If my understanding is correct, would the following change be = agreeable? >>=20 >> OLD: >>=20 >> REQ 2: The overload [control] mechanism MUST be useable with any = existing or >> future Diameter application. It MUST NOT require >> specification changes for existing Diameter applications. >>=20 >> NEW: >>=20 >> REQ 2: The overload [control] mechanism MUST be useable with any = existing or >> future Diameter application. Support of this mechanism over = existing >> Diameter applications MUST NOT require major changes that = would lead >> to the need to define a new Diameter application. >=20 > sounds reasonable, but it's a bit less strong. It would be good for = the mechanism to work without requiring any changes to applications. = This is achievable and I think both proposed mechanisms could be used = over, or alongside, existing applications without any changes to the = applications. Applications may provide additional specification on top = of this, which the requirements do not at all prevent now. I gather = some would like additional language spelling this out though. >=20 > [LM] Both solutions consider "piggybacking" and piggybacking of any = new info over existing commands is actually a change into the Diameter = application. But what we want is to make this change as smooth as = possible for existing application. And it is the requirement that I read = in REQ2. >=20 > Now if it is about "alongside" i.e. with no protocol change at all on = existing application, the second sentence REQ2 would be anyway = irrelevant because you could say that for any other protocol e.g. "this = mechanism MUST NOT require specification changes for existing SIP or = HTTP or whatever" [em] One solution uses existing messages as a carrier, piggybacking on = them. This can be done by an implementation without any change in the = specification of the messages that are being used. The other solution = uses a separate application that does not use, or alter, any existing = messages. This could also be done without any change in the = specification of other applications. I'm confused as to what changes = would be required in any applications for an element to use either of = the mechanisms? Desired, yes (as Laurent was pointing out), but not = required. [...]= From lionel.morand@orange.com Fri Dec 7 01:42:54 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9946D21F8906 for ; Fri, 7 Dec 2012 01:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91TSzzRfCOEh for ; Fri, 7 Dec 2012 01:42:53 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9571421F860B for ; Fri, 7 Dec 2012 01:42:53 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 28D533B4677; Fri, 7 Dec 2012 10:42:52 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 06EE3238055; Fri, 7 Dec 2012 10:42:52 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Fri, 7 Dec 2012 10:42:51 +0100 From: To: Eric McMurry Thread-Topic: [Dime] Dime: Diameter Overload IETF requirements, review Thread-Index: Ac3TusuunSJZEqN9SqqEx3YmfVE7EwADHOXQ///3BgD//+RS0IAAQAAA///tC2CAABxLgP/+97Xw Date: Fri, 7 Dec 2012 09:42:51 +0000 Message-ID: <13633_1354873372_50C1BA1C_13633_2361_1_6B7134B31289DC4FAF731D844122B36E0C0056@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <23E0ABAF-E856-44A9-8F6D-C88B8CAB2A57@computer.org> <170E8FCC2134BD42B539B47798ABF8F026C0C43982@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> <28892_1354818749_50C0E4BD_28892_4479_1_6B7134B31289DC4FAF731D844122B36E0BF868@PEXCVZYM13.corporate.adroot.infra.ftgroup> <81E2AD4F-9FED-498D-ACA2-538C6ED53B7E@computer.org> In-Reply-To: <81E2AD4F-9FED-498D-ACA2-538C6ED53B7E@computer.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.7.81522 Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 09:42:54 -0000 Hi Eric, I think that I understand the misunderstanding. Please see below >> Hi, >>=20 >> I think that we should not misuse "application" and "specification" here= . The problem is not about change in the specification but about change in = the Diameter application.=20 >>=20 >> In my understanding, the intention of the second sentence of REQ2 is to = say that the support of OC mechanism must not imply major extensions of exi= sting Diameter Applications, which would cause the definition of a new appl= ication and the allocation of a new Application-id, as per RFC6733. >>=20 >> But of course, if required, existing applications can be slightly enhanc= ed to support OC without major impacts (e.g. using optional AVPs), and then= no need for new Application-id, and then the related specification will ha= ve to be updated to describe how to support this new feature. >>=20 >> If my understanding is correct, would the following change be agreeable? >>=20 >> OLD: >>=20 >> REQ 2: The overload [control] mechanism MUST be useable with any exist= ing or >> future Diameter application. It MUST NOT require >> specification changes for existing Diameter applications. >>=20 >> NEW: >>=20 >> REQ 2: The overload [control] mechanism MUST be useable with any exist= ing or >> future Diameter application. Support of this mechanism over ex= isting >> Diameter applications MUST NOT require major changes that would= lead >> to the need to define a new Diameter application. >=20 > sounds reasonable, but it's a bit less strong. It would be good for the = mechanism to work without requiring any changes to applications. This is a= chievable and I think both proposed mechanisms could be used over, or along= side, existing applications without any changes to the applications. Appli= cations may provide additional specification on top of this, which the requ= irements do not at all prevent now. I gather some would like additional la= nguage spelling this out though. >=20 > [LM] Both solutions consider "piggybacking" and piggybacking of any new i= nfo over existing commands is actually a change into the Diameter applicati= on. But what we want is to make this change as smooth as possible for exist= ing application. And it is the requirement that I read in REQ2. >=20 > Now if it is about "alongside" i.e. with no protocol change at all on exi= sting application, the second sentence REQ2 would be anyway irrelevant beca= use you could say that for any other protocol e.g. "this mechanism MUST NOT= require specification changes for existing SIP or HTTP or whatever" [em] One solution uses existing messages as a carrier, piggybacking on them= . This can be done by an implementation without any change in the specific= ation of the messages that are being used.=20=20 [LM] It is exactly the issue for me! :) I think that you want to say that e= xisting commands can be extended with changing the CCF specification and it= is true. The application (and its related specification/documentation) usi= ng this command will change! And it is what I highlight in my comment and i= n the proposed change. The other solution uses a separate application that does not use, or alter,= any existing messages. This could also be done without any change in the = specification of other applications.=20 [LM] So the second sentence will be always true i.e. no impact at all on ex= isting applications.=20=20 I'm confused as to what changes would be required in any applications for = an element to use either of the mechanisms? Desired, yes (as Laurent was p= ointing out), but not required. [LM] I hope that clarifies my point... that is not (so) different from your= s and Laurent's one!=20 [...] ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From ben@nostrum.com Fri Dec 7 07:04:40 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B270D21F86EE for ; Fri, 7 Dec 2012 07:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.251 X-Spam-Level: X-Spam-Status: No, score=-102.251 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuDCbCs2yuI4 for ; Fri, 7 Dec 2012 07:04:40 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id DE25121F8667 for ; Fri, 7 Dec 2012 07:04:38 -0800 (PST) Received: from [10.0.1.14] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qB7F4HmY056001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Dec 2012 09:04:18 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <13633_1354873372_50C1BA1C_13633_2361_1_6B7134B31289DC4FAF731D844122B36E0C0056@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Fri, 7 Dec 2012 09:04:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <724F2D49-4B1F-416D-BF94-F46C3DDC02EF@nostrum.com> References: <23E0ABAF-E856-44A9-8F6D-C88B8CAB2A57@computer.org> <170E8FCC2134BD42B539B47798ABF8F026C0C43982@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> <28892_1354818749_50C0E4BD_28892_4479_1_6B7134B31289DC4FAF731D844122B36E0BF868@PEXCVZYM13.corporate.adroot.infra.ftgroup> <81E2AD4F-9FED-498D-ACA2-538C6ED53B7E@computer.org> <13633_1354873372_50C1BA1C_13633_2361_1_6B7134B31289DC4FAF731D844122B36E0C0056@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 15:04:40 -0000 H Lionel, see comments inline: On Dec 7, 2012, at 3:42 AM, lionel.morand@orange.com wrote: > Hi Eric, >=20 > I think that I understand the misunderstanding. Please see below >=20 >>> Hi, >>>=20 >>> I think that we should not misuse "application" and "specification" = here. The problem is not about change in the specification but about = change in the Diameter application.=20 >>>=20 >>> In my understanding, the intention of the second sentence of REQ2 is = to say that the support of OC mechanism must not imply major extensions = of existing Diameter Applications, which would cause the definition of a = new application and the allocation of a new Application-id, as per = RFC6733. >>>=20 >>> But of course, if required, existing applications can be slightly = enhanced to support OC without major impacts (e.g. using optional AVPs), = and then no need for new Application-id, and then the related = specification will have to be updated to describe how to support this = new feature. >>>=20 >>> If my understanding is correct, would the following change be = agreeable? >>>=20 >>> OLD: >>>=20 >>> REQ 2: The overload [control] mechanism MUST be useable with any = existing or >>> future Diameter application. It MUST NOT require >>> specification changes for existing Diameter applications. >>>=20 >>> NEW: >>>=20 >>> REQ 2: The overload [control] mechanism MUST be useable with any = existing or >>> future Diameter application. Support of this mechanism over = existing >>> Diameter applications MUST NOT require major changes that = would lead >>> to the need to define a new Diameter application. >>=20 >> sounds reasonable, but it's a bit less strong. It would be good for = the mechanism to work without requiring any changes to applications. = This is achievable and I think both proposed mechanisms could be used = over, or alongside, existing applications without any changes to the = applications. Applications may provide additional specification on top = of this, which the requirements do not at all prevent now. I gather = some would like additional language spelling this out though. >>=20 >> [LM] Both solutions consider "piggybacking" and piggybacking of any = new info over existing commands is actually a change into the Diameter = application. But what we want is to make this change as smooth as = possible for existing application. And it is the requirement that I read = in REQ2. >>=20 >> Now if it is about "alongside" i.e. with no protocol change at all on = existing application, the second sentence REQ2 would be anyway = irrelevant because you could say that for any other protocol e.g. "this = mechanism MUST NOT require specification changes for existing SIP or = HTTP or whatever" >=20 > [em] One solution uses existing messages as a carrier, piggybacking on = them. This can be done by an implementation without any change in the = specification of the messages that are being used. =20 >=20 > [LM] It is exactly the issue for me! :) I think that you want to say = that existing commands can be extended with changing the CCF = specification and it is true. The application (and its related = specification/documentation) using this command will change! And it is = what I highlight in my comment and in the proposed change. I'm not sure what you mean by the application changing in the piggyback = case. Assuming the application specification uses the * [ AVP ] = construct, an _implementation_ can add the OC AVPs without a change in = the specification of specification. Yes, the implementation changes, but = the spec doesn't have to. Given, there might be benefit to updating the = spec, particularly if you want to describe application-specific = behaviors rather than accepting the base behavior. But that's not a = _requirement_, right? What are we missing? >=20 > The other solution uses a separate application that does not use, or = alter, any existing messages. This could also be done without any = change in the specification of other applications.=20 >=20 > [LM] So the second sentence will be always true i.e. no impact at all = on existing applications. =20 >=20 > I'm confused as to what changes would be required in any applications = for an element to use either of the mechanisms? Desired, yes (as = Laurent was pointing out), but not required. >=20 > [LM] I hope that clarifies my point... that is not (so) different from = yours and Laurent's one!=20 >=20 >=20 > [...] >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > 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, > France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >=20 > 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, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. >=20 From lionel.morand@orange.com Fri Dec 7 07:24:36 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A665E21F8798 for ; Fri, 7 Dec 2012 07:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWFEWy5+ojEV for ; Fri, 7 Dec 2012 07:24:35 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC5321F86C4 for ; Fri, 7 Dec 2012 07:24:33 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 75F993B4C5E; Fri, 7 Dec 2012 16:24:32 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 591B54C017; Fri, 7 Dec 2012 16:24:32 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Fri, 7 Dec 2012 16:24:31 +0100 From: To: Ben Campbell Thread-Topic: [Dime] Dime: Diameter Overload IETF requirements, review Thread-Index: AQHN1IwhnSJZEqN9SqqEx3YmfVE7E5gNcYjA Date: Fri, 7 Dec 2012 15:24:31 +0000 Message-ID: <16364_1354893872_50C20A30_16364_5192_1_6B7134B31289DC4FAF731D844122B36E0C0699@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <23E0ABAF-E856-44A9-8F6D-C88B8CAB2A57@computer.org> <170E8FCC2134BD42B539B47798ABF8F026C0C43982@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> <28892_1354818749_50C0E4BD_28892_4479_1_6B7134B31289DC4FAF731D844122B36E0BF868@PEXCVZYM13.corporate.adroot.infra.ftgroup> <81E2AD4F-9FED-498D-ACA2-538C6ED53B7E@computer.org> <13633_1354873372_50C1BA1C_13633_2361_1_6B7134B31289DC4FAF731D844122B36E0C0056@PEXCVZYM13.corporate.adroot.infra.ftgroup> <724F2D49-4B1F-416D-BF94-F46C3DDC02EF@nostrum.com> In-Reply-To: <724F2D49-4B1F-416D-BF94-F46C3DDC02EF@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.7.144522 Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 15:24:36 -0000 Hi Ben, see below. Regards, Lionel -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com]=20 Envoy=E9=A0: vendredi 7 d=E9cembre 2012 16:04 =C0=A0: MORAND Lionel OLNC/OLN Cc=A0: Eric McMurry; THIEBAUT, LAURENT (LAURENT); dime@ietf.org Objet=A0: Re: [Dime] Dime: Diameter Overload IETF requirements, review H Lionel, see comments inline: On Dec 7, 2012, at 3:42 AM, lionel.morand@orange.com wrote: > Hi Eric, >=20 > I think that I understand the misunderstanding. Please see below >=20 >>> Hi, >>>=20 >>> I think that we should not misuse "application" and "specification" her= e. The problem is not about change in the specification but about change in= the Diameter application.=20 >>>=20 >>> In my understanding, the intention of the second sentence of REQ2 is to= say that the support of OC mechanism must not imply major extensions of ex= isting Diameter Applications, which would cause the definition of a new app= lication and the allocation of a new Application-id, as per RFC6733. >>>=20 >>> But of course, if required, existing applications can be slightly enhan= ced to support OC without major impacts (e.g. using optional AVPs), and the= n no need for new Application-id, and then the related specification will h= ave to be updated to describe how to support this new feature. >>>=20 >>> If my understanding is correct, would the following change be agreeable? >>>=20 >>> OLD: >>>=20 >>> REQ 2: The overload [control] mechanism MUST be useable with any exis= ting or >>> future Diameter application. It MUST NOT require >>> specification changes for existing Diameter applications. >>>=20 >>> NEW: >>>=20 >>> REQ 2: The overload [control] mechanism MUST be useable with any exis= ting or >>> future Diameter application. Support of this mechanism over ex= isting >>> Diameter applications MUST NOT require major changes that would= lead >>> to the need to define a new Diameter application. >>=20 >> sounds reasonable, but it's a bit less strong. It would be good for the= mechanism to work without requiring any changes to applications. This is = achievable and I think both proposed mechanisms could be used over, or alon= gside, existing applications without any changes to the applications. Appl= ications may provide additional specification on top of this, which the req= uirements do not at all prevent now. I gather some would like additional l= anguage spelling this out though. >>=20 >> [LM] Both solutions consider "piggybacking" and piggybacking of any new = info over existing commands is actually a change into the Diameter applicat= ion. But what we want is to make this change as smooth as possible for exis= ting application. And it is the requirement that I read in REQ2. >>=20 >> Now if it is about "alongside" i.e. with no protocol change at all on ex= isting application, the second sentence REQ2 would be anyway irrelevant bec= ause you could say that for any other protocol e.g. "this mechanism MUST NO= T require specification changes for existing SIP or HTTP or whatever" >=20 > [em] One solution uses existing messages as a carrier, piggybacking on th= em. This can be done by an implementation without any change in the specif= ication of the messages that are being used.=20=20 >=20 > [LM] It is exactly the issue for me! :) I think that you want to say that= existing commands can be extended with changing the CCF specification and = it is true. The application (and its related specification/documentation) u= sing this command will change! And it is what I highlight in my comment and= in the proposed change. I'm not sure what you mean by the application changing in the piggyback cas= e. Assuming the application specification uses the * [ AVP ] construct, an = _implementation_ can add the OC AVPs without a change in the specification = of specification. Yes, the implementation changes, but the spec doesn't hav= e to. Given, there might be benefit to updating the spec, particularly if y= ou want to describe application-specific behaviors rather than accepting th= e base behavior. But that's not a _requirement_, right? What are we missing? [LM] it is not the application specification that "uses the *[AVP]" but the= CCF specification of a given command. And an application is not only defin= ed by the command code format specifications. Set of AVP, error codes and s= o on are also part of the application. So adding new AVP to existing applic= ation IS a change of the application and related application specification,= even if this addition is compliant with the CCF specification of the given= command. You will have to describe at least that these new AVPs have to be= carried in a specific set of commands when considering existing applicatio= ns. I think that it the use of "specification" that causes problems here. A= nd it is why I've proposed the change in REQ2. >=20 > The other solution uses a separate application that does not use, or alte= r, any existing messages. This could also be done without any change in th= e specification of other applications.=20 >=20 > [LM] So the second sentence will be always true i.e. no impact at all on = existing applications.=20=20 >=20 > I'm confused as to what changes would be required in any applications for= an element to use either of the mechanisms? Desired, yes (as Laurent was = pointing out), but not required. >=20 > [LM] I hope that clarifies my point... that is not (so) different from yo= urs and Laurent's one!=20 >=20 >=20 > [...] >=20 > _________________________________________________________________________= ________________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu 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, > France Telecom - Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From ben@nostrum.com Fri Dec 7 07:47:46 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594AC21F878C for ; Fri, 7 Dec 2012 07:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.321 X-Spam-Level: X-Spam-Status: No, score=-102.321 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+vpm3YSZlXP for ; Fri, 7 Dec 2012 07:47:45 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5B39921F8784 for ; Fri, 7 Dec 2012 07:47:45 -0800 (PST) Received: from [10.0.1.14] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qB7FlQYd061169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Dec 2012 09:47:27 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <16364_1354893872_50C20A30_16364_5192_1_6B7134B31289DC4FAF731D844122B36E0C0699@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Fri, 7 Dec 2012 09:47:28 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <18AC9DCE-8C27-43AB-AE3E-CBB913A471A7@nostrum.com> References: <23E0ABAF-E856-44A9-8F6D-C88B8CAB2A57@computer.org> <170E8FCC2134BD42B539B47798ABF8F026C0C43982@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> <28892_1354818749_50C0E4BD_28892_4479_1_6B7134B31289DC4FAF731D844122B36E0BF868@PEXCVZYM13.corporate.adroot.infra.ftgroup> <81E2AD4F-9FED-498D-ACA2-538C6ED53B7E@computer.org> <13633_1354873372_50C1BA1C_13633_2361_1_6B7134B31289DC4FAF731D844122B36E0C0056@PEXCVZYM13.corporate.adroot.infra.ftgroup> <724F2D49-4B1F-416D-BF94-F46C3DDC02EF@nostrum.com> <16364_1354893872_50C20A30_16364_5192_1_6B7134B31289DC4FAF731D844122B36E0C0699@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 15:47:46 -0000 On Dec 7, 2012, at 9:24 AM, lionel.morand@orange.com wrote: >> [em] One solution uses existing messages as a carrier, piggybacking = on them. This can be done by an implementation without any change in = the specification of the messages that are being used. =20 >>=20 >> [LM] It is exactly the issue for me! :) I think that you want to say = that existing commands can be extended with changing the CCF = specification and it is true. The application (and its related = specification/documentation) using this command will change! And it is = what I highlight in my comment and in the proposed change. >=20 > I'm not sure what you mean by the application changing in the = piggyback case. Assuming the application specification uses the * [ AVP = ] construct, an _implementation_ can add the OC AVPs without a change in = the specification of specification. Yes, the implementation changes, but = the spec doesn't have to. Given, there might be benefit to updating the = spec, particularly if you want to describe application-specific = behaviors rather than accepting the base behavior. But that's not a = _requirement_, right? >=20 > What are we missing? >=20 > [LM] it is not the application specification that "uses the *[AVP]" = but the CCF specification of a given command. And an application is not = only defined by the command code format specifications. Set of AVP, = error codes and so on are also part of the application. So adding new = AVP to existing application IS a change of the application and related = application specification, even if this addition is compliant with the = CCF specification of the given command. You will have to describe at = least that these new AVPs have to be carried in a specific set of = commands when considering existing applications. I think that it the use = of "specification" that causes problems here. And it is why I've = proposed the change in REQ2. I see your point, but the goal of that language was that you don't = necessarily have to do that. For example, lets assume you have a spec = for application "Foo" that defines a set commands, AVPs (including = *[AVP] ), and their semantics. You also have a spec for piggybacked = overload control, that defines additional AVPs that can be added to any = message, their semantics, and at least one basic overload control = algorithm. (I'm using piggybacked for the sake of argument here, since I = think we agree that the issues are different if we have a separate OC = application) If all an implementer wants to use is the the basic OC algorithm, they = merely implement both specs, adding the OC AVPs (as completely specified = in the OC mechanism spec) to the Foo commands. You don't have to have a = revised Foo spec to use the OC spec. It's analogous to a "mix in" = pattern, if you will. That being said, there may be real benefits to updating the Foo spec. = For example, Foo might need an algorithm other than the base one. Or = maybe it needs to define how to prioritize requests in overload = conditions. Maybe Foo is a 3GPP spec, and they want to _require_ OC. The idea is, you don't have to go back and do a mass update of every = application to make OC useful. You can do it over time, as needed. Thanks! Ben.= From lionel.morand@orange.com Fri Dec 7 08:19:53 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A32621F8797 for ; Fri, 7 Dec 2012 08:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kw2eEVh9wIjm for ; Fri, 7 Dec 2012 08:19:52 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9D921F8767 for ; Fri, 7 Dec 2012 08:19:52 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 613E222CD7F; Fri, 7 Dec 2012 17:19:51 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 3D6C2238048; Fri, 7 Dec 2012 17:19:51 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Fri, 7 Dec 2012 17:19:50 +0100 From: To: Ben Campbell Thread-Topic: [Dime] Dime: Diameter Overload IETF requirements, review Thread-Index: AQHN1IwhnSJZEqN9SqqEx3YmfVE7E5gNcYjA///47QCAABUp0A== Date: Fri, 7 Dec 2012 16:19:50 +0000 Message-ID: <5614_1354897191_50C21727_5614_8583_1_6B7134B31289DC4FAF731D844122B36E0C0756@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <23E0ABAF-E856-44A9-8F6D-C88B8CAB2A57@computer.org> <170E8FCC2134BD42B539B47798ABF8F026C0C43982@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> <28892_1354818749_50C0E4BD_28892_4479_1_6B7134B31289DC4FAF731D844122B36E0BF868@PEXCVZYM13.corporate.adroot.infra.ftgroup> <81E2AD4F-9FED-498D-ACA2-538C6ED53B7E@computer.org> <13633_1354873372_50C1BA1C_13633_2361_1_6B7134B31289DC4FAF731D844122B36E0C0056@PEXCVZYM13.corporate.adroot.infra.ftgroup> <724F2D49-4B1F-416D-BF94-F46C3DDC02EF@nostrum.com> <16364_1354893872_50C20A30_16364_5192_1_6B7134B31289DC4FAF731D844122B36E0C0699@PEXCVZYM13.corporate.adroot.infra.ftgroup> <18AC9DCE-8C27-43AB-AE3E-CBB913A471A7@nostrum.com> In-Reply-To: <18AC9DCE-8C27-43AB-AE3E-CBB913A471A7@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.7.151516 Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 16:19:53 -0000 -----Message d'origine----- De=A0: Ben Campbell [mailto:ben@nostrum.com]=20 Envoy=E9=A0: vendredi 7 d=E9cembre 2012 16:47 =C0=A0: MORAND Lionel OLNC/OLN Cc=A0: Eric McMurry; THIEBAUT, LAURENT (LAURENT); dime@ietf.org Objet=A0: Re: [Dime] Dime: Diameter Overload IETF requirements, review On Dec 7, 2012, at 9:24 AM, lionel.morand@orange.com wrote: >> [em] One solution uses existing messages as a carrier, piggybacking on t= hem. This can be done by an implementation without any change in the speci= fication of the messages that are being used.=20=20 >>=20 >> [LM] It is exactly the issue for me! :) I think that you want to say tha= t existing commands can be extended with changing the CCF specification and= it is true. The application (and its related specification/documentation) = using this command will change! And it is what I highlight in my comment an= d in the proposed change. >=20 > I'm not sure what you mean by the application changing in the piggyback c= ase. Assuming the application specification uses the * [ AVP ] construct, a= n _implementation_ can add the OC AVPs without a change in the specificatio= n of specification. Yes, the implementation changes, but the spec doesn't h= ave to. Given, there might be benefit to updating the spec, particularly if= you want to describe application-specific behaviors rather than accepting = the base behavior. But that's not a _requirement_, right? >=20 > What are we missing? >=20 > [LM] it is not the application specification that "uses the *[AVP]" but t= he CCF specification of a given command. And an application is not only def= ined by the command code format specifications. Set of AVP, error codes and= so on are also part of the application. So adding new AVP to existing appl= ication IS a change of the application and related application specificatio= n, even if this addition is compliant with the CCF specification of the giv= en command. You will have to describe at least that these new AVPs have to = be carried in a specific set of commands when considering existing applicat= ions. I think that it the use of "specification" that causes problems here.= And it is why I've proposed the change in REQ2. I see your point, but the goal of that language was that you don't necessar= ily have to do that. For example, lets assume you have a spec for applicati= on "Foo" that defines a set commands, AVPs (including *[AVP] ), and their s= emantics. You also have a spec for piggybacked overload control, that defin= es additional AVPs that can be added to any message, their semantics, and a= t least one basic overload control algorithm. (I'm using piggybacked for th= e sake of argument here, since I think we agree that the issues are differe= nt if we have a separate OC application) If all an implementer wants to use is the the basic OC algorithm, they mere= ly implement both specs, adding the OC AVPs (as completely specified in the= OC mechanism spec) to the Foo commands. You don't have to have a revised F= oo spec to use the OC spec. It's analogous to a "mix in" pattern, if you wi= ll. That being said, there may be real benefits to updating the Foo spec. For e= xample, Foo might need an algorithm other than the base one. Or maybe it ne= eds to define how to prioritize requests in overload conditions. Maybe Foo = is a 3GPP spec, and they want to _require_ OC. The idea is, you don't have to go back and do a mass update of every applic= ation to make OC useful. You can do it over time, as needed. [LM] I agree in the principle! But again, I'm not speaking about documentat= ion issue. About a dedicated new application for OC, there is no impact on = application. However, to support OC specific AVPs over existing FOO command= s, any application using these FOO commands will be enhanced, right? Of cou= rse, the requirement is that this enhancement should not cause backward com= patible issues with existing implementation. After, how and when introduce = this upgrade in the existing nodes is only an operational issue. If you can= ensure that the changes required to support OC do not cause the creation o= f a new application (cf. section 1.3 of RFC 6733), you are in the safe side= . And I'm not saying anything else by "Support of this mechanism over exist= ing Diameter applications MUST NOT require major changes that would lead to= the need to define a new Diameter application." If this requirement is ful= filled, you don't have to upgrade at the same time all the Diameter peers (= client, server, proxy) supporting the existing application. About documenting how to support OC over existing applications, you can do = it in different ways: companion document, update of the existing specificat= ion, etc. But it is not something that matters here. Cheers. Lionel ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From tom.taylor.stds@gmail.com Fri Dec 7 19:16:56 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF36221F8564 for ; Fri, 7 Dec 2012 19:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TvWyjrqeUQi for ; Fri, 7 Dec 2012 19:16:56 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 610AF21F8563 for ; Fri, 7 Dec 2012 19:16:51 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so2091222iaz.31 for ; Fri, 07 Dec 2012 19:16:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=IOj83RntXYGtOFYaNj89H01PP6xa77ALI/2Mb/sq9aw=; b=j7K4dM5cHMaxZ8EvgeNrwaUS0MHr/zAE6mPLn+6ieDDSihYjj8L32m+oYVdbZVTZgD SaIUHqQdM/Aj8U1DndY3xS/NtzAhrAB+d4oQc8veFMmBTpxczZ+IMv8OZ67wewSR6eFY gawV9NJ3eB7FuMY3fbWH96qhJfCAJqksrdMoG0CGjRyllhSCOZ5OVKkokYJLnC+RpKpj AHtaD5DZ7537MhMKDTmn/egQCbfyv942W9T0a9RGw2nAfYTQzX+NoylV0QnXPd2Fq1nz 9zri/nLw7UE6y/EBmUheyNi1fdDFYH49H4RGoOz1FWa6yMzGAPumX0Pb+8gFMAxd8mVf JN1w== Received: by 10.42.51.142 with SMTP id e14mr6253457icg.2.1354936610795; Fri, 07 Dec 2012 19:16:50 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-24-193.tor.primus.ca. [173.206.24.193]) by mx.google.com with ESMTPS id ez8sm642104igb.17.2012.12.07.19.16.48 (version=SSLv3 cipher=OTHER); Fri, 07 Dec 2012 19:16:49 -0800 (PST) Message-ID: <50C2B121.6010508@gmail.com> Date: Fri, 07 Dec 2012 22:16:49 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: lionel.morand@orange.com References: <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> <28892_1354818749_50C0E4BD_28892_4479_1_6B7134B31289DC4FAF731D844122B36E0BF868@PEXCVZYM13.corporate.adroot.infra.ftgroup> <81E2AD4F-9FED-498D-ACA2-538C6ED53B7E@computer.org> <13633_1354873372_50C1BA1C_13633_2361_1_6B7134B31289DC4FAF731D844122B36E0C0056@PEXCVZYM13.corporate.adroot.infra.ftgroup> <724F2D49-4B1F-416D-BF94-F46C3DDC02EF@nostrum.com> <16364_1354893872_50C20A30_16364_5192_1_6B7134B31289DC4FAF731D844122B36E0C0699@PEXCVZYM13.corporate.adroot.infra.ftgroup> <18AC9DCE-8C27-43AB-AE3E-CBB913A471A7@nostrum.com> <5614_1354897191_50C21727_5614_8583_1_6B7134B31289DC4FAF731D844122B36E0C0756@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <5614_1354897191_50C21727_5614_8583_1_6B7134B31289DC4FAF731D844122B36E0C0756@PEXCVZYM13.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 121207-1, 07/12/2012), Outbound message X-Antivirus-Status: Clean Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 03:16:56 -0000 Ben, I think the problem is that a Diameter implementation can be thought of as a base part and an application-specific part. A message comes in, gets processed by the Diameter base part, then the application is passed the type of message and the parts not consumed by base. So some extra information is tacked on in that optional AVP part. Either the base recognizes it and deals with it, or the application does. If the application is to handle it, the application has to expect it -- that is, the specification of the application includes the additional data. On 07/12/2012 11:19 AM, lionel.morand@orange.com wrote: > > > -----Message d'origine----- De : Ben Campbell > [mailto:ben@nostrum.com] Envoyé : vendredi 7 décembre 2012 16:47 À : > MORAND Lionel OLNC/OLN Cc : Eric McMurry; THIEBAUT, LAURENT > (LAURENT); dime@ietf.org Objet : Re: [Dime] Dime: Diameter Overload > IETF requirements, review > > > On Dec 7, 2012, at 9:24 AM, lionel.morand@orange.com wrote: > >>> [em] One solution uses existing messages as a carrier, >>> piggybacking on them. This can be done by an implementation >>> without any change in the specification of the messages that are >>> being used. >>> >>> [LM] It is exactly the issue for me! :) I think that you want to >>> say that existing commands can be extended with changing the CCF >>> specification and it is true. The application (and its related >>> specification/documentation) using this command will change! And >>> it is what I highlight in my comment and in the proposed change. >> ... From laurent.thiebaut@alcatel-lucent.com Sun Dec 9 13:05:43 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999E721F8CE7 for ; Sun, 9 Dec 2012 13:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6PKZ0FG2HMM for ; Sun, 9 Dec 2012 13:05:41 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9881F21F8CDF for ; Sun, 9 Dec 2012 13:05:40 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qB9L5baM022457 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 9 Dec 2012 22:05:37 +0100 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sun, 9 Dec 2012 22:05:37 +0100 From: "THIEBAUT, LAURENT (LAURENT)" To: Tom Taylor , "lionel.morand@orange.com" Date: Sun, 9 Dec 2012 22:02:48 +0100 Thread-Topic: [Dime] Dime: Diameter Overload IETF requirements, review Thread-Index: Ac3U8n67n4OFOtW9RdS6hnAZWJHNJABWpcfA Message-ID: <170E8FCC2134BD42B539B47798ABF8F026C0C43F5B@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> References: <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> <28892_1354818749_50C0E4BD_28892_4479_1_6B7134B31289DC4FAF731D844122B36E0BF868@PEXCVZYM13.corporate.adroot.infra.ftgroup> <81E2AD4F-9FED-498D-ACA2-538C6ED53B7E@computer.org> <13633_1354873372_50C1BA1C_13633_2361_1_6B7134B31289DC4FAF731D844122B36E0C0056@PEXCVZYM13.corporate.adroot.infra.ftgroup> <724F2D49-4B1F-416D-BF94-F46C3DDC02EF@nostrum.com> <16364_1354893872_50C20A30_16364_5192_1_6B7134B31289DC4FAF731D844122B36E0C0699@PEXCVZYM13.corporate.adroot.infra.ftgroup> <18AC9DCE-8C27-43AB-AE3E-CBB913A471A7@nostrum.com> <5614_1354897191_50C21727_5614_8583_1_6B7134B31289DC4FAF731D844122B36E0C0756@PEXCVZYM13.corporate.adroot.infra.ftgroup> <50C2B121.6010508@gmail.com> In-Reply-To: <50C2B121.6010508@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_170E8FCC2134BD42B539B47798ABF8F026C0C43F5BFRMRSSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 21:05:43 -0000 --_000_170E8FCC2134BD42B539B47798ABF8F026C0C43F5BFRMRSSXCHMBSA_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all I'd like to highlight the comment from Tom that touches the topic we wanted= to address via our (unfortunate as it raised (too) much discussion) commen= t on REQ 2 Let's Consider a Diameter end point SW is split up into 2 parts: =B7 a base Diameter stack =B7 an application SW Even though the application *protocol* is NOT touched by Diameter overload = (thanks to * [AVP]), it seems questionable that only the base Diameter stac= k would handle the changes due to the Diameter overload control we are defi= ning (and that thus the application SW would be untouched). Said otherwise = something will have to change in the Behaviour of the source application. One of the reasons is that only the application knows the relative priority= of the various procedures and of the various users: e.g. taking the 3GPP S= 6a as an example (=3D MME as a kind of authenticator accessing the subscrib= er database i.e. the HSS), only the MME SW (as opposed to the Diameter stac= k or diameter agent en route between the S6a client and server) knows that o an Update location is of higher priority than a Purge o User Lionel is a high priority user while user Laurent is low tier= user o a request is associated with an emergency o etc... So the application behaviour/SW is likely to be changed May be a solution is to change second part of the REQ2 into "It MUST NOT re= quire protocol specification changes for existing Diameter applications" (h= inting that a behaviour change is possible) Best regards Laurent ALCATEL-LUCENT Disclaimer: this mail is not meant to promote any of the 2 solutions on the= table. It is JUST about requirements. -----Message d'origine----- De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Tom= Taylor Envoy=E9 : samedi 8 d=E9cembre 2012 04:17 =C0 : lionel.morand@orange.com Cc : dime@ietf.org Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review Ben, I think the problem is that a Diameter implementation can be thought of as a base part and an application-specific part. A message comes in, gets processed by the Diameter base part, then the application is passed the type of message and the parts not consumed by base. So some extra information is tacked on in that optional AVP part. Either the base recognizes it and deals with it, or the application does. If the application is to handle it, the application has to expect it -- that is, the specification of the application includes the additional data. On 07/12/2012 11:19 AM, lionel.morand@orange.com wrote: > > > -----Message d'origine----- De : Ben Campbell > [mailto:ben@nostrum.com] Envoy=E9 : vendredi 7 d=E9cembre 2012 16:47 =C0 = : > MORAND Lionel OLNC/OLN Cc : Eric McMurry; THIEBAUT, LAURENT > (LAURENT); dime@ietf.org Objet : Re: [Dime] Dime: Diameter Overload > IETF requirements, review > > > On Dec 7, 2012, at 9:24 AM, lionel.morand@orange.com wrote: > >>> [em] One solution uses existing messages as a carrier, >>> piggybacking on them. This can be done by an implementation >>> without any change in the specification of the messages that are >>> being used. >>> >>> [LM] It is exactly the issue for me! :) I think that you want to >>> say that existing commands can be extended with changing the CCF >>> specification and it is true. The application (and its related >>> specification/documentation) using this command will change! And >>> it is what I highlight in my comment and in the proposed change. >> ... _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_170E8FCC2134BD42B539B47798ABF8F026C0C43F5BFRMRSSXCHMBSA_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

     

     

    Hello all

    I'd like to highlight the comment from Tom that touches the topic we wanted to address via our (unfortunate as it raised (t= oo) much discussion) comment on REQ 2

     

    Let’s Consider a Diameter end point SW is = split up into 2 parts:

    =B7         a base Diam= eter stack

    =B7         an applicat= ion SW

    Even though the application *protocol* is NOT touched by Diameter overload (thanks to * [AVP]), it seems questionable that only the base Diam= eter stack would handle the changes due to the Diameter overload control we are defining (and that thus the application SW would be untouched). Said otherw= ise something will have to change in the Behaviour of the source application.

     

    One of the reasons is that only the application = knows the relative priority of the various procedures and of the various users: e= .g. taking the 3GPP S6a as an example (=3D MME as a kind of authenticator accessing th= e subscriber database i.e. the HSS), only the MME SW (as opposed to the Diame= ter stack or diameter agent en route between the S6a client and server) knows t= hat

    o        an Update l= ocation is of higher priority than a Purge

    o        User Lionel= is a high priority user while user Laurent is low tier user

    o        a request i= s associated with an emergency

    o        etc…<= o:p>

     

    So the application behaviour/SW is likely to be changed

     

    May be a solution is to change second part of th= e REQ2 into "It MUST NOT require protocol specification changes for existing Diameter applications" (hinting that a behaviour change is possible)

    Best regards

    Laurent

    ALCATEL-LUCENT

     

    Disclaimer: this mail is not meant = to promote any of the 2 solutions on the table. It is JUST about requirements.=

     

    -----Message d'origine-----
    De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part d= e Tom Taylor
    Envoy=E9 : samedi 8 d=E9cembre 2012 04:17
    =C0 : lionel.morand@orange.com
    Cc : dime@ietf.org
    Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review

     

    Ben, I think the problem is that a Diameter implementation can be

    thought of as a base part and an application-spe= cific part. A message

    comes in, gets processed by the Diameter base pa= rt, then the application

    is passed the type of message and the parts not consumed by base. So

    some extra information is tacked on in that opti= onal AVP part. Either

    the base recognizes it and deals with it, or the application does. If

    the application is to handle it, the application= has to expect it --

    that is, the specification of the application in= cludes the additional data.

     

    On 07/12/2012 11:19 AM, lionel.morand@orange.com wrote:

    > 

    > 

    > -----Message d'origine----- De : Ben Campbe= ll

    > [mailto:ben@nostrum.com] Envoy=E9 : vendred= i 7 d=E9cembre 2012 16:47 =C0 :

    > MORAND Lionel OLNC/OLN Cc : Eric McMurry; THIEBAUT, LAURENT

    > (LAURENT); dime@ietf.org Objet : Re: [Dime]= Dime: Diameter Overload

    > IETF requirements, review=

    > 

    > 

    > On Dec 7, 2012, at 9:24 AM, lionel.morand@orange.com wrote:

    > 

    >>> [em] One solution uses existing mes= sages as a carrier,

    >>> piggybacking on them.=A0 This can b= e done by an implementation

    >>> without any change in the specifica= tion of the messages that are

    >>> being used.

    >>> 

    >>> [LM] It is exactly the issue for me= ! :) I think that you want to

    >>> say that existing commands can be extended with changing the CCF

    >>> specification and it is true. The application (and its related

    >>> specification/documentation) using = this command will change! And

    >>> it is what I highlight in my commen= t and in the proposed change.

    >> 

    ...

    _______________________________________________<= o:p>

    DiME mailing list

    DiME@ietf.org

    https://www.ietf.org/mailman/listinfo/dime<= /o:p>

    --_000_170E8FCC2134BD42B539B47798ABF8F026C0C43F5BFRMRSSXCHMBSA_-- From ben@nostrum.com Sun Dec 9 19:32:20 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F2621F859C for ; Sun, 9 Dec 2012 19:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJG7g9paO1y8 for ; Sun, 9 Dec 2012 19:32:13 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id EAA9B21F8D49 for ; Sun, 9 Dec 2012 19:32:12 -0800 (PST) Received: from [10.0.1.14] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qBA3Vwq3049947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 9 Dec 2012 21:31:59 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <170E8FCC2134BD42B539B47798ABF8F026C0C43F5B@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> Date: Sun, 9 Dec 2012 21:32:03 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9A881352-53FA-4ED4-98E9-04D0CE8AAB77@nostrum.com> References: <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> <28892_1354818749_50C0E4BD_28892_4479_1_6B7134B31289DC4FAF731D844122B36E0BF868@PEXCVZYM13.corporate.adroot.infra.ftgroup> <81E2AD4F-9FED-498D-ACA2-538C6ED53B7E@computer.org> <13633_1354873372_50C1BA1C_13633_2361_1_6B7134B31289DC4FAF731D844122B36E0C0056@PEXCVZYM13.corporate.adroot.infra.ftgroup> <724F2D49-4B1F-416D-BF94-F46C3DDC02EF@nostrum.com> <16364_1354893872_50C20A30_16364_5192_1_6B7134B31289DC4FAF731D844122B36E0C0699@PEXCVZYM13.corporate.adroot.infra.ftgroup> <18AC9DCE-8C27-43AB-AE3E-CBB913A471A7@nostrum.com> <5614_1354897191_50C21727_5614_8583_1_6B7134B31289DC4FAF731D844122B36E0C0756@PEXCVZYM13.corporate.adroot.infra.ftgroup> <50C2B121.6010508@gmail.com>! <170E8FCC2134BD42B539B47798ABF8F026C0C43F5B@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> To: "THIEBAUT, LAURENT (LAURENT)" X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 03:32:20 -0000 Hi, I think we've got some confusion on the point of the requirement. Tom is = correct that many Diameter implementations decompose things in that = particular way. But the requirement is not about stack architecture, = it's about protocol documentation. I don't think any of us expect that = you can take advantage of a new OC mechanism without making changes to = _software_. The point is, you can make those changes to _software_ without waiting = for whatever spec defines the application to be revised. That may not be = important to all implementors, but, for example, lets say you are = implementing some of the 3GPP interfaces. You can implement and = negotiate _basic_ OC without waiting for the next 3GPP release to revise = the specs. On Dec 9, 2012, at 3:02 PM, "THIEBAUT, LAURENT (LAURENT)" = wrote: > =20 > =20 > Hello all > I'd like to highlight the comment from Tom that touches the topic we = wanted to address via our (unfortunate as it raised (too) much = discussion) comment on REQ 2 > =20 > Let=92s Consider a Diameter end point SW is split up into 2 parts: > =B7 a base Diameter stack > =B7 an application SW > Even though the application *protocol* is NOT touched by Diameter = overload (thanks to * [AVP]), it seems questionable that only the base = Diameter stack would handle the changes due to the Diameter overload = control we are defining (and that thus the application SW would be = untouched). Said otherwise something will have to change in the = Behaviour of the source application. > =20 > One of the reasons is that only the application knows the relative = priority of the various procedures and of the various users: e.g. taking = the 3GPP S6a as an example (=3D MME as a kind of authenticator accessing = the subscriber database i.e. the HSS), only the MME SW (as opposed to = the Diameter stack or diameter agent en route between the S6a client and = server) knows that > o an Update location is of higher priority than a Purge > o User Lionel is a high priority user while user Laurent is low = tier user > o a request is associated with an emergency > o etc=85 > =20 > So the application behaviour/SW is likely to be changed > =20 > May be a solution is to change second part of the REQ2 into "It MUST = NOT require protocol specification changes for existing Diameter = applications" (hinting that a behaviour change is possible) > Best regards > Laurent > ALCATEL-LUCENT > =20 > Disclaimer: this mail is not meant to promote any of the 2 solutions = on the table. It is JUST about requirements. > =20 > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Tom Taylor > Envoy=E9 : samedi 8 d=E9cembre 2012 04:17 > =C0 : lionel.morand@orange.com > Cc : dime@ietf.org > Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review > =20 > Ben, I think the problem is that a Diameter implementation can be > thought of as a base part and an application-specific part. A message > comes in, gets processed by the Diameter base part, then the = application > is passed the type of message and the parts not consumed by base. So > some extra information is tacked on in that optional AVP part. Either > the base recognizes it and deals with it, or the application does. If > the application is to handle it, the application has to expect it -- > that is, the specification of the application includes the additional = data. > =20 > On 07/12/2012 11:19 AM, lionel.morand@orange.com wrote: > >=20 > >=20 > > -----Message d'origine----- De : Ben Campbell > > [mailto:ben@nostrum.com] Envoy=E9 : vendredi 7 d=E9cembre 2012 16:47 = =C0 : > > MORAND Lionel OLNC/OLN Cc : Eric McMurry; THIEBAUT, LAURENT > > (LAURENT); dime@ietf.org Objet : Re: [Dime] Dime: Diameter Overload > > IETF requirements, review > >=20 > >=20 > > On Dec 7, 2012, at 9:24 AM, lionel.morand@orange.com wrote: > >=20 > >>> [em] One solution uses existing messages as a carrier, > >>> piggybacking on them. This can be done by an implementation > >>> without any change in the specification of the messages that are > >>> being used. > >>>=20 > >>> [LM] It is exactly the issue for me! :) I think that you want to > >>> say that existing commands can be extended with changing the CCF > >>> specification and it is true. The application (and its related > >>> specification/documentation) using this command will change! And > >>> it is what I highlight in my comment and in the proposed change. > >>=20 > ... > _______________________________________________ > 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 From emcmurry@computer.org Sun Dec 9 19:54:52 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71A821F8DDB for ; Sun, 9 Dec 2012 19:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+68wuuNQKxa for ; Sun, 9 Dec 2012 19:54:51 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3403A21F8DB5 for ; Sun, 9 Dec 2012 19:54:47 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1ThuS5-000MFt-GK; Mon, 10 Dec 2012 03:54:45 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 9832AAFB4E6; Sun, 9 Dec 2012 21:54:43 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18xisQOqZcCx7Z6wzFymlH1av9uQhoAG0U= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMF3vTTu3fpj; Sun, 9 Dec 2012 21:54:43 -0600 (CST) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 46EC7AFB4D1; Sun, 9 Dec 2012 21:54:43 -0600 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E13518E0-502D-4A6E-87AA-2EA2F37D76B4" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric McMurry In-Reply-To: <170E8FCC2134BD42B539B47798ABF8F026C0C43F5B@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> Date: Sun, 9 Dec 2012 21:54:42 -0600 Message-Id: <14A53213-81F4-49B3-B7A2-62604921FD1F@computer.org> References: <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> <28892_1354818749_50C0E4BD_28892_4479_1_6B7134B31289DC4FAF731D844122B36E0BF868@PEXCVZYM13.corporate.adroot.infra.ftgroup> <81E2AD4F-9FED-498D-ACA2-538C6ED53B7E@computer.org> <13633_1354873372_50C1BA1C_13633_2361_1_6B7134B31289DC4FAF731D844122B36E0C0056@PEXCVZYM13.corporate.adroot.infra.ftgroup> <724F2D49-4B1F-416D-BF94-F46C3DDC02EF@nostrum.com> <16364_1354893872_50C20A30_16364_5192_1_6B7134B31289DC4FAF731D844122B36E0C0699@PEXCVZYM13.corporate.adroot.infra.ftgroup> <18AC9DCE-8C27-43AB-AE3E-CBB913A471A7@nostrum.com> <5614_1354897191_50C21727_5614_8583_1_6B7134B31289DC4FAF731D844122B36E0C0756@PEXCVZYM13.corporate.adroot.infra.ftgroup> <50C2B121.6010508@gmail.com> <170E8FC C2134BD42B539B47798ABF8F026C0C43F5B@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> To: "THIEBAUT, LAURENT (LAURENT)" X-Mailer: Apple Mail (2.1499) Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 03:54:53 -0000 --Apple-Mail=_E13518E0-502D-4A6E-87AA-2EA2F37D76B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for clarifying your thoughts Laurent. I think we're all on the same page that some changes are likely to = happen to support overload control in the application specifications and = that this is the right level to consider priorities and other = application specific behaviors. Where we seem to be getting wrapped up = though is whether those changes will be required to use an overload = control mechanism. I agree changes at the application specifications = are a good idea, but I do not think they are required for basic = operation of an overload control mechanism. I don't see why a mechanism = (including the two proposals) could not be used without any changes to = application specifications. In your example with an end point implemented as a stack and and = application layer, handling of an overload control protocol could be = done in either place. Decisions about what to do would make sense at = the application level, but the implementation could do that in an = interoperable fashion without needing a new specification, for protocol = or behavior, with, for example, a drop or throttle algorithm that made = no consideration of priority. I think it is important for the design of an overload control mechanism = to support operation without application specification changes. It will = allow some overload control to be implemented even before application = specifications are updated. It will also ensure that the mechanism can = be used for application specifications that will not be, or do not need = to be, updated. Having a basic overload control mechanism in place will = be an improvement over current conditions. We can then further improve = this, by updating application specifications, to cover cases like those = you mention for S6a. Thanks, Eric On Dec 9, 2012, at 15:02 , "THIEBAUT, LAURENT (LAURENT)" = wrote: > =20 > =20 > Hello all > I'd like to highlight the comment from Tom that touches the topic we = wanted to address via our (unfortunate as it raised (too) much = discussion) comment on REQ 2 > =20 > Let=92s Consider a Diameter end point SW is split up into 2 parts: > =B7 a base Diameter stack > =B7 an application SW > Even though the application *protocol* is NOT touched by Diameter = overload (thanks to * [AVP]), it seems questionable that only the base = Diameter stack would handle the changes due to the Diameter overload = control we are defining (and that thus the application SW would be = untouched). Said otherwise something will have to change in the = Behaviour of the source application. > =20 > One of the reasons is that only the application knows the relative = priority of the various procedures and of the various users: e.g. taking = the 3GPP S6a as an example (=3D MME as a kind of authenticator accessing = the subscriber database i.e. the HSS), only the MME SW (as opposed to = the Diameter stack or diameter agent en route between the S6a client and = server) knows that > o an Update location is of higher priority than a Purge > o User Lionel is a high priority user while user Laurent is low = tier user > o a request is associated with an emergency > o etc=85 > =20 > So the application behaviour/SW is likely to be changed > =20 > May be a solution is to change second part of the REQ2 into "It MUST = NOT require protocol specification changes for existing Diameter = applications" (hinting that a behaviour change is possible) > Best regards > Laurent > ALCATEL-LUCENT > =20 > Disclaimer: this mail is not meant to promote any of the 2 solutions = on the table. It is JUST about requirements. > =20 > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Tom Taylor > Envoy=E9 : samedi 8 d=E9cembre 2012 04:17 > =C0 : lionel.morand@orange.com > Cc : dime@ietf.org > Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review > =20 > Ben, I think the problem is that a Diameter implementation can be > thought of as a base part and an application-specific part. A message > comes in, gets processed by the Diameter base part, then the = application > is passed the type of message and the parts not consumed by base. So > some extra information is tacked on in that optional AVP part. Either > the base recognizes it and deals with it, or the application does. If > the application is to handle it, the application has to expect it -- > that is, the specification of the application includes the additional = data. > =20 > On 07/12/2012 11:19 AM, lionel.morand@orange.com wrote: > >=20 > >=20 > > -----Message d'origine----- De : Ben Campbell > > [mailto:ben@nostrum.com] Envoy=E9 : vendredi 7 d=E9cembre 2012 16:47 = =C0 : > > MORAND Lionel OLNC/OLN Cc : Eric McMurry; THIEBAUT, LAURENT > > (LAURENT); dime@ietf.org Objet : Re: [Dime] Dime: Diameter Overload > > IETF requirements, review > >=20 > >=20 > > On Dec 7, 2012, at 9:24 AM, lionel.morand@orange.com wrote: > >=20 > >>> [em] One solution uses existing messages as a carrier, > >>> piggybacking on them. This can be done by an implementation > >>> without any change in the specification of the messages that are > >>> being used. > >>>=20 > >>> [LM] It is exactly the issue for me! :) I think that you want to > >>> say that existing commands can be extended with changing the CCF > >>> specification and it is true. The application (and its related > >>> specification/documentation) using this command will change! And > >>> it is what I highlight in my comment and in the proposed change. > >>=20 > ... > _______________________________________________ > 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 --Apple-Mail=_E13518E0-502D-4A6E-87AA-2EA2F37D76B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 laurent.thiebaut@ALCAT= EL-LUCENT.COM> wrote:
     
    Hello = all
    =B7 <= /font>a base Diameter = stack
    =B7 <= /font>an application SW
    Even though the application = *protocol* is NOT = touched by Diameter overload (thanks to * [AVP]), it seems questionable = that only the base Diameter stack would handle the changes due to the = Diameter overload control we are defining (and that thus the application = SW would be untouched). Said otherwise something will have to change in = the Behaviour of the source = application.
    o <= /font>an Update location is of higher priority than = a Purge
    o        <= /font>User Lionel is a high priority user while = user Laurent is low tier user
    o <= /font>a request is associated with an = emergency
    o        <= /font>etc=85
    So = the application behaviour/SW is likely to be = changed
    Laurent
    ALCATEL-LUCENT
     
    Disclaimer: this mail is not = meant to promote any of the 2 solutions on the table. It is JUST about = requirements.
     
    -----Message = d'origine-----
    De : dime-bounces@ietf.org = [mailto:dime-bounces@ietf.org] = De la part de Tom Taylor
    Envoy=E9 : samedi 8 d=E9cembre 2012 = 04:17
    =C0 : lionel.morand@orange.com
    C= c : dime@ietf.org
    Objet : Re: = [Dime] Dime: Diameter Overload IETF requirements, = review
    is = passed the type of message and the parts not consumed by base. = So
    On = 07/12/2012 11:19 AM, lionel.morand@orange.com = wrote:
    nostrum.com] = Envoy=E9 : vendredi 7 d=E9cembre 2012 16:47 =C0 = :
    dime@ietf.org = Objet : Re: [Dime] Dime: Diameter = Overload
    lionel.morand@orange.com = wrote:
    >>> without any change in the specification of the = messages that are
    >>> being used.
    >>> [LM] It is exactly the issue for me! :) I think = that you want to
    >>> say that existing commands can be extended with = changing the CCF
    >>> specification and it is true. The application (and = its related
    ...
    DiME mailing = list
    _____________= __________________________________
    DiME mailing list
    DiME@ietf.org
    Date: Mon, 10 Dec 2012 01:10:21 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-erp-15.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 09:10:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Diameter Support for the EAP Re-authentication Protocol = (ERP) Author(s) : Julien Bournelle Lionel Morand Sebastien Decugis Qin Wu Glen Zorn Filename : draft-ietf-dime-erp-15.txt Pages : 16 Date : 2012-12-10 Abstract: The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-erp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-erp-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-erp-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jean-jacques.trottin@alcatel-lucent.com Mon Dec 10 12:00:32 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A0F21F865D for ; Mon, 10 Dec 2012 12:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJ9VosTxhGJK for ; Mon, 10 Dec 2012 12:00:24 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE3621F867D for ; Mon, 10 Dec 2012 12:00:20 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBAJxnX0025175 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 10 Dec 2012 21:00:15 +0100 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 10 Dec 2012 21:00:14 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Date: Mon, 10 Dec 2012 21:00:11 +0100 Thread-Topic: [Dime] Dime: Diameter Overload IETF requirements, review Thread-Index: Ac3WiiC1gu8pDCj/Q+Kaw26KHsPx/QAhncsQ Message-ID: References: <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> <28892_1354818749_50C0E4BD_28892_4479_1_6B7134B31289DC4FAF731D844122B36E0BF868@PEXCVZYM13.corporate.adroot.infra.ftgroup> <81E2AD4F-9FED-498D-ACA2-538C6ED53B7E@computer.org> <13633_1354873372_50C1BA1C_13633_2361_1_6B7134B31289DC4FAF731D844122B36E0C0056@PEXCVZYM13.corporate.adroot.infra.ftgroup> <724F2D49-4B1F-416D-BF94-F46C3DDC02EF@nostrum.com> <16364_1354893872_50C20A30_16364_5192_1_6B7134B31289DC4FAF731D844122B36E0C0699@PEXCVZYM13.corporate.adroot.infra.ftgroup> <18AC9DCE-8C27-43AB-AE3E-CBB913A471A7@nostrum.com> <5614_1354897191_50C21727_5614_8583_1_6B7134B31289DC4FAF731D844122B36E0C0756@PEXCVZYM13.corporate.adroot.infra.ftgroup> <50C2B121.6010508@gmail.com> <170E8FC C2134BD42B539B47798ABF8F026C0C43F5B@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <14A53213-81F4-49B3-B7A2-62604921FD1F@computer.org> In-Reply-To: <14A53213-81F4-49B3-B7A2-62604921FD1F@computer.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_C472E6A4C17FA14E90533C0369A4798B20EB4C16DBFRMRSSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 20:00:32 -0000 --_000_C472E6A4C17FA14E90533C0369A4798B20EB4C16DBFRMRSSXCHMBSA_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all About this long discussion on REQ2, I hereafter give some additional commen= ts 1) Regarding Lionel's remark, the fact to add related overload AVPs t= o existing commands of a given Diameter application means these AVPs are no= w part of the Diameter application which should deal with them, so impactin= g the application. On another side, in REQ13, piggybacking is mentioned as an example of a sol= ution for this REQ13 . With piggybacking, the message is only used as tra= nsporter of the related overload AVPs. As messages from different Diamete= r applications may be transferred over the same connection, from my unders= tanding, we may have a solution where the overload AVPs are transported in= any message of any application and relate or are specific to the same Diam= eter application as the message one or to another application or be applica= tion independent. Here can we say these transported AVPs are sometimes pa= rt of the Diameter Application and sometimes no? Although this is a solution level discussion, it directly relates to the RE= Q2 sentence: "It MUST NOT require specification changes for existing Diamet= er applications". I am rather in favor of Lionel's remark and on the text he proposes. When a= n AVP is conveyed in a command of an application, it is part of this Diamet= er application. The same AVPs may be used by different Diameter application= s. Then it is a matter of implementation: these overload AVPS or some of t= hem may be processed by a separate application-independent function in a no= de, so to minimize impact on existing applications, but it is implementati= on. 2) In Req1 it is stated that the overload mechanism objective is "to p= rovide a communication method ...to exchange the overload information", so = no more , no less from my understanding. Then there are requirements on th= e Diameter node behaviors. I have no issue with the many REQs for managin= g and optimizing well this information exchange (eg REQ 9, 13, 14, 19...) b= y nodes . It is another topic on how the exchanged information is then used= by nodes. I am also OK with the REQs starting with "the mechanism MUST all= ow nodes to ... (REQ7) , "...MUST provide a way to (REQ 22)' as we are stil= l speaking of the exchanged information which allows nodes to... . I thin= k we should also use this type of wording for a few requirements eg for RE= Q 7 "the mechanism must ensure that the system remains stable" as it is = not the exchanged information which stabilize the system, but the nodes be= havior on the basis of information exchanges. 3) This document does not address any overload algorithm which will be= key on how the exchanged information is then used by nodes. From a 3GPP = angle, the approach ALU foresees is to use the Dime method to exchange the = overload information, eventually by extending the information exchanged (RE= Q 33, 34), and to specify nodes behaviors about overload handling accordi= ng to the Diameter application (corresponding to a 3GPP interface) and the = overload algorithm. Eric's mail mentions a basic operation of an overload control mechanism, wh= ich should correspond to an overload algorithm. Has Dime the intent to spec= ify some general overload algorithms? 4) I remind the question of priority given to some users that 3GPP wi= ll have to handle. Generally, it is the client that should manages such pr= iorities and signals it to the server but the intermediate Diameter agents = are not neutral there and should have the relevant information to behave co= rrectly (eg to not drop a message for a priority user). On Req 26 ,we propo= sed an additional wording "" For example, it may be more beneficial to pro= cess messages for existing sessions ahead of new sessions and to give prior= ity to requests associated with emergency sessions or with high priority us= ers". Do you think it is sufficient, or should we have a normative statemen= t (not only an example)? Best regards JJacques From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Eri= c McMurry Sent: lundi 10 d=E9cembre 2012 04:55 To: THIEBAUT, LAURENT (LAURENT) Cc: dime@ietf.org Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review Thanks for clarifying your thoughts Laurent. I think we're all on the same page that some changes are likely to happen t= o support overload control in the application specifications and that this = is the right level to consider priorities and other application specific be= haviors. Where we seem to be getting wrapped up though is whether those ch= anges will be required to use an overload control mechanism. I agree chang= es at the application specifications are a good idea, but I do not think th= ey are required for basic operation of an overload control mechanism. I do= n't see why a mechanism (including the two proposals) could not be used wit= hout any changes to application specifications. In your example with an end point implemented as a stack and and applicatio= n layer, handling of an overload control protocol could be done in either p= lace. Decisions about what to do would make sense at the application level= , but the implementation could do that in an interoperable fashion without= needing a new specification, for protocol or behavior, with, for example, = a drop or throttle algorithm that made no consideration of priority. I think it is important for the design of an overload control mechanism to = support operation without application specification changes. It will allow= some overload control to be implemented even before application specificat= ions are updated. It will also ensure that the mechanism can be used for a= pplication specifications that will not be, or do not need to be, updated. = Having a basic overload control mechanism in place will be an improvement = over current conditions. We can then further improve this, by updating app= lication specifications, to cover cases like those you mention for S6a. Thanks, Eric On Dec 9, 2012, at 15:02 , "THIEBAUT, LAURENT (LAURENT)" > wrote: Hello all I'd like to highlight the comment from Tom that touches the topic we wanted= to address via our (unfortunate as it raised (too) much discussion) commen= t on REQ 2 Let's Consider a Diameter end point SW is split up into 2 parts: * a base Diameter stack * an application SW Even though the application *protocol* is NOT touched by Diameter overload = (thanks to * [AVP]), it seems questionable that only the base Diameter stac= k would handle the changes due to the Diameter overload control we are defi= ning (and that thus the application SW would be untouched). Said otherwise = something will have to change in the Behaviour of the source application. One of the reasons is that only the application knows the relative priority= of the various procedures and of the various users: e.g. taking the 3GPP S= 6a as an example (=3D MME as a kind of authenticator accessing the subscrib= er database i.e. the HSS), only the MME SW (as opposed to the Diameter stac= k or diameter agent en route between the S6a client and server) knows that o an Update location is of higher priority than a Purge o User Lionel is a high priority user while user Laurent is low tier= user o a request is associated with an emergency o etc... So the application behaviour/SW is likely to be changed May be a solution is to change second part of the REQ2 into "It MUST NOT re= quire protocol specification changes for existing Diameter applications" (h= inting that a behaviour change is possible) Best regards Laurent ALCATEL-LUCENT Disclaimer: this mail is not meant to promote any of the 2 solutions on the= table. It is JUST about requirements. -----Message d'origine----- De : dime-bounces@ietf.org [mailto:dime-bounc= es@ietf.org] De la part de Tom Taylor Envoy=E9 : samedi 8 d=E9cembre 2012 04:17 =C0 : lionel.morand@orange.com Cc : dime@ietf.org Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review Ben, I think the problem is that a Diameter implementation can be thought of as a base part and an application-specific part. A message comes in, gets processed by the Diameter base part, then the application is passed the type of message and the parts not consumed by base. So some extra information is tacked on in that optional AVP part. Either the base recognizes it and deals with it, or the application does. If the application is to handle it, the application has to expect it -- that is, the specification of the application includes the additional data. On 07/12/2012 11:19 AM, lionel.morand@orange.com wrote: > > > -----Message d'origine----- De : Ben Campbell > [mailto:ben@nostrum.com] Envoy=E9 : vendredi 7 d=E9ce= mbre 2012 16:47 =C0 : > MORAND Lionel OLNC/OLN Cc : Eric McMurry; THIEBAUT, LAURENT > (LAURENT); dime@ietf.org Objet : Re: [Dime] Dime: D= iameter Overload > IETF requirements, review > > > On Dec 7, 2012, at 9:24 AM, lionel.morand@orange.com wrote: > >>> [em] One solution uses existing messages as a carrier, >>> piggybacking on them. This can be done by an implementation >>> without any change in the specification of the messages that are >>> being used. >>> >>> [LM] It is exactly the issue for me! :) I think that you want to >>> say that existing commands can be extended with changing the CCF >>> specification and it is true. The application (and its related >>> specification/documentation) using this command will change! And >>> it is what I highlight in my comment and in the proposed change. >> ... _______________________________________________ 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 --_000_C472E6A4C17FA14E90533C0369A4798B20EB4C16DBFRMRSSXCHMBSA_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Hi all

     

    About this= long discussion on REQ2, I hereafter give some additional comments =A0

     

    1)      Re= garding Lionel’s remark,  the fact to add related overload AVPs = to existing commands of a given Diameter application means these AVPs are n= ow part of the Diameter application which should deal with them, so impacti= ng the application.

     

    On another side, in R=
EQ13, piggybacking is mentioned as an example of a solution for this REQ13 =
. =A0With =A0piggybacking, the message is only used as transporter of the r=
elated overload AVPs.   As messages from different Diameter appli=
cations may be transferred over the same connection, =A0from my understandi=
ng, we may have a solution where =A0the overload AVPs are transported in an=
y message of any application and relate or are specific to the same Diamete=
r application as the message one or to another application or be applicatio=
n independent. Here =A0can we say these transported AVPs are sometimes =A0p=
art of the Diameter Application and sometimes no?
     
    <=
span lang=3DEN-US style=3D'font-family:"Calibri","sans-serif";color:#1F497D=
'>Although this is a solution level discussion, it directly relates to the =
REQ2 sentence: “It =
MUST NOT require specification changes for existing Diameter applications&#=
8221;.
    I am rather in favor of Lionel’s remark and on the t=
ext he proposes. When an AVP is conveyed in a command of an application, it=
 is part of this Diameter application. The same AVPs may be used by differe=
nt Diameter applications. Then it is a matter of implementation: these over=
load =A0AVPS or some of them may be processed by a separate application-ind=
ependent function in a node, so to minimize =A0impact on existing applicati=
ons, but it is implementation.
     

    2)      In Req1 it is stated that the overload mechanism objec= tive is “to provide a communication method …to exchange the ove= rload information”, so no more , no less from my understanding. =A0Th= en there are requirements on the Diameter node behaviors. I have =A0no issu= e with the many =A0REQs for managing and optimizing well this information e= xchange (eg REQ 9, 13, 14, 19…) by nodes . It is another topic on how= the exchanged information is then used by nodes. I am also OK with the REQ= s starting with “the mechanism MUST allow nodes to … (REQ7) , &= #8220;…MUST provide a way to (REQ 22)’ as we are still speaking= of the exchanged information=A0 which =A0allows nodes to… . I think = we should also use this type of wording for a few requirements =A0eg for RE= Q 7 =A0“the mechanism =A0must ensure =A0that the system remains stabl= e” as it is not the exchanged information =A0which stabilize the syst= em, but the nodes behavior on the basis of information exchanges.

     

    3)      This = document does not address any overload algorithm which will be key on how t= he exchanged information is then used by nodes. =A0=A0From a 3GPP angle, th= e approach ALU foresees is to use the Dime method to exchange the overload = information, eventually by extending the information exchanged (REQ 33, 34)= , =A0=A0and to specify nodes behaviors about overload handling according to= the Diameter application (corresponding to a 3GPP interface) and the overl= oad algorithm. =A0

    Eric’s mail mentions a basic operation of = an overload control mechanism, which should correspond to an overload algor= ithm. Has Dime the intent to specify some general overload algorithms?=

    <= span lang=3DEN-US style=3D'font-family:"Calibri","sans-serif";color:#1F497D= '> 

    4)      I= remind the question of priority =A0given to some users that 3GPP will have= to handle. Generally, it is the client that should =A0manages such priorit= ies and signals it to the server but the intermediate Diameter agents are n= ot neutral there and should have the relevant information to behave correct= ly (eg to not drop a message for a priority user). On Req 26 ,we proposed = =A0an additional wording ““ <= /span>For example, it may be mo= re beneficial to process messages for existing sessions ahead of new sessio= ns and to give priority to requests associated with emergency se= ssions or with high priority users&= #8221;. Do you think it is sufficient, or should we have a= normative statement (not only an example)?

     

    &n= bsp;

    Best regards=

     

    JJacques

     =

     

    From: dime-bounces= @ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Eric McMurrySent: lundi 10 d=E9cembre 2012 04:55
    To: THIEBAUT, LAURE= NT (LAURENT)
    Cc: dime@ietf.org
    Subject: Re: [Dime] Dime= : Diameter Overload IETF requirements, review

     

    Thanks f= or clarifying your thoughts Laurent.

     

    I think we're all on= the same page that some changes are likely to happen to support overload c= ontrol in the application specifications and that this is the right level t= o consider priorities and other application specific behaviors.  Where= we seem to be getting wrapped up though is whether those changes will be r= equired to use an overload control mechanism.  I agree changes at the = application specifications are a good idea, but I do not think they are req= uired for basic operation of an overload control mechanism.  I don't s= ee why a mechanism (including the two proposals) could not be used without = any changes to application specifications.

     

    In your = example with an end point implemented as a stack and and application layer,= handling of an overload control protocol could be done in either place. &n= bsp;Decisions about what to do would make sense at the application level, b= ut the implementation could do that in an interoperable fashion  witho= ut needing a new specification, for protocol or behavior, with, for example= , a drop or throttle algorithm that made no consideration of priority.=

     

    <= p class=3DMsoNormal>I think it is important for the design of an overload c= ontrol mechanism to support operation without application specification cha= nges.  It will allow some overload control to be implemented even befo= re application specifications are updated.  It will also ensure that t= he mechanism can be used for application specifications that will not be, o= r do not need to be, updated.  Having a basic overload control mechani= sm in place will be an improvement over current conditions.  We can th= en further improve this, by updating application specifications, to cover c= ases like those you mention for S6a.

     

    Thanks,

     

     

    Eric=

     

    <= div>

     


    <= br>

     

     

    Hello all

    I'd like to highlight the comment = from Tom that touches the topic we wanted to address via our (unfortunate a= s it raised (too) much discussion) comment on REQ 2

    =

     

    Let’= ;s Consider a Diameter end point SW is split up into 2 parts:

    <= /div>

    =B7  &nb= sp;      = a base Diameter stack

    =B7       &n= bsp; an application SW<= /span>

    Even though the application *pr= otocol* is NOT touched by Diameter overload (thanks to * [AVP]), it see= ms questionable that only the base Diameter stack would handle the changes = due to the Diameter overload control we are defining (and that thus the app= lication SW would be untouched). Said otherwise something will have to chan= ge in the Behaviour of the source application.

     

    One of the re= asons is that only the application knows the relative priority of the vario= us procedures and of the various users: e.g. taking the 3GPP S6a as an exam= ple (=3D MME as a kind of authenticator accessing the subscriber database i= .e. the HSS), only the MME SW (as opposed to the Diameter stack or diameter= agent en route between the S6a client and server) knows that

    <= /div>

    o &nbs= p;      <= /span>an Update location is of higher priority than a Purge

    o &n= bsp;      = ;User Lionel is a high priority user while user Laurent is low t= ier user<= o:p>

    o        a request is associated with an emergency=

    o        etc…

    &= nbsp;

    So the application behaviou= r/SW is likely to be changed

     = ;

    May be a solution is to change s= econd part of the REQ2 into "It MUST NOT require protocol specificatio= n changes for existing Diameter applications" (hinting that a behaviou= r change is possible)

    Best regards=

    Laurent

    ALCATEL-LUCENT

     

    Disclaimer: this mail is not meant to promote a= ny of the 2 solutions on the table. It is JUST about requirements.=

     

    -----Me= ssage d'origine-----
    De : = dime-bounces@ietf.org [mailto:dime-= bounces@ietf.org] De la part de Tom Taylor
    Envoy=E9 : samedi 8 = d=E9cembre 2012 04:17
    =C0 : lionel.morand@orange.com
    Cc : dime@ietf.org
    Objet : Re: [Dime] Dime: Diameter Overload I= ETF requirements, review

    =  

    Ben, I think the problem is= that a Diameter implementation can be

    thought of as a base part and an application-specific part. A message<= /span>

    comes in, gets processed by the Di= ameter base part, then the application

    is passed the type of message and the parts not consumed by base. So=

    some extra information is tacked on= in that optional AVP part. Either

    the base recognizes it and deals with it, or the application does. If

    the application is to handle it, the a= pplication has to expect it --

    = tha= t is, the specification of the application includes the additional data.<= /span>

     

    On 07/12/2012 11:19 AM, lionel.morand@orange.com wrote:

    > 

    > 

    > -----Message d'origine----- De : B= en Campbell> [mailto:ben@nostrum.com] Envoy=E9 : vendredi 7 d=E9cembre= 2012 16:47 =C0 :

    > MORAND Lion= el OLNC/OLN Cc : Eric McMurry; THIEBAUT, LAURENT

    > (LAURENT); dime@ietf.o= rg Objet : Re: [Dime] Dime: Diameter Overload

    > IETF requirements, review

    > 

    > =

    > On Dec 7, 2012, at 9:24 AM, = lionel.morand@orange.com wr= ote:=

    > 

    >>> [em] One solution uses existing messa= ges as a carrier,

    >>> pig= gybacking on them.  This can be done by an implementation

    =

    >>> without any change in the specifi= cation of the messages that are

    &g= t;>> being used.

    >>>= ; 

    >>> [LM] It is ex= actly the issue for me! :) I think that you want to

    =

    >>> say that existing commands can be extended w= ith changing the CCF

    >>> = specification and it is true. The application (and its related

    =

    >>> specification/documentation) usin= g this command will change! And

    &g= t;>> it is what I highlight in my comment and in the proposed change.=

    >> 

    ...

    ______= _________________________________________

    DiME mailing list

    _________= ______________________________________
    DiME mailing list
    DiME@ietf.org=
    https://www.ietf.org/mailman/listinfo/dime

     

    <= /div>= --_000_C472E6A4C17FA14E90533C0369A4798B20EB4C16DBFRMRSSXCHMBSA_-- From emcmurry@computer.org Mon Dec 10 12:43:29 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAA221F851E for ; Mon, 10 Dec 2012 12:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YByjlEuSJ5x for ; Mon, 10 Dec 2012 12:43:28 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6E53D21F8512 for ; Mon, 10 Dec 2012 12:43:28 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1TiACF-000NtO-Oh; Mon, 10 Dec 2012 20:43:28 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id C2E28B0548B; Mon, 10 Dec 2012 14:43:25 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/ecXXC0XTZCjVCtTrvDGZsw58xBQSw564= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYT-Oehw_oQ5; Mon, 10 Dec 2012 14:43:25 -0600 (CST) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 4882EB05476; Mon, 10 Dec 2012 14:43:25 -0600 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_39EB54B0-66E1-4D3B-A82B-779C22459688" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric McMurry In-Reply-To: Date: Mon, 10 Dec 2012 14:43:25 -0600 Message-Id: <8F944E58-0BD2-4B7D-98D8-7FC17A4C442A@computer.org> References: <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> <28892_1354818749_50C0E4BD_28892_4479_1_6B7134B31289DC4FAF731D844122B36E0BF868@PEXCVZYM13.corporate.adroot.infra.ftgroup> <81E2AD4F-9FED-498D-ACA2-538C6ED53B7E@computer.org> <13633_1354873372_50C1BA1C_13633_2361_1_6B7134B31289DC4FAF731D844122B36E0C0056@PEXCVZYM13.corporate.adroot.infra.ftgroup> <724F2D49-4B1F-416D-BF94-F46C3DDC02EF@nostrum.com> <16364_1354893872_50C20A30_16364_5192_1_6B7134B31289DC4FAF731D844122B36E0C0699@PEXCVZYM13.corporate.adroot.infra.ftgroup> <18AC9DCE-8C27-43AB-AE3E-CBB913A471A7@nostrum.com> <5614_1354897191_50C21727_5614_8583_1_6B7134B31289DC4FAF731D844122B36E0C0756@PEXCVZYM13.corporate.adroot.infra.ftgroup> <50C2B121.6010508@gmail.com> <"170E8F C C2134BD42B539B47798ABF8F026C0C43F5B"@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <14A53213-81F4-49B3-B7A2-62604921FD1F@computer.org> To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" X-Mailer: Apple Mail (2.1499) Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 20:43:29 -0000 --Apple-Mail=_39EB54B0-66E1-4D3B-A82B-779C22459688 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi JJaques, please see comments inline. Thanks, Eric On Dec 10, 2012, at 14:00 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: > Hi all > =20 > About this long discussion on REQ2, I hereafter give some additional = comments =20 > =20 > 1) Regarding Lionel=92s remark, the fact to add related overload = AVPs to existing commands of a given Diameter application means these = AVPs are now part of the Diameter application which should deal with = them, so impacting the application. > =20 > On another side, in REQ13, piggybacking is mentioned as an example of = a solution for this REQ13 . With piggybacking, the message is only = used as transporter of the related overload AVPs. As messages from = different Diameter applications may be transferred over the same = connection, from my understanding, we may have a solution where the = overload AVPs are transported in any message of any application and = relate or are specific to the same Diameter application as the message = one or to another application or be application independent. Here can = we say these transported AVPs are sometimes part of the Diameter = Application and sometimes no? > =20 > Although this is a solution level discussion, it directly relates to = the REQ2 sentence: =93It MUST NOT require specification changes for = existing Diameter applications=94. > I am rather in favor of Lionel=92s remark and on the text he proposes. = When an AVP is conveyed in a command of an application, it is part of = this Diameter application. The same AVPs may be used by different = Diameter applications. Then it is a matter of implementation: these = overload AVPS or some of them may be processed by a separate = application-independent function in a node, so to minimize impact on = existing applications, but it is implementation. I believe the requirements in this doc apply to the definition of a = standard for an overload control mechanism. They are not direct = requirements on any implementation that may follow that standard. This = is a key distinction. An implementation may do things that are not in a = standard and can still be compliant with that standard depending on how = the standard was crafted. So, as I see it, these comments make sense when talking about = implementations and I am in agreement with them. However, the = requirements are about standards definition. I think for purposes of = discussion of req 2, we need to think in terms of application = implementation and application specification. Use of the unqualified = term 'application' is causing confusion, at least for me. > =20 > 2) In Req1 it is stated that the overload mechanism objective is = =93to provide a communication method =85to exchange the overload = information=94, so no more , no less from my understanding. Then there = are requirements on the Diameter node behaviors. I have no issue with = the many REQs for managing and optimizing well this information = exchange (eg REQ 9, 13, 14, 19=85) by nodes . It is another topic on how = the exchanged information is then used by nodes. I am also OK with the = REQs starting with =93the mechanism MUST allow nodes to =85 (REQ7) , = =93=85MUST provide a way to (REQ 22)=92 as we are still speaking of the = exchanged information which allows nodes to=85 . I think we should = also use this type of wording for a few requirements eg for REQ 7 =93the= mechanism must ensure that the system remains stable=94 as it is not = the exchanged information which stabilize the system, but the nodes = behavior on the basis of information exchanges. that is a good point. I agree with changing req 7 like this. Assuming = others do as well, I'll look though for other examples at the same time. > =20 > 3) This document does not address any overload algorithm which = will be key on how the exchanged information is then used by nodes. = =46rom a 3GPP angle, the approach ALU foresees is to use the Dime method = to exchange the overload information, eventually by extending the = information exchanged (REQ 33, 34), and to specify nodes behaviors = about overload handling according to the Diameter application = (corresponding to a 3GPP interface) and the overload algorithm. =20 > Eric=92s mail mentions a basic operation of an overload control = mechanism, which should correspond to an overload algorithm. Has Dime = the intent to specify some general overload algorithms? Each of the current mechanism proposals in place have defined defaults = for algorithm and I think we're all on the same page that a minimal set = (one or two) should be supported as default. > =20 > 4) I remind the question of priority given to some users that = 3GPP will have to handle. Generally, it is the client that should = manages such priorities and signals it to the server but the = intermediate Diameter agents are not neutral there and should have the = relevant information to behave correctly (eg to not drop a message for a = priority user). On Req 26 ,we proposed an additional wording =93=93 For = example, it may be more beneficial to process messages for existing = sessions ahead of new sessions and to give priority to requests = associated with emergency sessions or with high priority users=94. Do = you think it is sufficient, or should we have a normative statement (not = only an example)? I think that should be sufficient. If we start doing something = normative here, we restrict the flexibility of applications to define = their own behavior. do you think there are things we can do here that = will be in common for all possible applications? [...]= --Apple-Mail=_39EB54B0-66E1-4D3B-A82B-779C22459688 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
    Hi = JJaques,

    please see comments = inline.

    Thanks,

    Eric


    On Dec 10, 2012, at 14:00 , = "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trott= in@alcatel-lucent.com> wrote:

    Hi = all
     
    About this = long discussion on REQ2, I hereafter give some additional comments =  
     
    1)      Regarding Lionel=92s remark,  the fact to add related = overload AVPs to existing commands of a given Diameter application means = these AVPs are now part of the Diameter application which should deal = with them, so impacting the application.
     
    On =
another side, in REQ13, piggybacking is mentioned as an example of a =
solution for this REQ13 .  With  piggybacking, the message is =
only used as transporter of the related overload AVPs.   As =
messages from different Diameter applications may be transferred over =
the same connection,  from my understanding, we may have a solution =
where  the overload AVPs are transported in any message of any =
application and relate or are specific to the same Diameter application =
as the message one or to another application or be application =
independent. Here  can we say these transported AVPs are sometimes =
 part of the Diameter Application and sometimes =
no?
     
    Although this is a =
solution level discussion, it directly relates to the REQ2 sentence: =
=93It MUST NOT =
require specification changes for existing Diameter =
applications=94.
    I am rather in favor of =
Lionel=92s remark and on the text he proposes. When an AVP is conveyed =
in a command of an application, it is part of this Diameter application. =
The same AVPs may be used by different Diameter applications. Then it is =
a matter of implementation: these overload  AVPS or some of them =
may be processed by a separate application-independent function in a =
node, so to minimize  impact on existing applications, but it is =
implementation.

    <= div>
    I believe the requirements in this doc apply to the = definition of a standard for an overload control mechanism.  They = are not direct requirements on any implementation that may follow that = standard.  This is a key distinction.  An implementation may = do things that are not in a standard and can still be compliant with = that standard depending on how the standard was = crafted.

    So, as I see it, these comments make = sense when talking about implementations and I am in agreement with = them.  However, the requirements are about standards definition. =  I think for purposes of discussion of req 2, we need to think in = terms of application implementation and application specification. =  Use of the unqualified term 'application' is causing confusion, at = least for me.


    2)In =
Req1 it is stated that the overload mechanism objective is =93to provide =
a communication method =85to exchange the overload information=94, so no =
more , no less from my understanding.  Then there are requirements =
on the Diameter node behaviors. I have  no issue with the many =
 REQs for managing and optimizing well this information exchange =
(eg REQ 9, 13, 14, 19=85) by nodes . It is another topic on how the =
exchanged information is then used by nodes. I am also OK with the REQs =
starting with =93the mechanism MUST allow nodes to =85 (REQ7) , =93=85MUST=
 provide a way to (REQ 22)=92 as we are still speaking of the exchanged =
information  which  allows nodes to=85 . I think we should =
also use this type of wording for a few requirements  eg for REQ 7 =
 =93the mechanism  must ensure  that the system remains =
stable=94 as it is not the exchanged information  which stabilize =
the system, but the nodes behavior on the basis of information =
exchanges.

    that = is a good point.  I agree with changing req 7 like this. =  Assuming others do as well, I'll look though for other examples at = the same time.

     
    3)Eric=92s mail mentions a basic operation of = an overload control mechanism, which should correspond to an overload = algorithm. Has Dime the intent to specify some general overload = algorithms?

    Each = of the current mechanism proposals in place have defined defaults for = algorithm and I think we're all on the same page that a minimal set (one = or two) should be supported as default.

     
    4)I = remind the question of priority  given to some users that 3GPP will = have to handle. Generally, it is the client that should  manages = such priorities and signals it to the server but the intermediate = Diameter agents are not neutral there and should have the relevant = information to behave correctly (eg to not drop a message for a priority = user). On Req 26 ,we proposed  an additional wording =93=93 For example, it may be more = beneficial to process messages for existing sessions ahead of new = sessions andto give = priority to requests associated with emergency sessions or with high = priority usersDo you think it is = sufficient, or should we have a normative statement (not only an = example)?

    I = think that should be sufficient.  If we start doing something = normative here, we restrict the flexibility of applications to define = their own behavior.  do you think there are things we can do here = that will be in common for all possible = applications?


    [...]
    = --Apple-Mail=_39EB54B0-66E1-4D3B-A82B-779C22459688-- From ben@nostrum.com Mon Dec 10 12:58:07 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1608621F868E for ; Mon, 10 Dec 2012 12:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hmu+TctamgWy for ; Mon, 10 Dec 2012 12:58:06 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3B27B21F8689 for ; Mon, 10 Dec 2012 12:58:03 -0800 (PST) Received: from [10.119.73.174] (v398.dal.ubiquity.io [174.34.133.219] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qBAKvqA0071002 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Dec 2012 14:57:53 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <8F944E58-0BD2-4B7D-98D8-7FC17A4C442A@computer.org> Date: Mon, 10 Dec 2012 14:57:50 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4F79BFB3-1067-4407-8DC0-22032E442D50@nostrum.com> References: <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> <28892_1354818749_50C0E4BD_28892_4479_1_6B7134B31289DC4FAF731D844122B36E0BF868@PEXCVZYM13.corporate.adroot.infra.ftgroup> <81E2AD4F-9FED-498D-ACA2-538C6ED53B7E@computer.org> <13633_1354873372_50C1BA1C_13633_2361_1_6B7134B31289DC4FAF731D844122B36E0C0056@PEXCVZYM13.corporate.adroot.infra.ftgroup> <724F2D49-4B1F-416D-BF94-F46C3DDC02EF@nostrum.com> <16364_1354893872_50C20A30_16364_5192_1_6B7134B31289DC4FAF731D844122B36E0C0699@PEXCVZYM13.corporate.adroot.infra.ftgroup> <18AC9DCE-8C27-43AB-AE3E-CBB913A471A7@nostrum.com> <5614_1354897191_50C21727_5614_8583_1_6B7134B31289DC4FAF731D844122B36E0C0756@PEXCVZYM13.corporate.adroot.infra.ftgroup> <50C2B121.6010508@gmail.com>! <"170E8F C C2134BD42B539B47798ABF8F026C0C43F5B"@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <14A53213-81F4-49B3-B7A2-62604921FD1F@computer.org> <8F944E58-0BD2-4B7D-98D8-7FC17A4C442A@computer.org> To: Eric McMurry X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 174.34.133.219 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 20:58:07 -0000 Hi, I've added some comments inline: Thanks! Ben. On Dec 10, 2012, at 2:43 PM, Eric McMurry wrote: [...] > On Dec 10, 2012, at 14:00 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: >=20 >> Hi all >> =20 >> About this long discussion on REQ2, I hereafter give some additional = comments =20 >> =20 >> 1) Regarding Lionel=92s remark, the fact to add related = overload AVPs to existing commands of a given Diameter application means = these AVPs are now part of the Diameter application which should deal = with them, so impacting the application. >> =20 >> On another side, in REQ13, piggybacking is mentioned as an example of = a solution for this REQ13 . With piggybacking, the message is only = used as transporter of the related overload AVPs. As messages from = different Diameter applications may be transferred over the same = connection, from my understanding, we may have a solution where the = overload AVPs are transported in any message of any application and = relate or are specific to the same Diameter application as the message = one or to another application or be application independent. Here can = we say these transported AVPs are sometimes part of the Diameter = Application and sometimes no? >> =20 >> Although this is a solution level discussion, it directly relates to = the REQ2 sentence: =93It MUST NOT require specification changes for = existing Diameter applications=94. >> I am rather in favor of Lionel=92s remark and on the text he = proposes. When an AVP is conveyed in a command of an application, it is = part of this Diameter application. The same AVPs may be used by = different Diameter applications. Then it is a matter of implementation: = these overload AVPS or some of them may be processed by a separate = application-independent function in a node, so to minimize impact on = existing applications, but it is implementation. >=20 >=20 > I believe the requirements in this doc apply to the definition of a = standard for an overload control mechanism. They are not direct = requirements on any implementation that may follow that standard. This = is a key distinction. An implementation may do things that are not in a = standard and can still be compliant with that standard depending on how = the standard was crafted. >=20 > So, as I see it, these comments make sense when talking about = implementations and I am in agreement with them. However, the = requirements are about standards definition. I think for purposes of = discussion of req 2, we need to think in terms of application = implementation and application specification. Use of the unqualified = term 'application' is causing confusion, at least for me. I concur that this entire draft is about requirements on the = _specification_ of an OC mechanism, not any particular _implementation_. = But I think this particular requirement goes further, as it talks about = how the mechanism might impact other _specifications_, namely = specifications of standardized Diameter applications. So the point about = making sure our language is clear about implementation vs specification = is doubly true. >=20 >=20 >> =20 >> 2) In Req1 it is stated that the overload mechanism objective is = =93to provide a communication method =85to exchange the overload = information=94, so no more , no less from my understanding. Then there = are requirements on the Diameter node behaviors. I have no issue with = the many REQs for managing and optimizing well this information = exchange (eg REQ 9, 13, 14, 19=85) by nodes . It is another topic on how = the exchanged information is then used by nodes. I am also OK with the = REQs starting with =93the mechanism MUST allow nodes to =85 (REQ7) , = =93=85MUST provide a way to (REQ 22)=92 as we are still speaking of the = exchanged information which allows nodes to=85 . I think we should = also use this type of wording for a few requirements eg for REQ 7 =93the= mechanism must ensure that the system remains stable=94 as it is not = the exchanged information which stabilize the system, but the nodes = behavior on the basis of information exchanges. >=20 > that is a good point. I agree with changing req 7 like this. = Assuming others do as well, I'll look though for other examples at the = same time. I'm not sure I agree on this point. As Eric mentions in the next section = (below), we expect the overload mechanism to include a default overload = algorithm, as well as a communications method. If we don't have = requirements for that, we should. (Are we talking = manditory-to-implement?) So I think Req 7 means more than just saying that it MUST be possible = for nodes to use the exchanged information to ensure stability. It means = that the default algorithm MUST ensure stability. >=20 >> =20 >> 3) This document does not address any overload algorithm which = will be key on how the exchanged information is then used by nodes. = =46rom a 3GPP angle, the approach ALU foresees is to use the Dime method = to exchange the overload information, eventually by extending the = information exchanged (REQ 33, 34), and to specify nodes behaviors = about overload handling according to the Diameter application = (corresponding to a 3GPP interface) and the overload algorithm. =20 >> Eric=92s mail mentions a basic operation of an overload control = mechanism, which should correspond to an overload algorithm. Has Dime = the intent to specify some general overload algorithms? >=20 > Each of the current mechanism proposals in place have defined defaults = for algorithm and I think we're all on the same page that a minimal set = (one or two) should be supported as default. (see previous comment) >=20 >> =20 >> 4) I remind the question of priority given to some users that = 3GPP will have to handle. Generally, it is the client that should = manages such priorities and signals it to the server but the = intermediate Diameter agents are not neutral there and should have the = relevant information to behave correctly (eg to not drop a message for a = priority user). On Req 26 ,we proposed an additional wording =93=93 For = example, it may be more beneficial to process messages for existing = sessions ahead of new sessions and to give priority to requests = associated with emergency sessions or with high priority users=94. Do = you think it is sufficient, or should we have a normative statement (not = only an example)? >=20 > I think that should be sufficient. If we start doing something = normative here, we restrict the flexibility of applications to define = their own behavior. I concur. The normative statement is that the _specification_ SHOULD = offer guidance. The example is merely there to clarify the sort of = guidance we have in mind. Nothing in this document should be interpreted = to mean we have already figured out the _content_ of that guidance. > do you think there are things we can do here that will be in common = for all possible applications? I think that's highly unlikely. Even the guidance itself is most likely = to be non-normative. From kristian.poscic@alcatel-lucent.com Mon Dec 10 16:39:56 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E3C21F86FB for ; Mon, 10 Dec 2012 16:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.382 X-Spam-Level: X-Spam-Status: No, score=-7.382 tagged_above=-999 required=5 tests=[AWL=-1.134, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wyY5TqLRi9td for ; Mon, 10 Dec 2012 16:39:54 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 55B9821F86FA for ; Mon, 10 Dec 2012 16:39:48 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBB0dgwa024587 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 11 Dec 2012 01:39:46 +0100 Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (135.120.45.62) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 11 Dec 2012 01:39:44 +0100 Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.227]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Mon, 10 Dec 2012 19:39:28 -0500 From: "Poscic, Kristian (Kristian)" To: "dime@ietf.org" Thread-Topic: failover scenario Thread-Index: Ac3XNgVVklLO7zbqTReQ9dDlPt2SKw== Date: Tue, 11 Dec 2012 00:39:25 +0000 Message-ID: <7921F977B17D5B49B8DCC955A339D2F02AA28B4D@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F02AA28B4DUS70UWXCHMBA05z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: [Dime] failover scenario X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 00:39:56 -0000 --_000_7921F977B17D5B49B8DCC955A339D2F02AA28B4DUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Does anyone know what would be the mechanism in Base Diameter to handle the= following scenario properly: - There are two NASes that run certain application (Gx in this cas= e) - They are in standby/active mode - in other words, the NAS1 is ac= tive and has peering session with DMR-SRV. NAS2 is synched to NAS (Gx sess= ion are synched and diameter entities are synched too - origin-host, origin= -realm, possibly more AVPs...). However NAS2 is standby and therefore quiet= (no peering session is established with DMR-SRV) - If the NAS 1 fails, the NAS2 takes over (it detects the failure = and activates itself along with application that is running on top of Base = Diameter) - At this point, NAS2 will establish a peering session with DMR-SR= V. The only difference between NAS2 and the failed NAS1 is the Host-IP-addr= ess (as AVP and also the source IP address in the transport =3D> src IPs ar= e not synched). - When the NAS2 sends CER and the peering session is established w= ith DMR-SRV, will the DMR-SRV automatically update its routing table and se= e that nas.example.com is now at IP2 and not at IP1. Consequently all subse= quent messages would be exchanged between NAS2 and DMR-SRV - All this presuppose that there are no changes on the application= layer (Gx for example is completely synched between NASes) and the re-rout= ing is handled at the Base Diameter. - Would this work and if not what would be the recommended approac= h that is compliant with Base Diameter so that the routing in DMR-SRV is up= dated properly? Origin-host =3D nas.example.com Origin-realm=3D example.com Host-IP-Address =3D IP1 --------- |NAS1 | ------------------- --------- | | = -------------- |-----------------| DMR-SRV= | --------- | --= ------------ |NAS2 |------------------- --------- Origin-host =3D nas.example.com Origin-realm=3D example.com Host-IP-Address =3D IP2 Thanks, Kris --_000_7921F977B17D5B49B8DCC955A339D2F02AA28B4DUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Does anyone know what would be the mechanism in Base= Diameter to handle the following scenario properly:

     

    -     &= nbsp;    There are two NASes that run certain application (G= x in this case)

    -     &= nbsp;    They are in standby/active mode – in other wo= rds, the NAS1 is active and has peering session with DMR-SRV. NAS2 is synch= ed to NAS  (Gx session are synched and diameter entities are synched t= oo – origin-host, origin-realm, possibly more AVPs…). However NAS2 is standby and therefore quiet (no peering sess= ion is established with  DMR-SRV)

    -     &= nbsp;    If the NAS 1 fails, the NAS2 takes over (it detects= the failure and activates itself along with application that is running on= top of Base Diameter)

    -     &= nbsp;    At this point, NAS2 will establish a peering sessio= n with DMR-SRV. The only difference between NAS2 and the failed NAS1 is the= Host-IP-address (as AVP and also the source IP address in the transport = =3D> src IPs are not synched).

    -     &= nbsp;    When the NAS2 sends CER and the peering session is = established with DMR-SRV, will the DMR-SRV automatically update its routing= table and see that nas.example.com is now at IP2 and not at IP1. Consequen= tly all subsequent messages would be exchanged between NAS2 and DMR-SRV

    -     &= nbsp;    All this presuppose that there are no changes on th= e application layer (Gx for example is completely synched between NASes) an= d the re-routing is handled at the Base Diameter.

    -     &= nbsp;    Would this work and if not what would be the recomm= ended approach that is compliant with Base Diameter so that the routing in = DMR-SRV is updated properly?

     

     

     

    Origin-host =3D        = ;            &n= bsp; nas.example.com

    Origin-realm=3D        = ;            example= .com

    Host-IP-Address =3D      &n= bsp;    IP1

     

    ---------

    |NAS1 | -------------------

    ---------       &= nbsp;            &nb= sp;            |

            &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; |           &n= bsp;            = ;      --------------

            &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; |-----------------| DMR-SRV|

    ---------       &= nbsp;           &nbs= p;             = |            &n= bsp;            = ;     --------------

    |NAS2 |-------------------

    ---------

     

    Origin-host =3D        = ;            &n= bsp; nas.example.com

    Origin-realm=3D        = ;            example= .com

    Host-IP-Address =3D      &n= bsp;    IP2

     

     

    Thanks,

    Kris

    --_000_7921F977B17D5B49B8DCC955A339D2F02AA28B4DUS70UWXCHMBA05z_-- From internet-drafts@ietf.org Mon Dec 10 23:19:10 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CF921F875C; Mon, 10 Dec 2012 23:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5MuFiYKpy6p; Mon, 10 Dec 2012 23:19:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816C121F86E2; Mon, 10 Dec 2012 23:19:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121211071909.12140.40965.idtracker@ietfa.amsl.com> Date: Mon, 10 Dec 2012 23:19:09 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-erp-16.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 07:19:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Diameter Support for the EAP Re-authentication Protocol = (ERP) Author(s) : Julien Bournelle Lionel Morand Sebastien Decugis Qin Wu Glen Zorn Filename : draft-ietf-dime-erp-16.txt Pages : 16 Date : 2012-12-10 Abstract: The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new AVPs that can be used to transport the cryptographic material needed by the re-authentication server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-erp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-erp-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-erp-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lionel.morand@orange.com Tue Dec 11 01:47:00 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3218421F8514 for ; Tue, 11 Dec 2012 01:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcFtAqkvsI1V for ; Tue, 11 Dec 2012 01:46:55 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 67D3E21F850B for ; Tue, 11 Dec 2012 01:46:54 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id E37B622C864; Tue, 11 Dec 2012 10:46:52 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 2BA1227C069; Tue, 11 Dec 2012 10:46:52 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Tue, 11 Dec 2012 10:46:51 +0100 From: To: Eric McMurry , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" Thread-Topic: [Dime] Dime: Diameter Overload IETF requirements, review Thread-Index: Ac3WiiC1gu8pDCj/Q+Kaw26KHsPx/QAhncsQ///8DID//yE/0A== Date: Tue, 11 Dec 2012 09:46:51 +0000 Message-ID: <16082_1355219212_50C7010C_16082_10054_1_6B7134B31289DC4FAF731D844122B36E0C280B@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> <28892_1354818749_50C0E4BD_28892_4479_1_6B7134B31289DC4FAF731D844122B36E0BF868@PEXCVZYM13.corporate.adroot.infra.ftgroup> <81E2AD4F-9FED-498D-ACA2-538C6ED53B7E@computer.org> <13633_1354873372_50C1BA1C_13633_2361_1_6B7134B31289DC4FAF731D844122B36E0C0056@PEXCVZYM13.corporate.adroot.infra.ftgroup> <724F2D49-4B1F-416D-BF94-F46C3DDC02EF@nostrum.com> <16364_1354893872_50C20A30_16364_5192_1_6B7134B31289DC4FAF731D844122B36E0C0699@PEXCVZYM13.corporate.adroot.infra.ftgroup> <18AC9DCE-8C27-43AB-AE3E-CBB913A471A7@nostrum.com> <5614_1354897191_50C21727_5614_8583_1_6B7134B31289DC4FAF731D844122B36E0C0756@PEXCVZYM13.corporate.adroot.infra.ftgroup> <50C2B121.6010508@gmail.com> <"170E8F C C2134BD42B539B47798ABF8F026C0C43F5B"@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <14A53213-81F4-49B3-B7A2-62604921FD1F@computer.org> <8F944E58-0BD2-4B7D-98D8-7FC17A4C442A@computer.org> In-Reply-To: <8F944E58-0BD2-4B7D-98D8-7FC17A4C442A@computer.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E0C280BPEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.11.90324 Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 09:47:00 -0000 --_000_6B7134B31289DC4FAF731D844122B36E0C280BPEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Eric, Just on this point: "Use of the unqualified term 'application' is causing confusion, at least f= or me." As I said, it is the use of 'specification' that causes confusion in REQ2. I can understand that some new folks may encounter some difficulties in und= erstanding the wording used in Diameter specifications e.g. RFC3588, RFC 67= 33, all the related RFCs specifying Diameter 'applications' or even the tit= le of the draft Diameter Applications Design Guidelines ... But I don't think that it is a reason to change the definition or even intr= oduce more confusion. Based on this discussion, I'm more and more convinced that the correct word= ing for the REQ2 should be something based on my proposal: OLD: REQ 2: The overload [control] mechanism MUST be useable with any exist= ing or future Diameter application. It MUST NOT require specification changes for existing Diameter applications. NEW: REQ 2: The overload [control] mechanism MUST be useable with any exist= ing or future Diameter application. Support of this mechanism over ex= isting Diameter applications MUST NOT require major changes that would= lead to the need to define a new Diameter application. Regards, Lionel De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Eri= c McMurry Envoy=E9 : lundi 10 d=E9cembre 2012 21:43 =C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Cc : dime@ietf.org Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review Hi JJaques, please see comments inline. Thanks, Eric On Dec 10, 2012, at 14:00 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" > wrote: Hi all About this long discussion on REQ2, I hereafter give some additional commen= ts 1) Regarding Lionel's remark, the fact to add related overload AVPs t= o existing commands of a given Diameter application means these AVPs are no= w part of the Diameter application which should deal with them, so impactin= g the application. On another side, in REQ13, piggybacking is mentioned as an example of a sol= ution for this REQ13 . With piggybacking, the message is only used as tra= nsporter of the related overload AVPs. As messages from different Diamete= r applications may be transferred over the same connection, from my unders= tanding, we may have a solution where the overload AVPs are transported in= any message of any application and relate or are specific to the same Diam= eter application as the message one or to another application or be applica= tion independent. Here can we say these transported AVPs are sometimes pa= rt of the Diameter Application and sometimes no? Although this is a solution level discussion, it directly relates to the RE= Q2 sentence: "It MUST NOT require specification changes for existing Diamet= er applications". I am rather in favor of Lionel's remark and on the text he proposes. When a= n AVP is conveyed in a command of an application, it is part of this Diamet= er application. The same AVPs may be used by different Diameter application= s. Then it is a matter of implementation: these overload AVPS or some of t= hem may be processed by a separate application-independent function in a no= de, so to minimize impact on existing applications, but it is implementati= on. I believe the requirements in this doc apply to the definition of a standar= d for an overload control mechanism. They are not direct requirements on a= ny implementation that may follow that standard. This is a key distinction= . An implementation may do things that are not in a standard and can still= be compliant with that standard depending on how the standard was crafted. So, as I see it, these comments make sense when talking about implementatio= ns and I am in agreement with them. However, the requirements are about st= andards definition. I think for purposes of discussion of req 2, we need t= o think in terms of application implementation and application specificatio= n. Use of the unqualified term 'application' is causing confusion, at leas= t for me. 2) In Req1 it is stated that the overload mechanism objective is "to p= rovide a communication method ...to exchange the overload information", so = no more , no less from my understanding. Then there are requirements on th= e Diameter node behaviors. I have no issue with the many REQs for managin= g and optimizing well this information exchange (eg REQ 9, 13, 14, 19...) b= y nodes . It is another topic on how the exchanged information is then used= by nodes. I am also OK with the REQs starting with "the mechanism MUST all= ow nodes to ... (REQ7) , "...MUST provide a way to (REQ 22)' as we are stil= l speaking of the exchanged information which allows nodes to... . I thin= k we should also use this type of wording for a few requirements eg for RE= Q 7 "the mechanism must ensure that the system remains stable" as it is = not the exchanged information which stabilize the system, but the nodes be= havior on the basis of information exchanges. that is a good point. I agree with changing req 7 like this. Assuming oth= ers do as well, I'll look though for other examples at the same time. 3) This document does not address any overload algorithm which will be= key on how the exchanged information is then used by nodes. From a 3GPP = angle, the approach ALU foresees is to use the Dime method to exchange the = overload information, eventually by extending the information exchanged (RE= Q 33, 34), and to specify nodes behaviors about overload handling accordi= ng to the Diameter application (corresponding to a 3GPP interface) and the = overload algorithm. Eric's mail mentions a basic operation of an overload control mechanism, wh= ich should correspond to an overload algorithm. Has Dime the intent to spec= ify some general overload algorithms? Each of the current mechanism proposals in place have defined defaults for = algorithm and I think we're all on the same page that a minimal set (one or= two) should be supported as default. 4) I remind the question of priority given to some users that 3GPP wi= ll have to handle. Generally, it is the client that should manages such pr= iorities and signals it to the server but the intermediate Diameter agents = are not neutral there and should have the relevant information to behave co= rrectly (eg to not drop a message for a priority user). On Req 26 ,we propo= sed an additional wording "" For example, it may be more beneficial to pro= cess messages for existing sessions ahead of new sessions and to give prior= ity to requests associated with emergency sessions or with high priority us= ers". Do you think it is sufficient, or should we have a normative statemen= t (not only an example)? I think that should be sufficient. If we start doing something normative h= ere, we restrict the flexibility of applications to define their own behavi= or. do you think there are things we can do here that will be in common fo= r all possible applications? [...] ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E0C280BPEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Hi Eric,

     

    Just on this point:

    “Use of the unqualified te= rm 'application' is causing confusion, at least for me.”=

     

    As I said, it is the use of ‘specification’ that= causes confusion in REQ2.

    I can understand that some new folks may encounter some diff= iculties in understanding the wording used in Diameter specifications e.g. = RFC3588, RFC 6733, all the related RFCs specifying Diameter ‘applicationsR= 17; or even the title of the draft = Diameter Applications Design Guidelines …

    But I don’t think that it is a reason to change the de= finition or even introduce more confusion.

     

    Based on this discussion, I’m more and more convinced = that the correct wording for the REQ2 should be something based on my propo= sal:

     

    OLD:

     

       REQ 2: &nb= sp; The overload [control] mechanism MUST be useable with any existing or

        &nbs= p;       future Diameter application.  I= t MUST NOT require

        &nbs= p;       specification changes for existing D= iameter applications.

     

    NEW:

     

       REQ 2: &nb= sp; The overload [control] mechanism MUST be useable with any existing or

        &nbs= p;       future Diameter application.  S= upport of this mechanism over existing

        &nbs= p;       Diameter applications MUST NOT requi= re major changes that would lead

        &nbs= p;       to the need to define a new Diameter= application.

     

    Regards,

     

    Lionel

     

     

    De : dime= -bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Eric McMurry
    Envoy=E9 : lundi 10 d=E9cembre 2012 21:43
    =C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
    Cc : dime@ietf.org
    Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, r= eview

     

    Hi JJaques,

     

    please see comments inline.

     

    Thanks,

     

    Eric

     

     

    On Dec 10, 2012, at 14:00 , "TROTTIN, JEAN-JACQ= UES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:



    Hi all

     

    About this long discussion on REQ2, I hereafter give some ad= ditional comments  

     

    1)      Regarding Lionel’s remark,  the fact to add related overload AVPs to exis= ting commands of a given Diameter application means these AVPs are now part= of the Diameter application which should deal with them, so impacting the = application.

     

    On another side, in REQ13, piggybacking is mentio=
ned as an example of a solution for this REQ13 .  With  piggyback=
ing, the message is only used as transporter of the related overload AVPs. =
  As messages from different Diameter applications may be transfe=
rred over the same connection,  from my understanding, we may have a s=
olution where  the overload AVPs are transported in any message of any=
 application and relate or are specific to the same Diameter application as=
 the message one or to another application or be application independent. H=
ere  can we say these transported AVPs are sometimes  part of the=
 Diameter Application and sometimes no?
     
    Although this is a solution level discussion, it =
directly relates to the REQ2 sentence: “It M=
UST NOT require specification changes for existing Diameter applications=
221;.
    I am rather in fa=
vor of Lionel’s remark and on the text he proposes. When an AVP is co=
nveyed in a command of an application, it is part of this Diameter applicat=
ion. The same AVPs may be used by different Diameter applications. Then it =
is a matter of implementation: these overload  AVPS or some of them ma=
y be processed by a separate application-independent function in a node, so=
 to minimize  impact on existing applications, but it is implementatio=
n.

     

     

    I believe the requirements in this doc apply to the = definition of a standard for an overload control mechanism.  They are = not direct requirements on any implementation that may follow that standard= .  This is a key distinction.  An implementation may do things that are not in a standard and can still be compliant with t= hat standard depending on how the standard was crafted.

     

    So, as I see it, these comments make sense when talk= ing about implementations and I am in agreement with them.  However, t= he requirements are about standards definition.  I think for purposes = of discussion of req 2, we need to think in terms of application implementation and application specification.  U= se of the unqualified term 'application' is causing confusion, at least for= me.

     



    2)&n= bsp;     In Req1 it is stated that the overload mechanism objective is “to provi= de a communication method …to exchange the overload information”= ;, so no more , no less from my understanding.  Then there are require= ments on the Diameter node behaviors. I have  no issue with the many  REQs for managing and optimizing well this information= exchange (eg REQ 9, 13, 14, 19…) by nodes . It is another topic on h= ow the exchanged information is then used by nodes. I am also OK with the R= EQs starting with “the mechanism MUST allow nodes to … (REQ7) , “…MUST provide a way to (REQ 22)R= 17; as we are still speaking of the exchanged information  which  = ;allows nodes to… . I think we should also use this type of wording f= or a few requirements  eg for REQ 7  “the mechanism  m= ust ensure  that the system remains stable” as it is not the exchanged information  = which stabilize the system, but the nodes behavior on the basis of informat= ion exchanges.

     

    that is a good point.  I agree with changing re= q 7 like this.  Assuming others do as well, I'll look though for other= examples at the same time.



     

    3)&n= bsp;     This document does not address any overload algorithm which will be key on how = the exchanged information is then used by nodes.   From a 3GPP an= gle, the approach ALU foresees is to use the Dime method to exchange the ov= erload information, eventually by extending the information exchanged (REQ 33, 34),   and to specify nodes b= ehaviors about overload handling according to the Diameter application (cor= responding to a 3GPP interface) and the overload algorithm.  

    Eric’s mail mentions a basic operation of an overload = control mechanism, which should correspond to an overload algorithm. Has Di= me the intent to specify some general overload algorithms?

     

    Each of the current mechanism proposals in place hav= e defined defaults for algorithm and I think we're all on the same page tha= t a minimal set (one or two) should be supported as default.



     

    4)&n= bsp;     I remind the question of priority  given to some users that 3GPP will h= ave to handle. Generally, it is the client that should  manages such p= riorities and signals it to the server but the intermediate Diameter agents= are not neutral there and should have the relevant information to behave correctly (eg to not drop a message for a p= riority user). On Req 26 ,we proposed  an additional wording ““ For example, it may be more beneficial to process messages for ex= isting sessions ahead of new sessions = and to give priority to requests associated with emergency sessions or with high = priority users”. = Do you think it is sufficient, or should we have a normative statement (not only an example)?

     

    I think that should be sufficient.  If we start= doing something normative here, we restrict the flexibility of application= s to define their own behavior.  do you think there are things we can = do here that will be in common for all possible applications?

     

     

    [...]

    ______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
    --_000_6B7134B31289DC4FAF731D844122B36E0C280BPEXCVZYM13corpora_-- From emcmurry@computer.org Tue Dec 11 05:59:39 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB96F21F8782 for ; Tue, 11 Dec 2012 05:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ft3-PIhr7WU7 for ; Tue, 11 Dec 2012 05:59:38 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id E349721F8765 for ; Tue, 11 Dec 2012 05:59:37 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1TiQMy-000KJx-B4; Tue, 11 Dec 2012 13:59:37 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 81F6EB0FB74; Tue, 11 Dec 2012 07:59:33 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19ddv8XW71WScw8HTNanjdYnfhBg8V4eyM= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8y-5hvoVceH; Tue, 11 Dec 2012 07:59:33 -0600 (CST) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 4BA8CB0FB5F; Tue, 11 Dec 2012 07:59:33 -0600 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_889D41A3-95CA-49C6-AC8A-570F5EB56814" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric McMurry In-Reply-To: <16082_1355219212_50C7010C_16082_10054_1_6B7134B31289DC4FAF731D844122B36E0C280B@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 11 Dec 2012 07:59:32 -0600 Message-Id: <251F43C5-9526-4855-98D9-4315EBF66E87@computer.org> References: <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> <28892_1354818749_50C0E4BD_28892_4479_1_6B7134B31289DC4FAF731D844122B36E0BF868@PEXCVZYM13.corporate.adroot.infra.ftgroup> <81E2AD4F-9FED-498D-ACA2-538C6ED53B7E@computer.org> <13633_1354873372_50C1BA1C_13633_2361_1_6B7134B31289DC4FAF731D844122B36E0C0056@PEXCVZYM13.corporate.adroot.infra.ftgroup> <724F2D49-4B1F-416D-BF94-F46C3DDC02EF@nostrum.com> <16364_1354893872_50C20A30_16364_5192_1_6B7134B31289DC4FAF731D844122B36E0C0699@PEXCVZYM13.corporate.adroot.infra.ftgroup> <18AC9DCE-8C27-43AB-AE3E-CBB913A471A7@nostrum.com> <5614_1354897191_50C21727_5614_8583_1_6B7134B31289DC4FAF731D844122B36E0C0756@PEXCVZYM13.corporate.adroot.infra.ftgroup> <50C2B121.6010508@gmail.com> <"170E8F C C2134BD42B539B47798ABF8F026C0C43F5B"@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <14A53213-81F4-49B3-B7A2-62604921FD1F@computer.org> <8F944E58-0BD2-4B7D-98D8-7FC17A4C442A@computer.org> <16082_1355219212_50C7010C_16082_10054_1_6B7134B31289DC4FAF731D844122B36E0C280B@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1499) Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 13:59:39 -0000 --Apple-Mail=_889D41A3-95CA-49C6-AC8A-570F5EB56814 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Lionel, I'm not arguing against changing the language in req 2. This discussion = has made it quite clear that needs to happen. The alternate proposals I have seen do not say the same thing though and = are weaker requirements. It is important for the resulting OC mechanism = to work without requiring changes to the specification of an = application. Perhaps you have a better way of saying this. For = example, I would expect the OC mechanism to work between an MME and HHS = without touching 29.272. Can you propose alternate language that = captures this? Thanks! Eric On Dec 11, 2012, at 3:46 , lionel.morand@orange.com wrote: > Hi Eric, > =20 > Just on this point: > =93Use of the unqualified term 'application' is causing confusion, at = least for me.=94 > =20 > As I said, it is the use of =91specification=92 that causes confusion = in REQ2. > I can understand that some new folks may encounter some difficulties = in understanding the wording used in Diameter specifications e.g. = RFC3588, RFC 6733, all the related RFCs specifying Diameter = =91applications=92 or even the title of the draft Diameter Applications = Design Guidelines =85 > But I don=92t think that it is a reason to change the definition or = even introduce more confusion. > =20 > Based on this discussion, I=92m more and more convinced that the = correct wording for the REQ2 should be something based on my proposal: > =20 > OLD: > =20 > REQ 2: The overload [control] mechanism MUST be useable with any = existing or > future Diameter application. It MUST NOT require > specification changes for existing Diameter applications. > =20 > NEW: > =20 > REQ 2: The overload [control] mechanism MUST be useable with any = existing or > future Diameter application. Support of this mechanism = over existing > Diameter applications MUST NOT require major changes that = would lead > to the need to define a new Diameter application. > =20 > Regards, > =20 > Lionel > =20 > =20 > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Eric McMurry > Envoy=E9 : lundi 10 d=E9cembre 2012 21:43 > =C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES) > Cc : dime@ietf.org > Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review > =20 > Hi JJaques, > =20 > please see comments inline. > =20 > Thanks, > =20 > Eric > =20 > =20 > On Dec 10, 2012, at 14:00 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" = wrote: >=20 >=20 > Hi all > =20 > About this long discussion on REQ2, I hereafter give some additional = comments =20 > =20 > 1) Regarding Lionel=92s remark, the fact to add related overload = AVPs to existing commands of a given Diameter application means these = AVPs are now part of the Diameter application which should deal with = them, so impacting the application. > =20 > On another side, in REQ13, piggybacking is mentioned as an example of = a solution for this REQ13 . With piggybacking, the message is only = used as transporter of the related overload AVPs. As messages from = different Diameter applications may be transferred over the same = connection, from my understanding, we may have a solution where the = overload AVPs are transported in any message of any application and = relate or are specific to the same Diameter application as the message = one or to another application or be application independent. Here can = we say these transported AVPs are sometimes part of the Diameter = Application and sometimes no? > =20 > Although this is a solution level discussion, it directly relates to = the REQ2 sentence: =93It MUST NOT require specification changes for = existing Diameter applications=94. > I am rather in favor of Lionel=92s remark and on the text he proposes. = When an AVP is conveyed in a command of an application, it is part of = this Diameter application. The same AVPs may be used by different = Diameter applications. Then it is a matter of implementation: these = overload AVPS or some of them may be processed by a separate = application-independent function in a node, so to minimize impact on = existing applications, but it is implementation. > =20 > =20 > I believe the requirements in this doc apply to the definition of a = standard for an overload control mechanism. They are not direct = requirements on any implementation that may follow that standard. This = is a key distinction. An implementation may do things that are not in a = standard and can still be compliant with that standard depending on how = the standard was crafted. > =20 > So, as I see it, these comments make sense when talking about = implementations and I am in agreement with them. However, the = requirements are about standards definition. I think for purposes of = discussion of req 2, we need to think in terms of application = implementation and application specification. Use of the unqualified = term 'application' is causing confusion, at least for me. > =20 >=20 >=20 > =20 > 2) In Req1 it is stated that the overload mechanism objective is = =93to provide a communication method =85to exchange the overload = information=94, so no more , no less from my understanding. Then there = are requirements on the Diameter node behaviors. I have no issue with = the many REQs for managing and optimizing well this information = exchange (eg REQ 9, 13, 14, 19=85) by nodes . It is another topic on how = the exchanged information is then used by nodes. I am also OK with the = REQs starting with =93the mechanism MUST allow nodes to =85 (REQ7) , = =93=85MUST provide a way to (REQ 22)=92 as we are still speaking of the = exchanged information which allows nodes to=85 . I think we should = also use this type of wording for a few requirements eg for REQ 7 =93the= mechanism must ensure that the system remains stable=94 as it is not = the exchanged information which stabilize the system, but the nodes = behavior on the basis of information exchanges. > =20 > that is a good point. I agree with changing req 7 like this. = Assuming others do as well, I'll look though for other examples at the = same time. >=20 >=20 > =20 > 3) This document does not address any overload algorithm which = will be key on how the exchanged information is then used by nodes. = =46rom a 3GPP angle, the approach ALU foresees is to use the Dime method = to exchange the overload information, eventually by extending the = information exchanged (REQ 33, 34), and to specify nodes behaviors = about overload handling according to the Diameter application = (corresponding to a 3GPP interface) and the overload algorithm. =20 > Eric=92s mail mentions a basic operation of an overload control = mechanism, which should correspond to an overload algorithm. Has Dime = the intent to specify some general overload algorithms? > =20 > Each of the current mechanism proposals in place have defined defaults = for algorithm and I think we're all on the same page that a minimal set = (one or two) should be supported as default. >=20 >=20 > =20 > 4) I remind the question of priority given to some users that = 3GPP will have to handle. Generally, it is the client that should = manages such priorities and signals it to the server but the = intermediate Diameter agents are not neutral there and should have the = relevant information to behave correctly (eg to not drop a message for a = priority user). On Req 26 ,we proposed an additional wording =93=93 For = example, it may be more beneficial to process messages for existing = sessions ahead of new sessions and to give priority to requests = associated with emergency sessions or with high priority users=94. Do = you think it is sufficient, or should we have a normative statement (not = only an example)? > =20 > I think that should be sufficient. If we start doing something = normative here, we restrict the flexibility of applications to define = their own behavior. do you think there are things we can do here that = will be in common for all possible applications? > =20 > =20 > [...] > = __________________________________________________________________________= _______________________________________________ >=20 > 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, > France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >=20 > 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, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. --Apple-Mail=_889D41A3-95CA-49C6-AC8A-570F5EB56814 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Lionel,

    I'm not arguing against changing the language = in req 2.  This discussion has made it quite clear that needs to = happen.

    The alternate proposals I have seen do = not say the same thing though and are weaker requirements.  It is = important for the resulting OC mechanism to work without requiring = changes to the specification of an application.  Perhaps you have a = better way of saying this.  For example, I would expect the OC = mechanism to work between an MME and HHS without touching 29.272. =  Can you propose alternate language that captures = this?

    Thanks!

    Eric
    =



    On Dec 11, 2012, at = 3:46 , lionel.morand@orange.com = wrote:

    Hi = Eric,
     
    Just on = this point:
    =93Use = of the unqualified term 'application' is causing confusion, at least for = me.=94
     
    As I said, = it is the use of =91specification=92 that causes confusion in = REQ2.
    I can understand that some new = folks may encounter some difficulties in understanding the wording used = in Diameter specifications e.g. RFC3588, RFC 6733, all the related RFCs = specifying Diameter =91applications=92 or even the title of the = draft Diameter = Applications Design Guidelines =85
    But I = don=92t think that it is a reason to change the definition or even = introduce more confusion.
     
    Based on = this discussion, I=92m more and more convinced that the correct wording = for the REQ2 should be something based on my = proposal:
     
    OLD:
     
       REQ 2:   The overload [control] = mechanism MUST be useable with any existing = or
              = ;  future Diameter application.  It MUST NOT = require
              = ;  specification changes for existing Diameter = applications.
     
    NEW:
     
       REQ 2:   The overload [control] = mechanism MUST be useable with any existing = or
              = ;  future Diameter application.  Support of this mechanism = over existing
              = ;  Diameter applications MUST NOT require major changes that would = lead
              = ;  to the need to define a new Diameter = application.
     
     
     
    De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Eric = McMurry
    Envoy=E9 : lundi 10 d=E9cembre 2012 = 21:43
    =C0 : TROTTIN, JEAN-JACQUES = (JEAN-JACQUES)
    Cc : dime@ietf.org
    Objet : Re: [Dime] Dime: Diameter = Overload IETF requirements, = review
    Hi = JJaques,
     
    Thanks,
     
    Eric
     
    On = Dec 10, 2012, at 14:00 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <Hi = all
    1)On = another side, in REQ13, piggybacking is mentioned as an example of a = solution for this REQ13 .  With  piggybacking, the message is = only used as transporter of the related overload AVPs.   As = messages from different Diameter applications may be transferred over = the same connection,  from my understanding, we may have a solution = where  the overload AVPs are transported in any message of any = application and relate or are specific to the same Diameter application = as the message one or to another application or be application = independent. Here  can we say these transported AVPs are sometimes =  part of the Diameter Application and sometimes no?
    Although this is a solution level =
discussion, it directly relates to the REQ2 sentence: =93It MUST NOT require specification changes for existing =
Diameter applications=94.I am rather in favor of Lionel=92s =
remark and on the text he proposes. When an AVP is conveyed in a command =
of an application, it is part of this Diameter application. The same =
AVPs may be used by different Diameter applications. Then it is a matter =
of implementation: these overload  AVPS or some of them may be =
processed by a separate application-independent function in a node, so =
to minimize  impact on existing applications, but it is =
implementation.I =
believe the requirements in this doc apply to the definition of a =
standard for an overload control mechanism.  They are not direct =
requirements on any implementation that may follow that standard. =
 This is a key distinction.  An implementation may do things =
that are not in a standard and can still be compliant with that standard =
depending on how the standard was =
crafted.
     
    2)In = Req1 it is stated that the overload mechanism objective is =93to provide = a communication method =85to exchange the overload information=94, so no = more , no less from my understanding.  Then there are requirements = on the Diameter node behaviors. I have  no issue with the many =  REQs for managing and optimizing well this information exchange = (eg REQ 9, 13, 14, 19=85) by nodes . It is another topic on how the = exchanged information is then used by nodes. I am also OK with the REQs = starting with =93the mechanism MUST allow nodes to =85 (REQ7) , =93=85MUST= provide a way to (REQ 22)=92 as we are still speaking of the exchanged = information  which  allows nodes to=85 . I think we should = also use this type of wording for a few requirements  eg for REQ 7 =  =93the mechanism  must ensure  that the system remains = stable=94 as it is not the exchanged information  which stabilize = the system, but the nodes behavior on the basis of information = exchanges.


    <14A53213-81F4-49B3-B7A2-62604921FD1F@computer.org> <8F944E58-0BD2-4B7D-98D8-7FC17A4C442A@computer.org> <16082_1355219212_50C7010C_16082_10054_1_6B7134B31289DC4FAF731D844122B36E0C280B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <251F43C5-9526-4855-98D9-4315EBF66E87@computer.org> In-Reply-To: <251F43C5-9526-4855-98D9-4315EBF66E87@computer.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E0C2D57PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 15:06:20 -0000 --_000_6B7134B31289DC4FAF731D844122B36E0C2D57PEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Eric, The way to document the support of the OC mechanisms in existing applicatio= ns is up to the people managing the document defining the given application= (IETF, 3GPP, other SDOs, vendors, etc.) and this can be done in various wa= ys. They can even decide to create a completely new application if it is pr= eferred. For me, it is out of the scope of the definition of the mechanism = itself and then not part of the requirement. >From a Diameter point of view, the important point is that the foreseen sol= ution has to be designed to be used along or over existing applications. An= d when used over existing applications, the required changes must not imply= the creation of a new application (as clarified in the proposal). The solu= tion designers can rely on the RFC 6733 and the draft Diameter Applications= Design Guidelines to see if the solution meets this requirement. Regards, Lionel De : Eric McMurry [mailto:emcmurry@computer.org] Envoy=E9 : mardi 11 d=E9cembre 2012 15:00 =C0 : MORAND Lionel OLNC/OLN Cc : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review Hi Lionel, I'm not arguing against changing the language in req 2. This discussion ha= s made it quite clear that needs to happen. The alternate proposals I have seen do not say the same thing though and ar= e weaker requirements. It is important for the resulting OC mechanism to w= ork without requiring changes to the specification of an application. Perh= aps you have a better way of saying this. For example, I would expect the = OC mechanism to work between an MME and HHS without touching 29.272. Can y= ou propose alternate language that captures this? Thanks! Eric On Dec 11, 2012, at 3:46 , lionel.morand@orange.com wrote: Hi Eric, Just on this point: "Use of the unqualified term 'application' is causing confusion, at least f= or me." As I said, it is the use of 'specification' that causes confusion in REQ2. I can understand that some new folks may encounter some difficulties in und= erstanding the wording used in Diameter specifications e.g. RFC3588, RFC 67= 33, all the related RFCs specifying Diameter 'applications' or even the tit= le of the draft Diameter Applications Design Guidelines ... But I don't think that it is a reason to change the definition or even intr= oduce more confusion. Based on this discussion, I'm more and more convinced that the correct word= ing for the REQ2 should be something based on my proposal: OLD: REQ 2: The overload [control] mechanism MUST be useable with any exist= ing or future Diameter application. It MUST NOT require specification changes for existing Diameter applications. NEW: REQ 2: The overload [control] mechanism MUST be useable with any exist= ing or future Diameter application. Support of this mechanism over ex= isting Diameter applications MUST NOT require major changes that would= lead to the need to define a new Diameter application. Regards, Lionel De : dime-bounces@ietf.org [mailto:dime-bounc= es@ietf.org] De la part de Eric McMurry Envoy=E9 : lundi 10 d=E9cembre 2012 21:43 =C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Cc : dime@ietf.org Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review Hi JJaques, please see comments inline. Thanks, Eric On Dec 10, 2012, at 14:00 , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" > wrote: Hi all About this long discussion on REQ2, I hereafter give some additional commen= ts 1) Regarding Lionel's remark, the fact to add related overload AVPs t= o existing commands of a given Diameter application means these AVPs are no= w part of the Diameter application which should deal with them, so impactin= g the application. On another side, in REQ13, piggybacking is mentioned as an example of a sol= ution for this REQ13 . With piggybacking, the message is only used as tra= nsporter of the related overload AVPs. As messages from different Diamete= r applications may be transferred over the same connection, from my unders= tanding, we may have a solution where the overload AVPs are transported in= any message of any application and relate or are specific to the same Diam= eter application as the message one or to another application or be applica= tion independent. Here can we say these transported AVPs are sometimes pa= rt of the Diameter Application and sometimes no? Although this is a solution level discussion, it directly relates to the RE= Q2 sentence: "It MUST NOT require specification changes for existing Diamet= er applications". I am rather in favor of Lionel's remark and on the text he proposes. When a= n AVP is conveyed in a command of an application, it is part of this Diamet= er application. The same AVPs may be used by different Diameter application= s. Then it is a matter of implementation: these overload AVPS or some of t= hem may be processed by a separate application-independent function in a no= de, so to minimize impact on existing applications, but it is implementati= on. I believe the requirements in this doc apply to the definition of a standar= d for an overload control mechanism. They are not direct requirements on a= ny implementation that may follow that standard. This is a key distinction= . An implementation may do things that are not in a standard and can still= be compliant with that standard depending on how the standard was crafted. So, as I see it, these comments make sense when talking about implementatio= ns and I am in agreement with them. However, the requirements are about st= andards definition. I think for purposes of discussion of req 2, we need t= o think in terms of application implementation and application specificatio= n. Use of the unqualified term 'application' is causing confusion, at leas= t for me. 2) In Req1 it is stated that the overload mechanism objective is "to p= rovide a communication method ...to exchange the overload information", so = no more , no less from my understanding. Then there are requirements on th= e Diameter node behaviors. I have no issue with the many REQs for managin= g and optimizing well this information exchange (eg REQ 9, 13, 14, 19...) b= y nodes . It is another topic on how the exchanged information is then used= by nodes. I am also OK with the REQs starting with "the mechanism MUST all= ow nodes to ... (REQ7) , "...MUST provide a way to (REQ 22)' as we are stil= l speaking of the exchanged information which allows nodes to... . I thin= k we should also use this type of wording for a few requirements eg for RE= Q 7 "the mechanism must ensure that the system remains stable" as it is = not the exchanged information which stabilize the system, but the nodes be= havior on the basis of information exchanges. that is a good point. I agree with changing req 7 like this. Assuming oth= ers do as well, I'll look though for other examples at the same time. 3) This document does not address any overload algorithm which will be= key on how the exchanged information is then used by nodes. From a 3GPP = angle, the approach ALU foresees is to use the Dime method to exchange the = overload information, eventually by extending the information exchanged (RE= Q 33, 34), and to specify nodes behaviors about overload handling accordi= ng to the Diameter application (corresponding to a 3GPP interface) and the = overload algorithm. Eric's mail mentions a basic operation of an overload control mechanism, wh= ich should correspond to an overload algorithm. Has Dime the intent to spec= ify some general overload algorithms? Each of the current mechanism proposals in place have defined defaults for = algorithm and I think we're all on the same page that a minimal set (one or= two) should be supported as default. 4) I remind the question of priority given to some users that 3GPP wi= ll have to handle. Generally, it is the client that should manages such pr= iorities and signals it to the server but the intermediate Diameter agents = are not neutral there and should have the relevant information to behave co= rrectly (eg to not drop a message for a priority user). On Req 26 ,we propo= sed an additional wording "" For example, it may be more beneficial to pro= cess messages for existing sessions ahead of new sessions and to give prior= ity to requests associated with emergency sessions or with high priority us= ers". Do you think it is sufficient, or should we have a normative statemen= t (not only an example)? I think that should be sufficient. If we start doing something normative h= ere, we restrict the flexibility of applications to define their own behavi= or. do you think there are things we can do here that will be in common fo= r all possible applications? [...] ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E0C2D57PEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Hi Eric,

     

    The way to document the support of the OC mechanisms in exis= ting applications is up to the people managing the document defining the gi= ven application (IETF, 3GPP, other SDOs, vendors, etc.) and this can be done in various wa= ys. They can even decide to create a completely new application if it is pr= eferred. For me, it is out of the scope of the definition of the mechanism = itself and then not part of the requirement.

     

    From a Diameter point of view, the important point is that t= he foreseen solution has to be designed to be used along or over existing a= pplications. And when used over existing applications, the required changes must not im= ply the creation of a new application (as clarified in the proposal). The s= olution designers can rely on the RFC 6733 and the draft Diameter Applications Design Guidelines to see if the solution meets this requirement.

     

    Regards,

     

    Lionel =

     

    De : Eric= McMurry [mailto:emcmurry@computer.org]
    Envoy=E9 : mardi 11 d=E9cembre 2012 15:00
    =C0 : MORAND Lionel OLNC/OLN
    Cc : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
    Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, r= eview

     

    Hi Lionel,

     

    I'm not arguing against changing the language in req= 2.  This discussion has made it quite clear that needs to happen.

     

    The alternate proposals I have seen do not say the s= ame thing though and are weaker requirements.  It is important for the= resulting OC mechanism to work without requiring changes to the specificat= ion of an application.  Perhaps you have a better way of saying this.  For example, I would expect the OC mech= anism to work between an MME and HHS without touching 29.272.  Can you= propose alternate language that captures this?

     

    Thanks!

     

    Eric

     

     

     

    On Dec 11, 2012, at 3:46 , lionel.morand@orange.com wrote:



    Hi Eric,

     

    Just on this point:

    “Use of the unqualified te= rm 'application' is causing confusion, at least for me.”

     

    As I said, it is the use of ‘specification’ that= causes confusion in REQ2.

    I can understand that some new folks may encounter some diff= iculties in understanding the wording used in Diameter specifications e.g. = RFC3588, RFC 6733, all the related RFCs specifying Diameter ‘applicationsR= 17; or even the title of the draft&nb= sp;Diameter Applications Design Guidelines …

    But I don’t think that it is a reason to change the de= finition or even introduce more confusion.

     

    Based on this discussion, I’m more and more convinced = that the correct wording for the REQ2 should be something based on my propo= sal:

     

    OLD:

     

       REQ 2:   The overload [control] mec= hanism MUST be useable with any existing or

             &nbs= p;  future Diameter application.  It MUST NOT require

             &nbs= p;  specification changes for existing Diameter applications.

     

    NEW:

     

       REQ 2:   The overload [control] mec= hanism MUST be useable with any existing or

             &nbs= p;  future Diameter application.  Support of this mechanism over = existing<= /o:p>

             &nbs= p;  Diameter applications MUST NOT require major changes that would le= ad<= /span>

             &nbs= p;  to the need to define a new Diameter application.

     

    Regards,

     

    Lionel

     

     

    De : dime-bounces@ie= tf.org [mailto= :dime-boun= ces@ietf.org] = De la part de Eric McMu= rry
    Envoy=E9 : lu= ndi 10 d=E9cembre 2012 21:43
    =C0 : TROTTIN= , JEAN-JACQUES (JEAN-JACQUES)
    Cc : dime@ietf.org=
    Objet : Re: [= Dime] Dime: Diameter Overload IETF requirements, review

     

    Hi JJaques,

     

    please see comments inline.

     

    Thanks,

     

    Eric

     

     

    On Dec 10, 2012, at 14:00 , "TROTTIN, JEAN-JACQ= UES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-luce= nt.com> wrote:




    Hi all

     

    About this long discussion on REQ2, I hereafter give some ad= ditional comments  

     

    1)      Regarding Lionel’s remark,  the fact to add related overload AVPs to exis= ting commands of a given Diameter application means these AVPs are now part= of the Diameter application which should deal with them, so impacting the = application.

     

    On another side, in REQ13, piggybacking is mentio=
ned as an example of a solution for this REQ13 .  With  piggyback=
ing, the message is only used as transporter of the related overload AVPs. =
  As messages from different Diameter applications may be transfe=
rred over the same connection,  from my understanding, we may have a s=
olution where  the overload AVPs are transported in any message of any=
 application and relate or are specific to the same Diameter application as=
 the message one or to another application or be application independent. H=
ere  can we say these transported AVPs are sometimes  part of the=
 Diameter Application and sometimes no?
     
    Although this is a solution level discussion, it =
directly relates to the REQ2 sentence: “It M=
UST NOT require specification changes for existing Diameter applications=
221;.
    I am rather in favor of Lionel’s remark and=
 on the text he proposes. When an AVP is conveyed in a command of an applic=
ation, it is part of this Diameter application. The same AVPs may be used b=
y different Diameter applications. Then it is a matter of implementation: t=
hese overload  AVPS or some of them may be processed by a separate app=
lication-independent function in a node, so to minimize  impact on exi=
sting applications, but it is implementation.

     

     

    I believe the requirements in this doc apply to the = definition of a standard for an overload control mechanism.  They are = not direct requirements on any implementation that may follow that standard= .  This is a key distinction.  An implementation may do things that are not in a standard and can still be compliant with t= hat standard depending on how the standard was crafted.

     

    So, as I see it, these comments make sense when talk= ing about implementations and I am in agreement with them.  However, t= he requirements are about standards definition.  I think for purposes = of discussion of req 2, we need to think in terms of application implementation and application specification.  U= se of the unqualified term 'application' is causing confusion, at least for= me.

     




    

    

    2)&n=
bsp;     In
 Req1 it is stated that the overload mechanism objective is “to provi=
de a communication method …to exchange the overload information”=
;, so no more , no less from my understanding.  Then there are require=
ments on the Diameter node behaviors. I have  no issue
 with the many  REQs for managing and optimizing well this information=
 exchange (eg REQ 9, 13, 14, 19…) by nodes . It is another topic on h=
ow the exchanged information is then used by nodes. I am also OK with the R=
EQs starting with “the mechanism MUST allow
 nodes to … (REQ7) , “…MUST provide a way to (REQ 22)R=
17; as we are still speaking of the exchanged information  which  =
;allows nodes to… . I think we should also use this type of wording f=
or a few requirements  eg for REQ 7  “the mechanism  m=
ust ensure  that the
 system remains stable” as it is not the exchanged information  =
which stabilize the system, but the nodes behavior on the basis of informat=
ion exchanges.

     

    that is a good point.  I agree with changing re= q 7 like this.  Assuming others do as well, I'll look though for other= examples at the same time.




     

    3)&n= bsp;     This document does not address any overload algorithm which will be key on how = the exchanged information is then used by nodes.   From a 3GPP an= gle, the approach ALU foresees is to use the Dime method to exchange the ov= erload information, eventually by extending the information exchanged (REQ 33, 34),   and to specify nodes b= ehaviors about overload handling according to the Diameter application (cor= responding to a 3GPP interface) and the overload algorithm.  

    Eric’s mail mentions a basic operation of an overload = control mechanism, which should correspond to an overload algorithm. Has Di= me the intent to specify some general overload algorithms?

     

    Each of the current mechanism proposals in place hav= e defined defaults for algorithm and I think we're all on the same page tha= t a minimal set (one or two) should be supported as default.




     

    4)&n= bsp;     I remind the question of priority  given to some users that 3GPP will h= ave to handle. Generally, it is the client that should  manages such p= riorities and signals it to the server but the intermediate Diameter agents= are not neutral there and should have the relevant information to behave correctly (eg to not drop a message for a p= riority user). On Req 26 ,we proposed  an additional wording ““ For example, it may be more beneficial to process messages for ex= isting sessions ahead of new sessions = and to give priority to requests associated with emergency sessions or with high = priority users”. = Do you think it is sufficient, or should we have a normative statement (not only an example)?

     

    I think that should be sufficient.  If we start= doing something normative here, we restrict the flexibility of application= s to define their own behavior.  do you think there are things we can = do here that will be in common for all possible applications?

     

     

    [...]

    ______________________________________________________________________=
___________________________________________________
     
    Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
    France Telecom - Orange decline toute responsabilite si ce message a e=
te altere, deforme ou falsifie. Merci.
     
    This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
    they should not be distributed, used or copied without authorisation.<=
o:p>
    If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
    As emails may be altered, France Telecom - Orange is not liable for me=
ssages that have been modified, changed or falsified.
    Thank you.

     

    ______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
    --_000_6B7134B31289DC4FAF731D844122B36E0C2D57PEXCVZYM13corpora_-- From emcmurry@computer.org Tue Dec 11 07:39:48 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7801221F84C9 for ; Tue, 11 Dec 2012 07:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttsHvklnqCEQ for ; Tue, 11 Dec 2012 07:39:47 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id BC75721F87AD for ; Tue, 11 Dec 2012 07:39:47 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1TiRvv-0001m1-AF; Tue, 11 Dec 2012 15:39:47 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id EA672B10CB2; Tue, 11 Dec 2012 09:39:43 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/vP7wNdsZB3+42vB+xO3Q3Q2Mtd8ivmsU= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kd3-Mxd-1OaF; Tue, 11 Dec 2012 09:39:43 -0600 (CST) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id AEB70B10C9E; Tue, 11 Dec 2012 09:39:43 -0600 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_CAAE2815-664A-4391-B397-CFF2ABEA1EE1" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric McMurry In-Reply-To: <17021_1355238371_50C74BE3_17021_468_22_6B7134B31289DC4FAF731D844122B36E0C2D57@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 11 Dec 2012 09:39:41 -0600 Message-Id: <668202E6-DF0C-4261-B85C-DB17D6297EF1@computer.org> References: <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> <28892_1354818749_50C0E4BD_28892_4479_1_6B7134B31289DC4FAF731D844122B36E0BF868@PEXCVZYM13.corporate.adroot.infra.ftgroup> <81E2AD4F-9FED-498D-ACA2-538C6ED53B7E@computer.org> <13633_1354873372_50C1BA1C_13633_2361_1_6B7134B31289DC4FAF731D844122B36E0C0056@PEXCVZYM13.corporate.adroot.infra.ftgroup> <724F2D49-4B1F-416D-BF94-F46C3DDC02EF@nostrum.com> <16364_1354893872_50C20A30_16364_5192_1_6B7134B31289DC4FAF731D844122B36E0C0699@PEXCVZYM13.corporate.adroot.infra.ftgroup> <18AC9DCE-8C27-43AB-AE3E-CBB913A471A7@nostrum.com> <5614_1354897191_50C21727_5614_8583_1_6B7134B31289DC4FAF731D844122B36E0C0756@PEXCVZYM13.corporate.adroot.infra.ftgroup> <50C2B121.6010508@gmail.com> <"170E8F C C2134BD42B539B47798ABF8F026C0C43F5B"@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <14A53213-81F4-49B3-B7A2-62604921FD1F@computer.org> <8F944E58-0BD2-4B7D-98D8-7FC17A4C442A@computer.org> <16082_1355219212_50C7010C_16082_10054_1_6B7134B31289DC4FAF731D844122B36E0C280B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <251F43C5-9526-4855-98D9-4315EBF66E87@computer.org> <17021_1355238371_50C74BE3_17021_468_22_6B7134B31289DC4FAF731D844122B36E0C2D57@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1499) Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 15:39:48 -0000 --Apple-Mail=_CAAE2815-664A-4391-B397-CFF2ABEA1EE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Lionel, Please see inline.=20 Thanks, Eric On Dec 11, 2012, at 9:06 , lionel.morand@orange.com wrote: > Hi Eric, > =20 > The way to document the support of the OC mechanisms in existing = applications is up to the people managing the document defining the = given application (IETF, 3GPP, other SDOs, vendors, etc.) and this can = be done in various ways. They can even decide to create a completely new = application if it is preferred. For me, it is out of the scope of the = definition of the mechanism itself and then not part of the requirement. > =20 of course. I am not proposing any restrictions on how application = specifications are updated. > =46rom a Diameter point of view, the important point is that the = foreseen solution has to be designed to be used along or over existing = applications. And when used over existing applications, the required = changes must not imply the creation of a new application (as clarified = in the proposal). The solution designers can rely on the RFC 6733 and = the draft Diameter Applications Design Guidelines to see if the solution = meets this requirement. I am not making my point clear. I see the important point being that = the specification of existing applications do not have to be updated at = all. This includes your point, but is a stricter requirement. It would = be possible to design an OC mechanism that met your requirement that = still required changes to the specification of existing applications. --Apple-Mail=_CAAE2815-664A-4391-B397-CFF2ABEA1EE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 lionel.morand@orange.com = ;wrote:

    Hi Eric,
     
    The way to = document the support of the OC mechanisms in existing applications is up = to the people managing the document defining the given application = (IETF, 3GPP, other SDOs, vendors, etc.) and this can be done in various = ways. They can even decide to create a completely new application if it = is preferred. For me, it is out of the scope of the definition of the = mechanism itself and then not part of the = requirement.
    =46rom = a Diameter point of view, the important point is that the foreseen = solution has to be designed to be used along or over existing = applications. And when used over existing applications, the required = changes must not imply the creation of a new application (as clarified = in the proposal). The solution designers can rely on the RFC 6733 and = the draft Diameter Applications Design = Guidelines to see if the solution meets this = requirement.


    =
    I am not making my point clear.  I see the important = point being that the specification of  existing applications do not = have to be updated at all.  This includes your point, but is a = stricter requirement.  It would be possible to design an OC = mechanism that met your requirement that still required changes to the = specification of existing = applications.

    = --Apple-Mail=_CAAE2815-664A-4391-B397-CFF2ABEA1EE1-- From lionel.morand@orange.com Tue Dec 11 08:17:53 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F281921F8552 for ; Tue, 11 Dec 2012 08:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VL-4xPW+bpU for ; Tue, 11 Dec 2012 08:17:50 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E88CF21F853A for ; Tue, 11 Dec 2012 08:17:49 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 05BE1264270; Tue, 11 Dec 2012 17:17:49 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id D567223804B; Tue, 11 Dec 2012 17:17:48 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Tue, 11 Dec 2012 17:17:48 +0100 From: To: Eric McMurry Thread-Topic: [Dime] Dime: Diameter Overload IETF requirements, review Thread-Index: AQHN17W8LitkaeLo50W5NCjYYNM+uZgTw57w Date: Tue, 11 Dec 2012 16:17:47 +0000 Message-ID: <22934_1355242668_50C75CAC_22934_4017_1_6B7134B31289DC4FAF731D844122B36E0C2ED3@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> <28892_1354818749_50C0E4BD_28892_4479_1_6B7134B31289DC4FAF731D844122B36E0BF868@PEXCVZYM13.corporate.adroot.infra.ftgroup> <81E2AD4F-9FED-498D-ACA2-538C6ED53B7E@computer.org> <13633_1354873372_50C1BA1C_13633_2361_1_6B7134B31289DC4FAF731D844122B36E0C0056@PEXCVZYM13.corporate.adroot.infra.ftgroup> <724F2D49-4B1F-416D-BF94-F46C3DDC02EF@nostrum.com> <16364_1354893872_50C20A30_16364_5192_1_6B7134B31289DC4FAF731D844122B36E0C0699@PEXCVZYM13.corporate.adroot.infra.ftgroup> <18AC9DCE-8C27-43AB-AE3E-CBB913A471A7@nostrum.com> <5614_1354897191_50C21727_5614_8583_1_6B7134B31289DC4FAF731D844122B36E0C0756@PEXCVZYM13.corporate.adroot.infra.ftgroup> <50C2B121.6010508@gmail.com> <"170E8F C C2134BD42B539B47798ABF8F026C0C43F5B"@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <14A53213-81F4-49B3-B7A2-62604921FD1F@computer.org> <8F944E58-0BD2-4B7D-98D8-7FC17A4C442A@computer.org> <16082_1355219212_50C7010C_16082_10054_1_6B7134B31289DC4FAF731D844122B36E0C280B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <251F43C5-9526-4855-98D9-4315EBF66E87@computer.org> <17021_1355238371_50C74BE3_17021_468_22_6B7134B31289DC4FAF731D844122B36E0C2D57@PEXCVZYM13.corporate.adroot.infra.ftgroup> <668202E6-DF0C-4261-B85C-DB17D6297EF1@computer.org> In-Reply-To: <668202E6-DF0C-4261-B85C-DB17D6297EF1@computer.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E0C2ED3PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.11.150618 Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 16:17:53 -0000 --_000_6B7134B31289DC4FAF731D844122B36E0C2ED3PEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Eric, It is where I'm lost in your argumentation. If the specification of the app= lication is not updated at all, how do you want to reflect that the OC mech= anism is now supported over this application? Again, I think that the requirement is that any agent supporting the existi= ng application should not have to be forced to be upgraded when introducing= the new OC mechanism. Only the client, server and/or dedicated proxies hav= e to be upgraded to support the new functionality. And how to document that is out of scope. It could be a reference to a comp= anion document, addition of extra informative text, etc. But we should not = mix both aspects here. Only the requirements at the protocol level are rele= vant in this draft. Lionel De : Eric McMurry [mailto:emcmurry@computer.org] Envoy=E9 : mardi 11 d=E9cembre 2012 16:40 =C0 : MORAND Lionel OLNC/OLN Cc : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review Hi Lionel, Please see inline. Thanks, Eric On Dec 11, 2012, at 9:06 , lionel.morand@orange.com wrote: Hi Eric, The way to document the support of the OC mechanisms in existing applicatio= ns is up to the people managing the document defining the given application= (IETF, 3GPP, other SDOs, vendors, etc.) and this can be done in various wa= ys. They can even decide to create a completely new application if it is pr= eferred. For me, it is out of the scope of the definition of the mechanism = itself and then not part of the requirement. of course. I am not proposing any restrictions on how application specific= ations are updated. >From a Diameter point of view, the important point is that the foreseen sol= ution has to be designed to be used along or over existing applications. An= d when used over existing applications, the required changes must not imply= the creation of a new application (as clarified in the proposal). The solu= tion designers can rely on the RFC 6733 and the draft Diameter Applications= Design Guidelines to see if the solution meets this requirement. I am not making my point clear. I see the important point being that the s= pecification of existing applications do not have to be updated at all. T= his includes your point, but is a stricter requirement. It would be possib= le to design an OC mechanism that met your requirement that still required = changes to the specification of existing applications. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E0C2ED3PEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Hi Eric,

     

    It is where I’m lost in your argumentation. If the spe= cification of the application is not updated at all, how do you want to ref= lect that the OC mechanism is now supported over this application?

     

    Again, I think that the requirement is that any agent suppor= ting the existing application should not have to be forced to be upgraded w= hen introducing the new OC mechanism. Only the client, server and/or dedicated proxies hav= e to be upgraded to support the new functionality.

     

    And how to document that is out of scope. It could be a refe= rence to a companion document, addition of extra informative text, etc. But= we should not mix both aspects here. Only the requirements at the protocol level are= relevant in this draft.

     

    Lionel

     

    De : Eric= McMurry [mailto:emcmurry@computer.org]
    Envoy=E9 : mardi 11 d=E9cembre 2012 16:40
    =C0 : MORAND Lionel OLNC/OLN
    Cc : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
    Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, r= eview

     

     

    Hi Lionel,

     

    Please see inline. 

     

    Thanks,

     

    Eric

     

     

    On Dec 11, 2012, at 9:06 , lionel.morand@orange.com wrote:=



    Hi Eric,

     

    The way to document the support of the OC mechanisms in exis= ting applications is up to the people managing the document defining the gi= ven application (IETF, 3GPP, other SDOs, vendors, etc.) and this can be done in various wa= ys. They can even decide to create a completely new application if it is pr= eferred. For me, it is out of the scope of the definition of the mechanism = itself and then not part of the requirement.

     

     

    of course.  I am not proposing any restrictions= on how application specifications are updated.



    From a Diameter point of view, the important point is that t= he foreseen solution has to be designed to be used along or over existing a= pplications. And when used over existing applications, the required changes must not im= ply the creation of a new application (as clarified in the proposal). The s= olution designers can rely on the RFC 6733 and the draft Diameter Applications Design Guidelines to see if the solution meet= s this requirement.

     

     

    I am not making my point clear.  I see the impo= rtant point being that the specification of  existing applications do = not have to be updated at all.  This includes your point, but is a str= icter requirement.  It would be possible to design an OC mechanism that met your requirement that still required changes to t= he specification of existing applications.

     

    ______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
    --_000_6B7134B31289DC4FAF731D844122B36E0C2ED3PEXCVZYM13corpora_-- From emcmurry@computer.org Tue Dec 11 09:11:29 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDD821F885B for ; Tue, 11 Dec 2012 09:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oX3S6RpSrJjd for ; Tue, 11 Dec 2012 09:11:28 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 40E9E21F877B for ; Tue, 11 Dec 2012 09:11:28 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1TiTMW-000LLb-LZ; Tue, 11 Dec 2012 17:11:20 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 0FFB6B11BE3; Tue, 11 Dec 2012 11:11:04 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/DjoH624rf8u5o8cWV05LBVkYHCaQZSBI= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gm3sG6XMGjq0; Tue, 11 Dec 2012 11:11:03 -0600 (CST) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id AC89FB11BCC; Tue, 11 Dec 2012 11:11:03 -0600 (CST) Content-Type: multipart/alternative; boundary="Apple-Mail=_81E00B5E-E045-4AE8-8636-FCCC382F04BA" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric McMurry In-Reply-To: <22934_1355242668_50C75CAC_22934_4017_1_6B7134B31289DC4FAF731D844122B36E0C2ED3@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 11 Dec 2012 11:11:02 -0600 Message-Id: <921F02FF-0716-4C24-91EE-EEF8DA595857@computer.org> References: <7AE8BAB4-ACB6-40EA-BA50-E6DA909D01E7@nostrum.com> <28892_1354816236_50C0DAEC_28892_2267_1_6B7134B31289DC4FAF731D844122B36E0BF7AD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26F4B824-A91B-4D98-9E1F-41A5440C6C45@computer.org> <28892_1354818749_50C0E4BD_28892_4479_1_6B7134B31289DC4FAF731D844122B36E0BF868@PEXCVZYM13.corporate.adroot.infra.ftgroup> <81E2AD4F-9FED-498D-ACA2-538C6ED53B7E@computer.org> <13633_1354873372_50C1BA1C_13633_2361_1_6B7134B31289DC4FAF731D844122B36E0C0056@PEXCVZYM13.corporate.adroot.infra.ftgroup> <724F2D49-4B1F-416D-BF94-F46C3DDC02EF@nostrum.com> <16364_1354893872_50C20A30_16364_5192_1_6B7134B31289DC4FAF731D844122B36E0C0699@PEXCVZYM13.corporate.adroot.infra.ftgroup> <18AC9DCE-8C27-43AB-AE3E-CBB913A471A7@nostrum.com> <5614_1354897191_50C21727_5614_8583_1_6B7134B31289DC4FAF731D844122B36E0C0756@PEXCVZYM13.corporate.adroot.infra.ftgroup> <50C2B121.6010508@gmail.com> <"170E8F C C2134BD42B539B47798ABF8F026C0C43F5B"@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> <14A53213-81F4-49B3-B7A2-62604921FD1F@computer.org> <8F944E58-0BD2-4B7D-98D8-7FC17A4C442A@computer.org> <16082_1355219212_50C7010C_16082_10054_1_6B7134B31289DC4FAF731D844122B36E0C280B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <251F43C5-9526-4855-98D9-4315EBF66E87@computer.org> <17021_1355238371_50C74BE3_17021_468_22_6B7134B31289DC4FAF731D844122B36E0C2D57@PEXCVZYM13.corporate.adroot.infra.ftgroup> <668202E6-DF0C-4261-B85C-DB17D6297EF1@computer.org> <22934_1355242668_50C75CAC_22934_4017_1_6B7134B31289DC4FAF731D844122B36E0C2ED3@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1499) Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 17:11:29 -0000 --Apple-Mail=_81E00B5E-E045-4AE8-8636-FCCC382F04BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Lionel, I think the OC mechanism can not claim support over any particular = application. It needs to be application independent and should work = with any application. I'm not seeing that reflecting that the OC = mechanism is supported over an application is necessary. To your second point, I think this is orthogonal to req 2. There are = requirements around the OC mechanism supporting a mixed environment of = supporting and non-supporting elements. I don't think this is exactly = what you are saying, but is related. Do you think there is a need for a = new requirement here? I agree that how to change any application specs is out of scope. That = is what I was trying to say with my first comment. Thanks, Eric On Dec 11, 2012, at 10:17 , lionel.morand@orange.com wrote: > Hi Eric, > =20 > It is where I=92m lost in your argumentation. If the specification of = the application is not updated at all, how do you want to reflect that = the OC mechanism is now supported over this application? > =20 > Again, I think that the requirement is that any agent supporting the = existing application should not have to be forced to be upgraded when = introducing the new OC mechanism. Only the client, server and/or = dedicated proxies have to be upgraded to support the new functionality. > =20 > And how to document that is out of scope. It could be a reference to a = companion document, addition of extra informative text, etc. But we = should not mix both aspects here. Only the requirements at the protocol = level are relevant in this draft. > =20 > Lionel > =20 > De : Eric McMurry [mailto:emcmurry@computer.org]=20 > Envoy=E9 : mardi 11 d=E9cembre 2012 16:40 > =C0 : MORAND Lionel OLNC/OLN > Cc : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org > Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review > =20 > =20 > Hi Lionel, > =20 > Please see inline.=20 > =20 > Thanks, > =20 > Eric > =20 > =20 > On Dec 11, 2012, at 9:06 , lionel.morand@orange.com wrote: >=20 >=20 > Hi Eric, > =20 > The way to document the support of the OC mechanisms in existing = applications is up to the people managing the document defining the = given application (IETF, 3GPP, other SDOs, vendors, etc.) and this can = be done in various ways. They can even decide to create a completely new = application if it is preferred. For me, it is out of the scope of the = definition of the mechanism itself and then not part of the requirement. > =20 > =20 > of course. I am not proposing any restrictions on how application = specifications are updated. >=20 >=20 > =46rom a Diameter point of view, the important point is that the = foreseen solution has to be designed to be used along or over existing = applications. And when used over existing applications, the required = changes must not imply the creation of a new application (as clarified = in the proposal). The solution designers can rely on the RFC 6733 and = the draft Diameter Applications Design Guidelines to see if the solution = meets this requirement. > =20 > =20 > I am not making my point clear. I see the important point being that = the specification of existing applications do not have to be updated at = all. This includes your point, but is a stricter requirement. It would = be possible to design an OC mechanism that met your requirement that = still required changes to the specification of existing applications. > =20 > = __________________________________________________________________________= _______________________________________________ >=20 > 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, > France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >=20 > 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, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. --Apple-Mail=_81E00B5E-E045-4AE8-8636-FCCC382F04BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Lionel,

    I think the OC mechanism can not claim = support over any particular application.  It needs to be = application independent and should work with any application.  I'm = not seeing that reflecting that the OC mechanism is supported over an = application is necessary.

    To your second point, = I think this is orthogonal to req 2.  There are requirements around = the OC mechanism supporting a mixed environment of supporting and = non-supporting elements.  I don't think this is exactly what you = are saying, but is related.  Do you think there is a need for a new = requirement here?

    I agree that how to change = any application specs is out of scope.  That is what I was trying = to say with my first = comment.

    Thanks,

    Eric




    On = Dec 11, 2012, at 10:17 , lionel.morand@orange.com = wrote:

    Hi = Eric,
     
    It is where I=92m lost in your = argumentation. If the specification of the application is not updated at = all, how do you want to reflect that the OC mechanism is now supported = over this application?
     
    Again, I = think that the requirement is that any agent supporting the existing = application should not have to be forced to be upgraded when introducing = the new OC mechanism. Only the client, server and/or dedicated proxies = have to be upgraded to support the new = functionality.
     
    And how to = document that is out of scope. It could be a reference to a companion = document, addition of extra informative text, etc. But we should not mix = both aspects here. Only the requirements at the protocol level are = relevant in this draft.
     
     
    De : Eric McMurry = [mailto:emcmurry@computer.org] 
    Envoy=E9 :     mardi 11 d=E9cembre 2012 = 16:40
    =C0 : MORAND Lionel = OLNC/OLN
    Cc : TROTTIN, JEAN-JACQUES = (JEAN-JACQUES); dime@ietf.org
    Objet : Re: [Dime] Dime: Diameter = Overload IETF requirements, = review
    Hi = Lionel,
     
    Thanks,
     
    Eric
     
    On = Dec 11, 2012, at 9:06 , 



    I am = not making my point clear.  I see the important point being that = the specification of  existing applications do not have to be = updated at all.  This includes your point, but is a stricter = requirement.  It would be possible to design an OC mechanism that = met your requirement that still required changes to the specification of = existing applications.
    <14A53213-81F4-49B3-B7A2-62604921FD1F@computer.org> <8F944E58-0BD2-4B7D-98D8-7FC17A4C442A@computer.org> <16082_1355219212_50C7010C_16082_10054_1_6B7134B31289DC4FAF731D844122B36E0C280B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <251F43C5-9526-4855-98D9-4315EBF66E87@computer.org> <17021_1355238371_50C74BE3_17021_468_22_6B7134B31289DC4FAF731D844122B36E0C2D57@PEXCVZYM13.corporate.adroot.infra.ftgroup> <668202E6-DF0C-4261-B85C-DB17D6297EF1@computer.org> <22934_1355242668_50C75CAC_22934_4017_1_6B7134B31289DC4FAF731D844122B36E0C2ED3@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 22:23:03 -0000 Hi Lionel, see comments inline: On Dec 11, 2012, at 10:17 AM, lionel.morand@orange.com wrote: > Hi Eric, > =20 > It is where I=92m lost in your argumentation. If the specification of = the application is not updated at all, how do you want to reflect that = the OC mechanism is now supported over this application? > =20 You don't, at least not at the specification level. (An implementation = might allow one to select whether OC is in effect for any given = application, but that's an orthogonal issue). We've intended "application independence" to be a goal for the OC = mechanism from the beginning. Maybe it's worth exploring what that = means. The idea is that you don't have to decide (or document) whether OC is = supported for a particular application. You can use it across all = applications that a particular node supports. Now, that doesn't mean you = can't add application specific algorithm optimizations, or describe = specific application-level behaviors (e.g. request prioritization ) for = overload conditions. But the idea is that you don't _have_ to do that in = general. The discussion about documentation so far is really more of a process = question than a technical question. We want to make it possible to = deploy OC for a given application without having to revise the specs = (IETF RFCs, 3GPP TSs, etc) for that application. We do that by defining = default behavior that we expect to be at least useful in most cases. = That is, we don't leave sections that "MUST be described in the Diameter = application specification"=20 I believe this is possible using either the piggy-back model or the = dedicated application model. In the piggy-back case, we document OC AVPs = that can be used with _any_ application that includes the *[AVP] = construct. Any implementation that doesn't understand the OC mechanism = would simply fail to negotiate use of the mechanism, and ignore any OC = negotiation AVPs that occur in the CER. This does not require any change = to the original application specification, since the *[AVP] construct = means compliant implementations can handle (or at least ignore) = arbitrary AVPs without damage. In the dedicated application case, if you successfully negotiate support = for the OC application in the CER/CEA exchange, you can start sharing OC = info. Implementations can apply that info to messages in any = application, without requiring changes to the definition of that = application. We recognize that people may want to revise application definition specs = to describe application-specific OC behaviors. But they shouldn't have = to do so to use the default behaviors.. > Again, I think that the requirement is that any agent supporting the = existing application should not have to be forced to be upgraded when = introducing the new OC mechanism. Only the client, server and/or = dedicated proxies have to be upgraded to support the new functionality. That's a different requirement than the one intended by Req 2. (Nothing = in Req 2 should be interpreted to say you don't need to update = _software_). I think it will be a hard one to achieve, except possibly = in the case of pure relay agents (which I'm still not convinced exist in = the wild.). Proxy agents will certainly need to implement OC support for = OC to be useful. Hopefully section 2 illustrates why that is the = case--if not, it may need some clarification. > =20 > And how to document that is out of scope. It could be a reference to a = companion document, addition of extra informative text, etc. But we = should not mix both aspects here. Only the requirements at the protocol = level are relevant in this draft. I agree that this draft doesn't need to say how application-specific OC = support gets documented for any specific application. (The mechanism = draft(s) _might_ need to do so for some circumstances, but I don't think = we are far enough along on those to know one way or another.)=20 I disagree that protocol requirements are all that's relevant in the = this draft, as I think Req 2 is implied by the very idea of = application-independence. (OTOH, maybe we could restate it in terms of = application independence rather than documentation--but the implication = would remain.) > =20 > Lionel > =20 > De : Eric McMurry [mailto:emcmurry@computer.org]=20 > Envoy=E9 : mardi 11 d=E9cembre 2012 16:40 > =C0 : MORAND Lionel OLNC/OLN > Cc : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org > Objet : Re: [Dime] Dime: Diameter Overload IETF requirements, review > =20 > =20 > Hi Lionel, > =20 > Please see inline.=20 > =20 > Thanks, > =20 > Eric > =20 > =20 > On Dec 11, 2012, at 9:06 , lionel.morand@orange.com wrote: >=20 >=20 > Hi Eric, > =20 > The way to document the support of the OC mechanisms in existing = applications is up to the people managing the document defining the = given application (IETF, 3GPP, other SDOs, vendors, etc.) and this can = be done in various ways. They can even decide to create a completely new = application if it is preferred. For me, it is out of the scope of the = definition of the mechanism itself and then not part of the requirement. > =20 > =20 > of course. I am not proposing any restrictions on how application = specifications are updated. >=20 >=20 > =46rom a Diameter point of view, the important point is that the = foreseen solution has to be designed to be used along or over existing = applications. And when used over existing applications, the required = changes must not imply the creation of a new application (as clarified = in the proposal). The solution designers can rely on the RFC 6733 and = the draft Diameter Applications Design Guidelines to see if the solution = meets this requirement. > =20 > =20 > I am not making my point clear. I see the important point being that = the specification of existing applications do not have to be updated at = all. This includes your point, but is a stricter requirement. It would = be possible to design an OC mechanism that met your requirement that = still required changes to the specification of existing applications. > =20 > = __________________________________________________________________________= _______________________________________________ >=20 > 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, > France Telecom - Orange decline toute responsabilite si ce message a = ete altere, deforme ou falsifie. Merci. >=20 > 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, France Telecom - Orange is not liable for = messages that have been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From laurent.thiebaut@alcatel-lucent.com Thu Dec 13 08:30:21 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEC821F89A3 for ; Thu, 13 Dec 2012 08:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.399 X-Spam-Level: X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[AWL=1.849, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvveBIQT3ipG for ; Thu, 13 Dec 2012 08:30:19 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id D13E021F85D2 for ; Thu, 13 Dec 2012 08:30:18 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBDGU9tr028488 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 13 Dec 2012 17:30:14 +0100 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 13 Dec 2012 17:30:06 +0100 From: "THIEBAUT, LAURENT (LAURENT)" To: "dime@ietf.org" Date: Thu, 13 Dec 2012 17:26:26 +0100 Thread-Topic: Dime: Diameter Overload IETF requirements, review: comments on Req 1, 26, 35 Thread-Index: Ac3Ts/BAQEyu8MTiRFuiZHheD1/f7QFmkSiw Message-ID: <170E8FCC2134BD42B539B47798ABF8F026C0CA6946@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_170E8FCC2134BD42B539B47798ABF8F026C0CA6946FRMRSSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review: comments on Req 1, 26, 35 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:30:21 -0000 --_000_170E8FCC2134BD42B539B47798ABF8F026C0CA6946FRMRSSXCHMBSA_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all While we understand that JJ comments on REQ2 still raises discussion, can i= t be concluded that there is some sort of agreement on the other comments e= xpressed by JJ? Best regards Laurent ALCATEL-LUCENT _____________________________________________ De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Envoy=E9 : jeudi 6 d=E9cembre 2012 14:17 =C0 : dime@ietf.org Cc : THIEBAUT, LAURENT (LAURENT) Objet : Dime: Diameter Overload IETF requirements, review Dear all In the objective of relying on IETF specifications to handle Diameter overl= oad for 3GPP applications, as Alcatel-Lucent, we did an analysis of the dra= ft-ietf-dime-overload-reqs-01. We consider the list of REQs described in the IETF draft as quite extensive= and all REQs relevant. We have the few additional comments to submit to th= e upcoming Dime review: * We suggest to put more emphasis in REQ1 on the fact this is both fo= r load (preventive) and overload (reactive). A possible writing: REQ 1: The overload mechanism MUST provide a communication method for Dia= meter nodes to exchange load and overload information. * About REQ 2 ("The overload mechanism MUST be useable with any exist= ing or future Diameter application. It MUST NOT require specification chan= ges for existing Diameter applications"), an existing application may evolv= e to support an overload mechanism, especially when the overload handling m= ay rely on certain application dependent behaviors (which would be within 3= GPP scope for applications defined by 3GPP). It also may have a consistency= issue with REQ13 "allowing for the possibility of increased feedback for i= nformation piggybacked" as the piggybacking mechanism may impact the applic= ation. May be a solution is to suppress this second part of the REQ2 (" It = MUST NOT require specification changes for existing Diameter applications")= or review the wording. * On REQ 26, we have the following reading we consider important: the= specifications of the diameter load/overload control can only give an over= all guidance. Actual and precise specification of the "which message types = might be desirable to send or process over others during times of overload"= should be left for each application to define (for " ... Diameter specifi= c considerations). If this reading of REQ 26 is shared, a possible rewordin= g could be: REQ 26: The generic specification for the overload mechanism SHOULD offer = overall guidance on which message types might be desirable to send or proce= ss over others during times of overload, based on Diameter-specific conside= rations. For example, it may be more beneficial to process messages for ex= isting sessions ahead of new sessions. A precise specification of the relat= ive priorities of message types in case of overload would anyhow be under t= he responsibility of each application. * We expressed the point that overload handling should take into acco= unt that some messages may have a high priority (eg when related to an emer= gency or a high priority user"). This handling would be application depen= dent and so entering the REQ 26 as an overall guidance but it could be ment= ioned in REQ 26 as an example with the possible wording " For example, it may be more beneficial to process messages for existing s= essions ahead of new sessions and to give priority to requests associated w= ith emergency sessions or with high priority users" * Last sentence of REQ 35 appears unclear, wording may be reviewed or= this sentence may be suppressed. . Best regards JJacques Trottin Alcatel-Lucent delegate to 3GPP CT4 --_000_170E8FCC2134BD42B539B47798ABF8F026C0CA6946FRMRSSXCHMBSA_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
     
     
    Hello a= ll 
    While w= e understand that JJ comments on REQ2 still raises discussion, can it be co= ncluded that there is some sort of agreement on the other comments expresse= d by JJ?
     
    Best re= gards
    Laurent=
    ALCATEL= -LUCENT
     <= /font>
    _________________________= ____________________
    De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
    Envoy=E9 : jeudi 6 d=E9cembre 2012 14:17
    =C0 : dime@ietf.org
    Cc : THIEBAUT, LAURENT (LAURENT)
    Objet : Dime: Diameter Overload IETF requirements, review
     
    Dear all=
     
     
    In the objective of relyin= g on IETF specifications to handle Diameter overload for 3GPP applications,= as Alcatel-Lucent, we did an analysis of the draft-ietf-dime-overload-reqs-01.
     
    We consider the list of RE= Qs described in the IETF draft as quite extensive and all REQs relevant. We= have the few additional comments to submit to the upcoming Dime review:
     
    • We suggest to put more emphasis in REQ1 on the fact this is = both for load (preventive) and overload (reactive). A possible writing:
    REQ 1:   The overload mechanism MUS= T provide a communication method for Diameter nodes to exchange load and overload information.
     
    • About REQ 2 (“The overload = mechanism MUST be useable with any existing or future Diameter application.=   It MUST NOT require specification changes for existing Diameter appl= ications”), an existing application may evolve to support an overload mechanism, especially when the overload handl= ing may rely on certain application dependent behaviors (which would be within 3GPP scope for applications defined by 3GPP). It also may have a consistency issue with REQ13 “allowing for the possibility of increased feedback for informat= ion piggybacked” as the piggybacking mechanism may impact the application. May be = a solution is to suppress thi= s second part of the REQ2 (“ It= MUST NOT require specification changes for existing Diameter applications”) or review the wording.
      • <= /font>
     
    • On REQ 26, we have the following reading we consider important: the spe= cifications of the diameter load/overload control can only give an overall = guidance. Actual and precise specification of the = “which message types might be desirable to send or process over others during time= s of overload” should be left for each application to define (for “ …  Diameter specific considerations). If this reading of REQ 26 is shared, a possible rewording could be:
    REQ 26:  The generic specificati= on for the overload mechanism SHOULD offer overall = guidance on which message types might be desirable to send or process over others during times of overload, based on Diameter-specific considerations= .  For example, it may be more beneficial to process m= essages for existing sessions ahead of new sessions. A precise specification of the relati= ve priorities of message types in case of overload would anyhow be under th= e responsibility of each application.
     
    • We expressed the point that overload handling should take into account = that some messages may have a high priority (eg when related to an emergenc= y or a high priority user”).  This handling would  be appli= cation dependent and so entering the REQ 26 as an overall guidance but it could be mentioned in REQ 26 as an example with the= possible wording
      •
    R= 20; For example, it may be more beneficial to process messages = for existing sessions ahead of new sessions and to give p= riority to requests associated with emergency sessions or with high priorit= y users&= #8221;
     
    • Last sentence of REQ 35 appears unclear, wording may be reviewed or thi= s sentence may be suppressed.
      •
     
    .
    Best regards
     
    JJacques Trottin
    Alcatel-Lucent delegate to= 3GPP CT4
     
     
     
     --_000_170E8FCC2134BD42B539B47798ABF8F026C0CA6946FRMRSSXCHMBSA_-- From ben@nostrum.com Mon Dec 17 14:06:50 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE31021F886B for ; Mon, 17 Dec 2012 14:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WDbC6g-RMLi for ; Mon, 17 Dec 2012 14:06:50 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC2921F8573 for ; Mon, 17 Dec 2012 14:06:49 -0800 (PST) Received: from [10.12.11.37] ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qBHM6jQp069988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Dec 2012 16:06:46 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <170E8FCC2134BD42B539B47798ABF8F026C0CA6946@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> Date: Mon, 17 Dec 2012 16:06:58 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <170E8FCC2134BD42B539B47798ABF8F026C0CA6946@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> To: "THIEBAUT, LAURENT (LAURENT)" X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review: comments on Req 1, 26, 35 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 22:06:50 -0000 On Dec 13, 2012, at 10:26 AM, "THIEBAUT, LAURENT (LAURENT)" = wrote: > =20 > =20 > Hello all=20 > While we understand that JJ comments on REQ2 still raises discussion, = can it be concluded that there is some sort of agreement on the other = comments expressed by JJ? Yes, we've incorporated the comments on all but REQ2 into our working = copy, and marked Req2 as being the subject of ongoing discussion. Thanks! Ben. > =20 > Best regards > Laurent > ALCATEL-LUCENT > =20 > _____________________________________________ > De : TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=20 > Envoy=E9 : jeudi 6 d=E9cembre 2012 14:17 > =C0 : dime@ietf.org > Cc : THIEBAUT, LAURENT (LAURENT) > Objet : Dime: Diameter Overload IETF requirements, review > =20 > Dear all > =20 > =20 > In the objective of relying on IETF specifications to handle Diameter = overload for 3GPP applications, as Alcatel-Lucent, we did an analysis of = the draft-ietf-dime-overload-reqs-01. > =20 > We consider the list of REQs described in the IETF draft as quite = extensive and all REQs relevant. We have the few additional comments to = submit to the upcoming Dime review: > =20 > =95 We suggest to put more emphasis in REQ1 on the fact this is = both for load (preventive) and overload (reactive). A possible writing: > REQ 1: The overload mechanism MUST provide a communication method = for Diameter nodes to exchange load and overload information. > =20 > =95 About REQ 2 (=93The overload mechanism MUST be useable with = any existing or future Diameter application. It MUST NOT require = specification changes for existing Diameter applications=94), an = existing application may evolve to support an overload mechanism, = especially when the overload handling may rely on certain application = dependent behaviors (which would be within 3GPP scope for applications = defined by 3GPP). It also may have a consistency issue with REQ13 = =93allowing for the possibility of increased feedback for information = piggybacked=94 as the piggybacking mechanism may impact the application. = May be a solution is to suppress this second part of the REQ2 (=93 It = MUST NOT require specification changes for existing Diameter = applications=94) or review the wording. > =20 > =95 On REQ 26, we have the following reading we consider = important: the specifications of the diameter load/overload control can = only give an overall guidance. Actual and precise specification of the = =93which message types might be desirable to send or process over others = during times of overload=94 should be left for each application to = define (for =93 =85 Diameter specific considerations). If this reading = of REQ 26 is shared, a possible rewording could be: > REQ 26: The generic specification for the overload mechanism SHOULD = offer overall guidance on which message types might be desirable to send = or process over others during times of overload, based on = Diameter-specific considerations. For example, it may be more = beneficial to process messages for existing sessions ahead of new = sessions. A precise specification of the relative priorities of message = types in case of overload would anyhow be under the responsibility of = each application. > =20 > =95 We expressed the point that overload handling should take = into account that some messages may have a high priority (eg when = related to an emergency or a high priority user=94). This handling = would be application dependent and so entering the REQ 26 as an overall = guidance but it could be mentioned in REQ 26 as an example with the = possible wording > =93 For example, it may be more beneficial to process messages for = existing sessions ahead of new sessions and to give priority to requests = associated with emergency sessions or with high priority users=94 > =20 > =95 Last sentence of REQ 35 appears unclear, wording may be = reviewed or this sentence may be suppressed. > =20 > . > Best regards > =20 > JJacques Trottin > Alcatel-Lucent delegate to 3GPP CT4 > =20 > =20 > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From internet-drafts@ietf.org Tue Dec 18 15:19:27 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD2021E8085; Tue, 18 Dec 2012 15:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.417 X-Spam-Level: X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrT0aVc3Ch1x; Tue, 18 Dec 2012 15:19:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C881F0CB2; Tue, 18 Dec 2012 15:19:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121218231927.31153.27660.idtracker@ietfa.amsl.com> Date: Tue, 18 Dec 2012 15:19:27 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-overload-reqs-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 23:19:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Diameter Overload Control Requirements Author(s) : Eric McMurry Ben Campbell Filename : draft-ietf-dime-overload-reqs-02.txt Pages : 27 Date : 2012-12-18 Abstract: When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by informing clients to reduce sending traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages, possibly resulting in congestion collapse. The existing mechanisms provided by Diameter are not sufficient for this purpose. This document describes the limitations of the existing mechanisms, and provides requirements for new overload management mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ben@nostrum.com Tue Dec 18 15:23:31 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384E71F0CB2 for ; Tue, 18 Dec 2012 15:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.36 X-Spam-Level: X-Spam-Status: No, score=-102.36 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAy2wwmXSZsA for ; Tue, 18 Dec 2012 15:23:29 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6CD21F8574 for ; Tue, 18 Dec 2012 15:23:28 -0800 (PST) Received: from [10.0.1.14] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qBINNRxM051657 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 18 Dec 2012 17:23:27 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Dec 2012 17:23:29 -0600 References: <20121218231927.31153.89871.idtracker@ietfa.amsl.com> To: "dime@ietf.org" Message-Id: <02FF8071-81D1-4CD2-9D97-E906BAA45FC8@nostrum.com> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Subject: [Dime] Fwd: New Version Notification for draft-ietf-dime-overload-reqs-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 23:23:31 -0000 Hi Everyone, We've submitted draft-ietf-dime-overload-reqs-02, based on the list = discussions over the last few weeks. We believe this addresses all the = substantive comments so far, except for the ongoing discussion on Req2 = (concerning application independence and the impact on application = specifications.) We've noted the open issue for Req 2 in the text. The new version is available at = http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-02 . You can = see a diff from version 01 at = http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-dime-o= verload-reqs-02.txt . Thanks! Ben. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-dime-overload-reqs-02.txt > Date: December 18, 2012 5:19:27 PM CST > To: ben@nostrum.com > Cc: emcmurry@computer.org >=20 >=20 > A new version of I-D, draft-ietf-dime-overload-reqs-02.txt > has been successfully submitted by Ben Campbell and posted to the > IETF repository. >=20 > Filename: draft-ietf-dime-overload-reqs > Revision: 02 > Title: Diameter Overload Control Requirements > Creation date: 2012-12-17 > WG ID: dime > Number of pages: 27 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-dime-overload-reqs-02.txt > Status: = http://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs > Htmlized: = http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-02 >=20 > Abstract: > When a Diameter server or agent becomes overloaded, it needs to be > able to gracefully reduce its load, typically by informing clients = to > reduce sending traffic for some period of time. Otherwise, it must > continue to expend resources parsing and responding to Diameter > messages, possibly resulting in congestion collapse. The existing > mechanisms provided by Diameter are not sufficient for this purpose. > This document describes the limitations of the existing mechanisms, > and provides requirements for new overload management mechanisms. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From jounikor@gmail.com Wed Dec 19 00:48:03 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6FBF21F8924 for ; Wed, 19 Dec 2012 00:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NFFJemAKS5J for ; Wed, 19 Dec 2012 00:48:03 -0800 (PST) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) by ietfa.amsl.com (Postfix) with ESMTP id DF29E21F8884 for ; Wed, 19 Dec 2012 00:48:02 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id m15so1368613lah.28 for ; Wed, 19 Dec 2012 00:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=ZPNUMYSGFXhyogEwFVRwoVC4AqRj6Iu5C3+z1iYHFfI=; b=FHhFzSni0zK/Ggx4imrhubcn84oodsrZddhGmwiEiqEgqAs5IXC9LQZ6osWgAleK2I I1NAeakFMcLHYxoEe6rW4dbg4o9g5wePWYxzCZgorop19aX1SFQmw2kfHJ8HdPaSQR1f 8+wjzIa2y+sYxqGjVEfnLLtgajTISFkN1IABPsbcMhNxy+0ynu7g44OLiFtMTkBJLoIq FDASTr4HbAzCY7bv4gWAUzVXh5tgEc0aDIdvOlZ3IG4kwdEgo8o72zjR+zMC79Ok+OBz gdKna+xskScmilZKzbC54oSbvhWAqjawk1Ah/FnFZacrv4wQhulAA/Kl1xLPXVftAnTd eC7w== X-Received: by 10.152.108.42 with SMTP id hh10mr4544969lab.4.1355906881610; Wed, 19 Dec 2012 00:48:01 -0800 (PST) Received: from [192.168.250.133] ([194.100.71.98]) by mx.google.com with ESMTPS id ft8sm1682774lab.9.2012.12.19.00.47.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 00:47:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: <02FF8071-81D1-4CD2-9D97-E906BAA45FC8@nostrum.com> Date: Wed, 19 Dec 2012 10:47:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8B064DAA-E5D5-4B20-BFBA-225DE9576D70@gmail.com> References: <20121218231927.31153.89871.idtracker@ietfa.amsl.com> <02FF8071-81D1-4CD2-9D97-E906BAA45FC8@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Wed, 19 Dec 2012 00:52:01 -0800 Cc: "dime@ietf.org" Subject: Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 08:48:04 -0000 Hi Ben, Thanks for the update. Now that the new revision is out I would encourage the WG to sort out the language in REQ 2 asap. As long as it is in flux the document cannot proceed to WGLC. - jouni On Dec 19, 2012, at 1:23 AM, Ben Campbell wrote: > Hi Everyone, >=20 > We've submitted draft-ietf-dime-overload-reqs-02, based on the list = discussions over the last few weeks. We believe this addresses all the = substantive comments so far, except for the ongoing discussion on Req2 = (concerning application independence and the impact on application = specifications.) We've noted the open issue for Req 2 in the text. >=20 > The new version is available at = http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-02 . You can = see a diff from version 01 at = http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-dime-o= verload-reqs-02.txt . >=20 > Thanks! >=20 > Ben. >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-ietf-dime-overload-reqs-02.txt >> Date: December 18, 2012 5:19:27 PM CST >> To: ben@nostrum.com >> Cc: emcmurry@computer.org >>=20 >>=20 >> A new version of I-D, draft-ietf-dime-overload-reqs-02.txt >> has been successfully submitted by Ben Campbell and posted to the >> IETF repository. >>=20 >> Filename: draft-ietf-dime-overload-reqs >> Revision: 02 >> Title: Diameter Overload Control Requirements >> Creation date: 2012-12-17 >> WG ID: dime >> Number of pages: 27 >> URL: = http://www.ietf.org/internet-drafts/draft-ietf-dime-overload-reqs-02.txt >> Status: = http://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs >> Htmlized: = http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-02 >> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-02 >>=20 >> Abstract: >> When a Diameter server or agent becomes overloaded, it needs to be >> able to gracefully reduce its load, typically by informing clients = to >> reduce sending traffic for some period of time. Otherwise, it must >> continue to expend resources parsing and responding to Diameter >> messages, possibly resulting in congestion collapse. The existing >> mechanisms provided by Diameter are not sufficient for this purpose. >> This document describes the limitations of the existing mechanisms, >> and provides requirements for new overload management mechanisms. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From tom.taylor.stds@gmail.com Wed Dec 19 08:04:53 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC0F21F8A90 for ; Wed, 19 Dec 2012 08:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaR+eHtbxbj5 for ; Wed, 19 Dec 2012 08:04:52 -0800 (PST) Received: from mail-ia0-f169.google.com (mail-ia0-f169.google.com [209.85.210.169]) by ietfa.amsl.com (Postfix) with ESMTP id 11AC621F86AC for ; Wed, 19 Dec 2012 08:04:52 -0800 (PST) Received: by mail-ia0-f169.google.com with SMTP id r4so1925551iaj.0 for ; Wed, 19 Dec 2012 08:04:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=AX28TxOJqEKzG/xc9Zj6rbIeq/vjHy56+zH5tV+C4P4=; b=IyLxE+BePc79rlu8b8eaBiEyLchPPoiUKHZsDFuFS6BexcZpfP16kJOZxXha9l/P8W p0QhRpER2WkFfK4YlZYJISsL/86kfWHV9ZL5q6pl2FI0TMc6Pwm8+4kBXDS7jDuF/Hfd gDaBl9oOLFM8iII9yk4P1CZrL5bN3DbCs/jejHrPY9nueoiCYLNEHmMs8+/zQLGJ91lz m1ZsKWxb3b5msyRmqc9FmoWmhG7cA8CVkXNeSw4zksUetHTprgqMOqBrnofg2E4OQ9Ag zi45mkyDhnnRdVysjnBW1ZIZPGFL2f/oqPAunSwtP3AQ4xuphQt3V0NA7PwLZYvA3ot1 CBAQ== X-Received: by 10.50.47.228 with SMTP id g4mr2438105ign.77.1355933091575; Wed, 19 Dec 2012 08:04:51 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-170-104.tor.primus.ca. [173.206.170.104]) by mx.google.com with ESMTPS id l8sm4427236igo.13.2012.12.19.08.04.49 (version=SSLv3 cipher=OTHER); Wed, 19 Dec 2012 08:04:50 -0800 (PST) Message-ID: <50D1E5A3.2030005@gmail.com> Date: Wed, 19 Dec 2012 11:04:51 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jouni Korhonen References: <20121218231927.31153.89871.idtracker@ietfa.amsl.com> <02FF8071-81D1-4CD2-9D97-E906BAA45FC8@nostrum.com> <8B064DAA-E5D5-4B20-BFBA-225DE9576D70@gmail.com> In-Reply-To: <8B064DAA-E5D5-4B20-BFBA-225DE9576D70@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 121219-0, 19/12/2012), Outbound message X-Antivirus-Status: Clean Cc: "dime@ietf.org" Subject: Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 16:04:53 -0000 I think the requirement is trying to say the following: "Basic support for overload controls MUST be independent of what applications a given Diameter node supports. Individual applications MAY provide more refined support for overload controls." On 19/12/2012 3:47 AM, Jouni Korhonen wrote: > > Hi Ben, > > Thanks for the update. Now that the new revision is out > I would encourage the WG to sort out the language in REQ 2 > asap. As long as it is in flux the document cannot proceed > to WGLC. > > - jouni > ... From mark@azu.ca Wed Dec 19 09:23:13 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AD321F878F for ; Wed, 19 Dec 2012 09:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vX3dUj7q-Suh for ; Wed, 19 Dec 2012 09:23:07 -0800 (PST) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by ietfa.amsl.com (Postfix) with ESMTP id DA61D21F8750 for ; Wed, 19 Dec 2012 09:23:06 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id k13so3189123iea.22 for ; Wed, 19 Dec 2012 09:23:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=cTfYQMHz7sfAd4CPEdCuGFWWegL22SAZQT9jmJb9soI=; b=Hr5qGBppBCOJESM+f8kfID2GMobfIxDE6NxIjTXljn2hzMpXBKr+8jKezcdWHFwDMv yV6AZKgCZIYYYmuOsq3qFJFN6ESN30W5OZAAc+lQqgIjlyLVVxMVwOE/PxcGABz/q0vo wy9yv9IgK9MM5pYuKeIpCUv5Wcm5mqr1BvfYHqCQowySHU2ZHSdMHQWQM0CuWp6Wdvig WasMsGmmL6/RYRGf09eIsAL5qJIq+zONOmYC48vt0l5P5PcWE1O+XYENX76U6CsUuJfZ iiQ3dGxLxhMXwFx/oApzzv2FVY+bcdqMNNTpRAvtV07Gdf7SEwuxEQb0CqBRxZPBpa5/ 1Ang== X-Received: by 10.50.152.132 with SMTP id uy4mr7557563igb.3.1355937786186; Wed, 19 Dec 2012 09:23:06 -0800 (PST) Received: from victor (75-119-249-79.dsl.teksavvy.com. [75.119.249.79]) by mx.google.com with ESMTPS id hg2sm11138484igc.3.2012.12.19.09.23.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 09:23:04 -0800 (PST) From: "Mark Jones" To: References: <20121218231927.31153.89871.idtracker@ietfa.amsl.com> <02FF8071-81D1-4CD2-9D97-E906BAA45FC8@nostrum.com> <8B064DAA-E5D5-4B20-BFBA-225DE9576D70@gmail.com> <50D1E5A3.2030005@gmail.com> In-Reply-To: <50D1E5A3.2030005@gmail.com> Date: Wed, 19 Dec 2012 12:23:01 -0500 Message-ID: <000601cdde0d$80d24f20$8276ed60$@azu.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ51F1iApZ/J+YgoUKExYbslzJ06QIE4VajAfTSCAsC0mmzipaSBEHA Content-Language: en-ca X-Gm-Message-State: ALoCoQnV/jLB/RufMJ444/HExkE/qql70By3D2X3C9RSqodimfScS9byWhzjAiOeBo7W75g7hx1y Subject: Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 17:23:13 -0000 > I think the requirement is trying to say the following: > > "Basic support for overload controls MUST be independent of what > applications a given Diameter node supports. Individual applications MAY > provide more refined support for overload controls." > I'm not reading a requirement for basic vs. refined support from the current REQ 2 text. I understand that REQ 2 is trying to establish the bounds of acceptable impacts on existing Diameter applications. IMHO it should read something like "the addition of the Diameter overload control mechanism to an existing Diameter application MUST NOT require the allocation of a new application id". Do we need to constrain the solution any further? I don't understand the motivation for requiring that it "MUST NOT require specification changes for existing Diameter applications". If 3GPP decides that Diameter overload control must be supported on an existing reference point, I would expect the 3GPP TS for that release to be updated to state just that. This is a "specification change" and I don't see how else a vendor would know that they had to update their implementation. What am I missing here? /Mark > On 19/12/2012 3:47 AM, Jouni Korhonen wrote: > > > > Hi Ben, > > > > Thanks for the update. Now that the new revision is out I would > > encourage the WG to sort out the language in REQ 2 asap. As long as it > > is in flux the document cannot proceed to WGLC. > > > > - jouni > > > ... > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From emcmurry@computer.org Wed Dec 19 10:26:51 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B46621F8795 for ; Wed, 19 Dec 2012 10:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4laX2o8Y85kf for ; Wed, 19 Dec 2012 10:26:50 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDD821F878F for ; Wed, 19 Dec 2012 10:26:49 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1TlOLw-000PFx-SC; Wed, 19 Dec 2012 18:26:48 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id A167BDE1488; Wed, 19 Dec 2012 12:26:46 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/ahcOynzJ/VAiq7ahBAy82sC2/EwCbwSc= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ7DybFzcUtY; Wed, 19 Dec 2012 12:26:46 -0600 (CST) Received: from [10.119.171.18] (unknown [217.171.42.130]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 05B69DE147E; Wed, 19 Dec 2012 12:26:45 -0600 (CST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric McMurry In-Reply-To: <000601cdde0d$80d24f20$8276ed60$@azu.ca> Date: Wed, 19 Dec 2012 19:25:48 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8A4C62AB-BE64-40B8-AA1C-8D8B5F1E22F3@computer.org> References: <20121218231927.31153.89871.idtracker@ietfa.amsl.com> <02FF8071-81D1-4CD2-9D97-E906BAA45FC8@nostrum.com> <8B064DAA-E5D5-4B20-BFBA-225DE9576D70@gmail.com> <50D1E5A3.2030005@gmail.com> <000601cdde0d$80d24f20$8276ed60$@azu.ca> To: Mark Jones X-Mailer: Apple Mail (2.1499) Cc: dime@ietf.org Subject: Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 18:26:51 -0000 Hi Mark, There wasn't a mention of basic and refined before, but I think Tom's = comment was close to what the requirement was trying to get at. It goes = beyond not changing the application id. It is entirely possible to = design a mechanism that requires no action from 3GPP and the requirement = was intended to ensure that the resulting mechanism is designed that = way. Thanks, Eric On Dec 19, 2012, at 18:23 , Mark Jones wrote: >> I think the requirement is trying to say the following: >>=20 >> "Basic support for overload controls MUST be independent of what >> applications a given Diameter node supports. Individual applications = MAY >> provide more refined support for overload controls." >>=20 >=20 > I'm not reading a requirement for basic vs. refined support from the = current > REQ 2 text. I understand that REQ 2 is trying to establish the bounds = of > acceptable impacts on existing Diameter applications. IMHO it should = read > something like "the addition of the Diameter overload control = mechanism to > an existing Diameter application MUST NOT require the allocation of a = new > application id". Do we need to constrain the solution any further? >=20 > I don't understand the motivation for requiring that it "MUST NOT = require > specification changes for existing Diameter applications". If 3GPP = decides > that Diameter overload control must be supported on an existing = reference > point, I would expect the 3GPP TS for that release to be updated to = state > just that. This is a "specification change" and I don't see how else a > vendor would know that they had to update their implementation. What = am I > missing here? >=20 > /Mark >=20 >> On 19/12/2012 3:47 AM, Jouni Korhonen wrote: >>>=20 >>> Hi Ben, >>>=20 >>> Thanks for the update. Now that the new revision is out I would >>> encourage the WG to sort out the language in REQ 2 asap. As long as = it >>> is in flux the document cannot proceed to WGLC. >>>=20 >>> - jouni >>>=20 >> ... >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From emcmurry@computer.org Wed Dec 19 10:26:51 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95BAB21F878F for ; Wed, 19 Dec 2012 10:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZHiBrB9gllT for ; Wed, 19 Dec 2012 10:26:51 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 54ED821F8790 for ; Wed, 19 Dec 2012 10:26:51 -0800 (PST) Received: from cpe-76-184-161-215.tx.res.rr.com ([76.184.161.215] helo=antikythera.casamcmurry.com) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1TlOLy-000PLg-UN; Wed, 19 Dec 2012 18:26:50 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 9DEB6DE1496; Wed, 19 Dec 2012 12:26:50 -0600 (CST) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 76.184.161.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18IR/6oeu//9CA2kxxWD44gFe05EfweGZU= X-Virus-Scanned: amavisd-new at casamcmurry.com Received: from antikythera.casamcmurry.com ([127.0.0.1]) by localhost (antikythera.casamcmurry.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pB8XJClFQYQ; Wed, 19 Dec 2012 12:26:50 -0600 (CST) Received: from [10.119.171.18] (unknown [217.171.42.130]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 197E5DE1490; Wed, 19 Dec 2012 12:26:49 -0600 (CST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric McMurry In-Reply-To: <000601cdde0d$80d24f20$8276ed60$@azu.ca> Date: Wed, 19 Dec 2012 19:26:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <700CBE5A-6FDC-4C40-B312-5867557212F7@computer.org> References: <20121218231927.31153.89871.idtracker@ietfa.amsl.com> <02FF8071-81D1-4CD2-9D97-E906BAA45FC8@nostrum.com> <8B064DAA-E5D5-4B20-BFBA-225DE9576D70@gmail.com> <50D1E5A3.2030005@gmail.com> <000601cdde0d$80d24f20$8276ed60$@azu.ca> To: Mark Jones X-Mailer: Apple Mail (2.1499) Cc: dime@ietf.org Subject: Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 18:26:51 -0000 Hi Mark, There wasn't a mention of basic and refined before, but I think Tom's = comment was close to what the requirement was trying to get at. It goes = beyond not changing the application id. It is entirely possible to = design a mechanism that requires no action from 3GPP and the requirement = was intended to ensure that the resulting mechanism is designed that = way. Thanks, Eric On Dec 19, 2012, at 18:23 , Mark Jones wrote: >> I think the requirement is trying to say the following: >>=20 >> "Basic support for overload controls MUST be independent of what >> applications a given Diameter node supports. Individual applications = MAY >> provide more refined support for overload controls." >>=20 >=20 > I'm not reading a requirement for basic vs. refined support from the = current > REQ 2 text. I understand that REQ 2 is trying to establish the bounds = of > acceptable impacts on existing Diameter applications. IMHO it should = read > something like "the addition of the Diameter overload control = mechanism to > an existing Diameter application MUST NOT require the allocation of a = new > application id". Do we need to constrain the solution any further? >=20 > I don't understand the motivation for requiring that it "MUST NOT = require > specification changes for existing Diameter applications". If 3GPP = decides > that Diameter overload control must be supported on an existing = reference > point, I would expect the 3GPP TS for that release to be updated to = state > just that. This is a "specification change" and I don't see how else a > vendor would know that they had to update their implementation. What = am I > missing here? >=20 > /Mark >=20 >> On 19/12/2012 3:47 AM, Jouni Korhonen wrote: >>>=20 >>> Hi Ben, >>>=20 >>> Thanks for the update. Now that the new revision is out I would >>> encourage the WG to sort out the language in REQ 2 asap. As long as = it >>> is in flux the document cannot proceed to WGLC. >>>=20 >>> - jouni >>>=20 >> ... >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Wed Dec 19 10:30:21 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC2B21F8696 for ; Wed, 19 Dec 2012 10:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.286 X-Spam-Level: X-Spam-Status: No, score=-102.286 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+emCWVwx9EA for ; Wed, 19 Dec 2012 10:30:20 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8C46621F86AC for ; Wed, 19 Dec 2012 10:30:20 -0800 (PST) Received: from [10.12.11.37] ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qBJIUFiC084028 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Dec 2012 12:30:16 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: multipart/alternative; boundary="Apple-Mail=_51E2E0C0-08AD-444F-BFEF-30625367EFFE" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <50D1E5A3.2030005@gmail.com> Date: Wed, 19 Dec 2012 12:30:16 -0600 Message-Id: References: <20121218231927.31153.89871.idtracker@ietfa.amsl.com> <02FF8071-81D1-4CD2-9D97-E906BAA45FC8@nostrum.com> <8B064DAA-E5D5-4B20-BFBA-225DE9576D70@gmail.com> <50D1E5A3.2030005@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" , Jouni Korhonen Subject: Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 18:30:21 -0000 --Apple-Mail=_51E2E0C0-08AD-444F-BFEF-30625367EFFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Tom, I think that's on the right track. We've been too focused on = specification impact, when the root of the requirement is really a = combination of application-independent default behavior, along with = extensibility to allow application-specific behavior. To put some finer points on it, how's this? I tried to take the spirit = of your proposed text, and added some non-normative elaboration: The mechanism MUST allow Diameter nodes to support default overload = control regardless of which Diameter applications they support. It MUST = provide sufficient extensibility to allow individual applications to = provide more refined overload control. The basic mechanism is intended to be application-independent, that is, = a Diameter node can use it across any existing and future Diameter = applications and expect reasonable results. Certain Diameter = applications might, however, benefit from application-specific behavior = over and above the mechanism's defaults. For example, an application = specification might specify relative priorities of messages or selection = of a specific overload control algorithm. On Dec 19, 2012, at 10:04 AM, Tom Taylor = wrote: > I think the requirement is trying to say the following: >=20 > "Basic support for overload controls MUST be independent of what = applications a given Diameter node supports. Individual applications MAY = provide more refined support for overload controls." >=20 > On 19/12/2012 3:47 AM, Jouni Korhonen wrote: >>=20 >> Hi Ben, >>=20 >> Thanks for the update. Now that the new revision is out >> I would encourage the WG to sort out the language in REQ 2 >> asap. As long as it is in flux the document cannot proceed >> to WGLC. >>=20 >> - jouni >>=20 > ... --Apple-Mail=_51E2E0C0-08AD-444F-BFEF-30625367EFFE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 The basic mechanism is intended to be application-independent, = that is, a Diameter node can use it across any existing and future = Diameter applications and expect reasonable results. Certain Diameter = applications might, however, benefit from application-specific behavior = over and above the mechanism's defaults. For example, an application = specification might specify relative priorities of messages or selection = of a specific overload control = algorithm.



    On Dec 19, 2012, at 10:04 AM, Tom Taylor <tom.taylor.stds@gmail.com>= ; wrote:

    I think the requirement is trying to say the = following:

    "Basic support for overload controls MUST be = independent of what applications a given Diameter node supports. = Individual applications MAY provide more refined support for overload = controls."

    On 19/12/2012 3:47 AM, Jouni Korhonen = wrote:

    Hi Ben,

    Thanks for the = update. Now that the new revision is out
    I would encourage the WG to = sort out the language in REQ 2
    asap. As long as it is in flux the = document cannot proceed
    to WGLC.

    - = jouni

    ...

    = --Apple-Mail=_51E2E0C0-08AD-444F-BFEF-30625367EFFE-- From ben@nostrum.com Wed Dec 19 10:40:56 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD23821F862D for ; Wed, 19 Dec 2012 10:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.308 X-Spam-Level: X-Spam-Status: No, score=-102.308 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnixO+z9xim8 for ; Wed, 19 Dec 2012 10:40:55 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id EB67521F8609 for ; Wed, 19 Dec 2012 10:40:53 -0800 (PST) Received: from [10.12.11.37] ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qBJIem1c085232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Dec 2012 12:40:49 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <000601cdde0d$80d24f20$8276ed60$@azu.ca> Date: Wed, 19 Dec 2012 12:40:49 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121218231927.31153.89871.idtracker@ietfa.amsl.com> <02FF8071-81D1-4CD2-9D97-E906BAA45FC8@nostrum.com> <8B064DAA-E5D5-4B20-BFBA-225DE9576D70@gmail.com> <50D1E5A3.2030005@gmail.com> <000601cdde0d$80d24f20$8276ed60$@azu.ca> To: "Mark Jones" X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: dime@ietf.org Subject: Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 18:40:56 -0000 Hi Mark, see comments inline: Thanks! Ben. On Dec 19, 2012, at 11:23 AM, "Mark Jones" wrote: >> I think the requirement is trying to say the following: >>=20 >> "Basic support for overload controls MUST be independent of what >> applications a given Diameter node supports. Individual applications = MAY >> provide more refined support for overload controls." >>=20 >=20 > I'm not reading a requirement for basic vs. refined support from the = current > REQ 2 text. I understand that REQ 2 is trying to establish the bounds = of > acceptable impacts on existing Diameter applications. IMHO it should = read > something like "the addition of the Diameter overload control = mechanism to > an existing Diameter application MUST NOT require the allocation of a = new > application id". Do we need to constrain the solution any further? >=20 The original Req 2 language clearly created confusion about it's = original intent. This really is about application-independence. I think = that not forcing new application IDs is an implication of that intent, = but does not capture it entirely. Please see my separate response to = Tom's email. > I don't understand the motivation for requiring that it "MUST NOT = require > specification changes for existing Diameter applications". If 3GPP = decides > that Diameter overload control must be supported on an existing = reference > point, I would expect the 3GPP TS for that release to be updated to = state > just that. This is a "specification change" and I don't see how else a > vendor would know that they had to update their implementation. What = am I > missing here? The idea is that an implementor would not have to wait for 3GPP in order = to implement whatever RFC we come up with in DIME. 3GPP could certainly = require support, and specify application-specific refinements. Those = would require updates to the relevant specs. But even if they didn't do = that, people could still choose to support some level of overload = control. >=20 > /Mark >=20 >> On 19/12/2012 3:47 AM, Jouni Korhonen wrote: >>>=20 >>> Hi Ben, >>>=20 >>> Thanks for the update. Now that the new revision is out I would >>> encourage the WG to sort out the language in REQ 2 asap. As long as = it >>> is in flux the document cannot proceed to WGLC. >>>=20 >>> - jouni >>>=20 >> ... >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From tom.taylor.stds@gmail.com Wed Dec 19 11:51:41 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D0421F8750 for ; Wed, 19 Dec 2012 11:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.312 X-Spam-Level: X-Spam-Status: No, score=-3.312 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tv091ra9vX3b for ; Wed, 19 Dec 2012 11:51:40 -0800 (PST) Received: from mail-ia0-f174.google.com (mail-ia0-f174.google.com [209.85.210.174]) by ietfa.amsl.com (Postfix) with ESMTP id 18E9D21F8742 for ; Wed, 19 Dec 2012 11:51:40 -0800 (PST) Received: by mail-ia0-f174.google.com with SMTP id y25so2122735iay.33 for ; Wed, 19 Dec 2012 11:51:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=CaqUdSVvFnQkPCW0uTF0ikzoiemEbC2S1EbC67OTqdk=; b=Q8KPQz9mO70NBINh5THDfjqfhSm9RkvIirHn6Ac68x4LtSDY4vbaNhF4gs9xDXlOJ/ pF1ynkdTuGLmg36ceglGOUsfmhB+p4Ju4Xz0USLCuZM+P1wBFKAqFKysfW2Au40M8UTt TqF/+9Sq5jeIxMZfhnbmH5UGTRZqh2/OU+0kPmiPeipLKTU7MXDWL74yHOraCpqZvM18 lnQBHFK+9bJq+wUY2ygkrPXSfbVOCJWIp+0MP6P7kGGZ7egCMTBZhOfryxFWHg3S9cZE uTMhejCaep3Nxo1axjE+2Vpi8DEuZIKnODAJF4lCJEAmRqoVzBZkBdWtv341FDhutioE mh9g== X-Received: by 10.50.152.132 with SMTP id uy4mr8037386igb.3.1355946699440; Wed, 19 Dec 2012 11:51:39 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-170-104.tor.primus.ca. [173.206.170.104]) by mx.google.com with ESMTPS id bh3sm11448578igc.0.2012.12.19.11.51.37 (version=SSLv3 cipher=OTHER); Wed, 19 Dec 2012 11:51:38 -0800 (PST) Message-ID: <50D21ACB.4060702@gmail.com> Date: Wed, 19 Dec 2012 14:51:39 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Campbell References: <20121218231927.31153.89871.idtracker@ietfa.amsl.com> <02FF8071-81D1-4CD2-9D97-E906BAA45FC8@nostrum.com> <8B064DAA-E5D5-4B20-BFBA-225DE9576D70@gmail.com> <50D1E5A3.2030005@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 121219-0, 19/12/2012), Outbound message X-Antivirus-Status: Clean Cc: "dime@ietf.org" Subject: Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 19:51:41 -0000 Just a one-word change. On 19/12/2012 1:30 PM, Ben Campbell wrote: > Hi Tom, > > I think that's on the right track. We've been too focused on > specification impact, when the root of the requirement is really a > combination of application-independent default behavior, along with > extensibility to allow application-specific behavior. > > To put some finer points on it, how's this? I tried to take the > spirit of your proposed text, and added some non-normative > elaboration: > > > The mechanism MUST allow Diameter nodes to support default overload > control regardless of which Diameter applications they support. It > MUST provide sufficient extensibility to allow individual > applications to provide more refined overload control. > > The basic mechanism is intended to be application-independent, that > is, a Diameter node can use it across any existing and future > Diameter applications and expect reasonable results. Certain Diameter > applications might, however, benefit from application-specific > behavior over and above the mechanism's defaults. For example, an > application might specify relative priorities of ^^^^^^^^ > messages or selection of a specific overload control algorithm. > From ben@nostrum.com Wed Dec 19 12:15:43 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3CF21F863C for ; Wed, 19 Dec 2012 12:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evj6Md2PT9nk for ; Wed, 19 Dec 2012 12:15:42 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 184D221F86A8 for ; Wed, 19 Dec 2012 12:15:42 -0800 (PST) Received: from [172.20.10.2] (mobile-166-137-149-039.mycingular.net [166.137.149.39]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qBJKFZEY095855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Dec 2012 14:15:37 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <50D21ACB.4060702@gmail.com> Date: Wed, 19 Dec 2012 14:15:33 -0600 Content-Transfer-Encoding: 7bit Message-Id: <42F0A6F7-CA0F-4F16-9D81-4B21B93A6FFC@nostrum.com> References: <20121218231927.31153.89871.idtracker@ietfa.amsl.com> <02FF8071-81D1-4CD2-9D97-E906BAA45FC8@nostrum.com> <8B064DAA-E5D5-4B20-BFBA-225DE9576D70@gmail.com> <50D1E5A3.2030005@gmail.com> <50D21ACB.4060702@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 166.137.149.39 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 20:15:43 -0000 WFM On Dec 19, 2012, at 1:51 PM, Tom Taylor wrote: > > > Just a one-word change. > > On 19/12/2012 1:30 PM, Ben Campbell wrote: >> Hi Tom, >> >> I think that's on the right track. We've been too focused on >> specification impact, when the root of the requirement is really a >> combination of application-independent default behavior, along with >> extensibility to allow application-specific behavior. >> >> To put some finer points on it, how's this? I tried to take the >> spirit of your proposed text, and added some non-normative >> elaboration: >> >> >> The mechanism MUST allow Diameter nodes to support default overload >> control regardless of which Diameter applications they support. It >> MUST provide sufficient extensibility to allow individual >> applications to provide more refined overload control. >> >> The basic mechanism is intended to be application-independent, that >> is, a Diameter node can use it across any existing and future >> Diameter applications and expect reasonable results. Certain Diameter >> applications might, however, benefit from application-specific >> behavior over and above the mechanism's defaults. For example, an >> application might specify relative priorities of > ^^^^^^^^ >> messages or selection of a specific overload control algorithm. >> From laurent.thiebaut@alcatel-lucent.com Wed Dec 19 12:34:19 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90DF21F862D for ; Wed, 19 Dec 2012 12:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.655 X-Spam-Level: X-Spam-Status: No, score=-8.655 tagged_above=-999 required=5 tests=[AWL=1.366, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FA2DU43ecgUt for ; Wed, 19 Dec 2012 12:34:18 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1515221F85EE for ; Wed, 19 Dec 2012 12:34:17 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qBJKYGxR011942 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 19 Dec 2012 21:34:16 +0100 Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 19 Dec 2012 21:34:16 +0100 From: "THIEBAUT, LAURENT (LAURENT)" To: Ben Campbell Date: Wed, 19 Dec 2012 21:34:14 +0100 Thread-Topic: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt Thread-Index: Ac3dxiVUs2ZV7SX+TA+gbXUVShlgJwAS4f9A Message-ID: <170E8FCC2134BD42B539B47798ABF8F026C0D0FBA8@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> References: <20121218231927.31153.89871.idtracker@ietfa.amsl.com> <02FF8071-81D1-4CD2-9D97-E906BAA45FC8@nostrum.com> <8B064DAA-E5D5-4B20-BFBA-225DE9576D70@gmail.com> In-Reply-To: <8B064DAA-E5D5-4B20-BFBA-225DE9576D70@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_170E8FCC2134BD42B539B47798ABF8F026C0D0FBA8FRMRSSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "dime@ietf.org" Subject: Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 20:34:19 -0000 --_000_170E8FCC2134BD42B539B47798ABF8F026C0D0FBA8FRMRSSXCHMBSA_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all Thanks Ben for the new version I think we are approaching towards the conclusion but would like to suggest= following new requirements REQ X: A common default algorithm to react to an overload status SHOULD b= e defined in order to allow a basic inter-operable inter Service Provider o= verload mechanism. REQ Y: Even though there are Diameter Agents between 2 Diameter end-point= s (client/server) that support the (overload control) feature, there MUST b= e a way to report an *overload* status to the Diameter end-points (client/s= erver) in order for Diameter end-points to be able to take proper (possibly= non Diameter) actions. So to us, the remaining work would be on Req2, Req X and Req Y. It is recognized that Req Y is almost the same than Req 35 but with =B7 a "MUST" instead of a "SHOULD" =B7 the fact that even when the DA supports the mechanism the end p= oint may need to know an *overload* status (this may be different for a *lo= ad* status) =B7 and (minor remark) the indication that the reaction to an overl= oad status may imply possible non Diameter actions. Best regards Laurent ALCATEL-LUCENT -----Message d'origine----- De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Jou= ni Korhonen Envoy=E9 : mercredi 19 d=E9cembre 2012 09:48 =C0 : Ben Campbell Cc : dime@ietf.org Objet : Re: [Dime] New Version Notification for draft-ietf-dime-overload-re= qs-02.txt Hi Ben, Thanks for the update. Now that the new revision is out I would encourage the WG to sort out the language in REQ 2 asap. As long as it is in flux the document cannot proceed to WGLC. - jouni On Dec 19, 2012, at 1:23 AM, Ben Campbell wrote: > Hi Everyone, > > We've submitted draft-ietf-dime-overload-reqs-02, based on the list discu= ssions over the last few weeks. We believe this addresses all the substanti= ve comments so far, except for the ongoing discussion on Req2 (concerning a= pplication independence and the impact on application specifications.) We'v= e noted the open issue for Req 2 in the text. > > The new version is available at http://tools.ietf.org/html/draft-ietf-dim= e-overload-reqs-02 . You can see a diff from version 01 at http://tools.iet= f.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-dime-overload-reqs-02.t= xt . > > Thanks! > > Ben. > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-ietf-dime-overload-reqs-02.t= xt >> Date: December 18, 2012 5:19:27 PM CST >> To: ben@nostrum.com >> Cc: emcmurry@computer.org >> >> >> A new version of I-D, draft-ietf-dime-overload-reqs-02.txt >> has been successfully submitted by Ben Campbell and posted to the >> IETF repository. >> >> Filename: draft-ietf-dime-overload-reqs >> Revision: 02 >> Title: Diameter Overload Control Requirements >> Creation date: 2012-12-17 >> WG ID: dime >> Number of pages: 27 >> URL: http://www.ietf.org/internet-drafts/draft-ietf-dime-ove= rload-reqs-02.txt >> Status: http://datatracker.ietf.org/doc/draft-ietf-dime-overloa= d-reqs >> Htmlized: http://tools.ietf.org/html/draft-ietf-dime-overload-req= s-02 >> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-over= load-reqs-02 >> >> Abstract: >> When a Diameter server or agent becomes overloaded, it needs to be >> able to gracefully reduce its load, typically by informing clients to >> reduce sending traffic for some period of time. Otherwise, it must >> continue to expend resources parsing and responding to Diameter >> messages, possibly resulting in congestion collapse. The existing >> mechanisms provided by Diameter are not sufficient for this purpose. >> This document describes the limitations of the existing mechanisms, >> and provides requirements for new overload management mechanisms. >> >> >> >> >> The IETF Secretariat >> > > _______________________________________________ > 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 --_000_170E8FCC2134BD42B539B47798ABF8F026C0D0FBA8FRMRSSXCHMBSA_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

     

     

    Hello all

    Thanks Ben for the new version=

    I think we are approaching towards the conclusio= n but would like to suggest following new requirements

    =A0

    REQ X:=A0=A0 A common default algorithm to react= to an overload status SHOULD be defined in order to allow a basic inter-operable inter Service Provider overload mechanism.

     

    REQ Y:=A0=A0 Even though there are Diameter Agen= ts between 2 Diameter end-points (client/server) that support the (overload control) f= eature, there MUST be a way to report an *overl= oad* status to the Diameter end-points (client/server) in order for Diameter end-points to be able to take proper (possibly non Diameter) actions.<= /o:p>

     

     

    So to us, the remaining work would be on Req2, R= eq X and Req Y.

     

    It is recognized that Req Y is almost the same t= han Req 35 but with

    =B7         a "MUST" instead of a "SHOULD"

    =B7         the fact th= at even when the DA supports the mechanism the end point may need to know an *= overload* status (this may be differe= nt for a *load* status)<= /span>

    =B7         and (minor = remark) the indication that the reaction to an overload status may imply possible n= on Diameter actions.

    =A0

    Best regards

    Laurent

    ALCATEL-LUCENT

     

    -----Message d'origine-----

    De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De l= a part de Jouni Korhonen

    Envoy=E9 : mercredi 19 d=E9cembre 2012 09:48=

    =C0 : Ben Campbell

    Cc : dime@ietf.org=

    Objet : Re: [Dime] New Version Notification= for draft-ietf-dime-overload-reqs-02.txt

     

     

    Hi Ben,

     

    Thanks for the update. Now that the new revision= is out

    I would encourage the WG to sort out the languag= e in REQ 2

    asap. As long as it is in flux the document cann= ot proceed

    to WGLC.

     

    - jouni

     

     

    On Dec 19, 2012, at 1:23 AM, Ben Campbell <ben@nostrum.com> wrote:

     

    > Hi Everyone,

    >

    > We've submitted draft-ietf-dime-overload-re= qs-02, based on the list discussions over the last few weeks. We believe this addresses all the substantive comments so far, except for the ongoing discussion on Req2 (concerning application independence and the impact on application specifications.) We've noted the open issue for Req 2 in the te= xt.

    >

    > The new version is available at http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-02 . You can see a diff from version 01 at http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-dim= e-overload-reqs-02.txt .

    >

    > Thanks!

    >

    > Ben.

    >

    > Begin forwarded message:<= /font>

    >

    >> From: internet-drafts@ietf.org

    >> Subject: New Version Notification for draft-ietf-dime-overload-reqs-02.txt

    >> Date: December 18, 2012 5:19:27 PM CST<= o:p>

    >> To: ben@nostrum.com

    >> Cc: emcmurry@computer.org

    >>

    >>

    >> A new version of I-D, draft-ietf-dime-overload-reqs-02.txt

    >> has been successfully submitted by Ben Campbell and posted to the

    >> IETF repository.

    >>

    >> Filename:=A0=A0=A0=A0=A0 draft-ietf-di= me-overload-reqs

    >> Revision:=A0=A0=A0=A0=A0 02=

    >> Title:=A0=A0=A0=A0=A0=A0=A0=A0 Diamete= r Overload Control Requirements

    >> Creation date: 2012-12-17

    >> WG ID:=A0=A0=A0=A0=A0=A0=A0=A0 dime

    >> Number of pages: 27

    >> URL:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 http://www.ietf.org/internet-drafts/draft-ietf-dime-overload-reqs-02.txt

    >> Status:=A0=A0=A0=A0=A0=A0=A0=A0=A0 http= ://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs=

    >> Htmlized:=A0=A0=A0=A0=A0=A0=A0 http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-02

    >> Diff:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-02

    >>

    >> Abstract:

    >>=A0 When a Diameter server or agent beco= mes overloaded, it needs to be

    >>=A0 able to gracefully reduce its load, typically by informing clients to

    >>=A0 reduce sending traffic for some peri= od of time.=A0 Otherwise, it must

    >>=A0 continue to expend resources parsing= and responding to Diameter

    >>=A0 messages, possibly resulting in cong= estion collapse.=A0 The existing

    >>=A0 mechanisms provided by Diameter are = not sufficient for this purpose.

    >>=A0 This document describes the limitati= ons of the existing mechanisms,

    >>=A0 and provides requirements for new ov= erload management mechanisms.

    >>

    >>

    >>

    >>

    >> The IETF Secretariat<= /font>

    >>

    >

    > ___________________________________________= ____

    > DiME mailing list<= /p>

    > DiME@ietf.org

    > https://www.ietf.org/mailman/listinfo/dime<= o:p>

     

    _______________________________________________<= o:p>

    DiME mailing list

    DiME@ietf.org

    https://www.ietf.org/mailman/listinfo/dime<= /o:p>

    --_000_170E8FCC2134BD42B539B47798ABF8F026C0D0FBA8FRMRSSXCHMBSA_-- From mark@azu.ca Wed Dec 19 12:38:59 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B453121F8578 for ; Wed, 19 Dec 2012 12:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCAsRkV09Mn0 for ; Wed, 19 Dec 2012 12:38:59 -0800 (PST) Received: from mail-ia0-f171.google.com (mail-ia0-f171.google.com [209.85.210.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC0F21F8530 for ; Wed, 19 Dec 2012 12:38:58 -0800 (PST) Received: by mail-ia0-f171.google.com with SMTP id k27so2165806iad.2 for ; Wed, 19 Dec 2012 12:38:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language:x-gm-message-state; bh=FvUnEYXCCM4xkBgQ+1PmZUAzX4eJKAkzd04iWzONxnk=; b=Q1LbLFIO2BXg63kS3kVN2UjstXLeWght8oYgsCbAMKLN+D95ixK7Re8lCagQP1Eu6m gLIIn0vIt0VAPZc0f9KLNO+2lNWjTDauUgTWM6/1EoK+BT5ivqGvgDYTiY6fZeoRQlot YztnFMoJsCfVu1OqBYxfPGxEA2LK+WQkv0Xl8Dt36P+K52LGr6nssaFVbBYqh7EIN9wp z9z2rMRyzU1ZPMw4RvOsgdtw/AwPOn9OxLXaNmTOq+nCIR2LVMyEFcjKVhC3ArfRAwWb D2MiJ9Q85ej0uRyxfVkPFACRu4UquRJEOYFYljYu1cuaIlU/D1xcRwqfEAsAWjPy9S2N NagA== X-Received: by 10.50.149.196 with SMTP id uc4mr8522366igb.74.1355949538417; Wed, 19 Dec 2012 12:38:58 -0800 (PST) Received: from victor (69-196-176-137.dsl.teksavvy.com. [69.196.176.137]) by mx.google.com with ESMTPS id eu3sm11533020igc.7.2012.12.19.12.38.56 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 12:38:57 -0800 (PST) From: "Mark Jones" To: "'Eric McMurry'" References: <20121218231927.31153.89871.idtracker@ietfa.amsl.com> <02FF8071-81D1-4CD2-9D97-E906BAA45FC8@nostrum.com> <8B064DAA-E5D5-4B20-BFBA-225DE9576D70@gmail.com> <50D1E5A3.2030005@gmail.com> <000601cdde0d$80d24f20$8276ed60$@azu.ca> <8A4C62AB-BE64-40B8-AA1C-8D8B5F1E22F3@computer.org> In-Reply-To: <8A4C62AB-BE64-40B8-AA1C-8D8B5F1E22F3@computer.org> Date: Wed, 19 Dec 2012 15:38:53 -0500 Message-ID: <000601cdde28$ddb8db30$992a9190$@azu.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ51F1iApZ/J+YgoUKExYbslzJ06QIE4VajAfTSCAsC0mmzigHR+Y4bAclFhVqWdWDJMA== Content-Language: en-ca X-Gm-Message-State: ALoCoQnDOGvwXyOcEPW5mpjZuszJKtzeO22N1002k3toU4DVSfs8BtTGL/YdKFxjYVvR821HU84G Cc: dime@ietf.org Subject: Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 20:38:59 -0000 Hi Eric, > There wasn't a mention of basic and refined before, but I think Tom's > comment was close to what the requirement was trying to get at. It goes > beyond not changing the application id. If I've understood correctly, REQ2 was originally intended to capture the requirement for an application-neutral overload control mechanism. The support for application-specific extensions for overload control is a new requirement that has come out of discussions of the original REQ2 text. Just to be clear, I'm not arguing against either requirement. I just couldn't derive the new requirement from reading revision -02. > It is entirely possible to design a > mechanism that requires no action from 3GPP and the requirement was > intended to ensure that the resulting mechanism is designed that way. > I understand the design goal but I think you missed the point of my 3GPP example. You can certainly design the mechanism and publish an RFC with "no action from 3GPP". However, until 3GPP updates and ratifies their technical specification (TS) to state that your RFC MUST be supported on a given reference point, an operator cannot assume multi-vendor interoperability of your RFC on that 3GPP reference point. /Mark > Thanks, > > Eric > > > On Dec 19, 2012, at 18:23 , Mark Jones wrote: > > >> I think the requirement is trying to say the following: > >> > >> "Basic support for overload controls MUST be independent of what > >> applications a given Diameter node supports. Individual applications > >> MAY provide more refined support for overload controls." > >> > > > > I'm not reading a requirement for basic vs. refined support from the > > current REQ 2 text. I understand that REQ 2 is trying to establish > > the bounds of acceptable impacts on existing Diameter applications. > > IMHO it should read something like "the addition of the Diameter > > overload control mechanism to an existing Diameter application MUST > > NOT require the allocation of a new application id". Do we need to > constrain the solution any further? > > > > I don't understand the motivation for requiring that it "MUST NOT > > require specification changes for existing Diameter applications". If > > 3GPP decides that Diameter overload control must be supported on an > > existing reference point, I would expect the 3GPP TS for that release > > to be updated to state just that. This is a "specification change" and > > I don't see how else a vendor would know that they had to update their > > implementation. What am I missing here? > > > > /Mark > > > >> On 19/12/2012 3:47 AM, Jouni Korhonen wrote: > >>> > >>> Hi Ben, > >>> > >>> Thanks for the update. Now that the new revision is out I would > >>> encourage the WG to sort out the language in REQ 2 asap. As long as > >>> it is in flux the document cannot proceed to WGLC. > >>> > >>> - jouni > >>> > >> ... > >> _______________________________________________ > >> 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 From ben@nostrum.com Wed Dec 19 13:27:43 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0869721F857D for ; Wed, 19 Dec 2012 13:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WROn9bn8AaBI for ; Wed, 19 Dec 2012 13:27:29 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2B021F8577 for ; Wed, 19 Dec 2012 13:27:29 -0800 (PST) Received: from [172.20.10.2] (mobile-166-137-149-039.mycingular.net [166.137.149.39]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qBJLRIaB003898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Dec 2012 15:27:19 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <000601cdde28$ddb8db30$992a9190$@azu.ca> Date: Wed, 19 Dec 2012 15:27:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121218231927.31153.89871.idtracker@ietfa.amsl.com> <02FF8071-81D1-4CD2-9D97-E906BAA45FC8@nostrum.com> <8B064DAA-E5D5-4B20-BFBA-225DE9576D70@gmail.com> <50D1E5A3.2030005@gmail.com> <000601cdde0d$80d24f20$8276ed60$@azu.ca> <8A4C62AB-BE64-40B8-AA1C-8D8B5F1E22F3@computer.org> <000601cdde28$ddb8db30$992a9190$@azu.ca> To: "Mark Jones" X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 166.137.149.39 is authenticated by a trusted mechanism) Cc: dime@ietf.org Subject: Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 21:27:43 -0000 On Dec 19, 2012, at 2:38 PM, "Mark Jones" wrote: > Hi Eric, >=20 >> There wasn't a mention of basic and refined before, but I think Tom's >> comment was close to what the requirement was trying to get at. It = goes >> beyond not changing the application id. =20 >=20 > If I've understood correctly, REQ2 was originally intended to capture = the > requirement for an application-neutral overload control mechanism. The > support for application-specific extensions for overload control is a = new > requirement that has come out of discussions of the original REQ2 = text. Just > to be clear, I'm not arguing against either requirement. I just = couldn't > derive the new requirement from reading revision -02. Basically, yes. The extensibility requirement was intended, but not well = documented. It's mentioned in the motivating text, but not so much in = the requirements. That's why I think we should make it explicit in Req2. >=20 >> It is entirely possible to design a >> mechanism that requires no action from 3GPP and the requirement was >> intended to ensure that the resulting mechanism is designed that way. >>=20 >=20 > I understand the design goal but I think you missed the point of my = 3GPP > example. You can certainly design the mechanism and publish an RFC = with "no > action from 3GPP". However, until 3GPP updates and ratifies their = technical > specification (TS) to state that your RFC MUST be supported on a given > reference point, an operator cannot assume multi-vendor = interoperability of > your RFC on that 3GPP reference point.=20 Customers often create MUSTs that don't show up in the standards :-) = That is, there may well be market pressure to implement OC whether or = not the 3GPP normatively requires it. The real issue there is what = happens when some vendors implement it and some don't. Req 16 talks = about that.=20 So far, all the proposed mechanisms require negotiation of support, so = there's no interop problem introduced. That is, if one peer supports it = and the other doesn't, nothing should break, although you won't get the = benefit of the mechanism. I don't think we have an explicit requirement = for negotiation, but I think it's pretty clearly implied by Reqs 6 and = 16. >=20 > /Mark >=20 >> Thanks, >>=20 >> Eric >>=20 >>=20 >> On Dec 19, 2012, at 18:23 , Mark Jones wrote: >>=20 >>>> I think the requirement is trying to say the following: >>>>=20 >>>> "Basic support for overload controls MUST be independent of what >>>> applications a given Diameter node supports. Individual = applications >>>> MAY provide more refined support for overload controls." >>>>=20 >>>=20 >>> I'm not reading a requirement for basic vs. refined support from the >>> current REQ 2 text. I understand that REQ 2 is trying to establish >>> the bounds of acceptable impacts on existing Diameter applications. >>> IMHO it should read something like "the addition of the Diameter >>> overload control mechanism to an existing Diameter application MUST >>> NOT require the allocation of a new application id". Do we need to >> constrain the solution any further? >>>=20 >>> I don't understand the motivation for requiring that it "MUST NOT >>> require specification changes for existing Diameter applications". = If >>> 3GPP decides that Diameter overload control must be supported on an >>> existing reference point, I would expect the 3GPP TS for that = release >>> to be updated to state just that. This is a "specification change" = and >>> I don't see how else a vendor would know that they had to update = their >>> implementation. What am I missing here? >>>=20 >>> /Mark >>>=20 >>>> On 19/12/2012 3:47 AM, Jouni Korhonen wrote: >>>>>=20 >>>>> Hi Ben, >>>>>=20 >>>>> Thanks for the update. Now that the new revision is out I would >>>>> encourage the WG to sort out the language in REQ 2 asap. As long = as >>>>> it is in flux the document cannot proceed to WGLC. >>>>>=20 >>>>> - jouni >>>>>=20 >>>> ... >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Wed Dec 19 13:38:02 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C5321F880E for ; Wed, 19 Dec 2012 13:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.43 X-Spam-Level: X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u9LAKh4PTzcg for ; Wed, 19 Dec 2012 13:38:01 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8508B21F87A6 for ; Wed, 19 Dec 2012 13:38:01 -0800 (PST) Received: from [172.20.10.2] (mobile-166-137-149-039.mycingular.net [166.137.149.39]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qBJLbwTS005069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Dec 2012 15:37:59 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <170E8FCC2134BD42B539B47798ABF8F026C0D0FBA8@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> Date: Wed, 19 Dec 2012 15:37:58 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1C0FBCF9-B792-48FB-ABD7-3E43BBC93BF9@nostrum.com> References: <20121218231927.31153.89871.idtracker@ietfa.amsl.com> <02FF8071-81D1-4CD2-9D97-E906BAA45FC8@nostrum.com> <8B064DAA-E5D5-4B20-BFBA-225DE9576D70@gmail.com> <170E8FCC2134BD42B539B47798ABF8F026C0D0FBA8@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> To: "THIEBAUT, LAURENT (LAURENT)" X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 166.137.149.39 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 21:38:02 -0000 Hi Laurent, comments inline: On Dec 19, 2012, at 2:34 PM, "THIEBAUT, LAURENT (LAURENT)" = wrote: > =20 > =20 > Hello all > Thanks Ben for the new version > I think we are approaching towards the conclusion but would like to = suggest following new requirements > =20 I hope you are right :-) > REQ X: A common default algorithm to react to an overload status = SHOULD be defined in order to allow a basic inter-operable inter Service = Provider overload mechanism. > =20 Do you consider an algorithm for inter-service-provider OC as = necessarily different from a general algorithm?=20 > REQ Y: Even though there are Diameter Agents between 2 Diameter = end-points (client/server) that support the (overload control) feature, = there MUST be a way to report an *overload* status to the Diameter = end-points (client/server) in order for Diameter end-points to be able = to take proper (possibly non Diameter) actions. > =20 I assume from the elaboration below that this includes the case where = the agents do not directly support OC? > =20 > So to us, the remaining work would be on Req2, Req X and Req Y. > =20 > It is recognized that Req Y is almost the same than Req 35 but with > =B7 a "MUST" instead of a "SHOULD" I don't think I object to a MUST (pending conversation on the other = parts) > =B7 the fact that even when the DA supports the mechanism the = end point may need to know an *overload* status (this may be different = for a *load* status) Req 35 already says "overload and load information". Are you looking for = more than that? > =B7 and (minor remark) the indication that the reaction to an = overload status may imply possible non Diameter actions. > =20 Can you elaborate on what you mean by "non Diameter actions"? I think it = likely that many overload conditions will require clients to take action = in whatever application protocol they provide. Nothing really uses = Diameter for it's on sake (we've got a fair amount of text on that in = the introductory sections). But it seems to me the specifics of such = actions belong to those protocols, not this one. Do you expect that the = overload information would some how explicitly signal what non-Diameter = actions a client might need to take? > Best regards > Laurent > ALCATEL-LUCENT > =20 > -----Message d'origine----- > De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part = de Jouni Korhonen > Envoy=E9 : mercredi 19 d=E9cembre 2012 09:48 > =C0 : Ben Campbell > Cc : dime@ietf.org > Objet : Re: [Dime] New Version Notification for = draft-ietf-dime-overload-reqs-02.txt > =20 > =20 > Hi Ben, > =20 > Thanks for the update. Now that the new revision is out > I would encourage the WG to sort out the language in REQ 2 > asap. As long as it is in flux the document cannot proceed > to WGLC. > =20 > - jouni > =20 > =20 > On Dec 19, 2012, at 1:23 AM, Ben Campbell wrote: > =20 > > Hi Everyone, > > > > We've submitted draft-ietf-dime-overload-reqs-02, based on the list = discussions over the last few weeks. We believe this addresses all the = substantive comments so far, except for the ongoing discussion on Req2 = (concerning application independence and the impact on application = specifications.) We've noted the open issue for Req 2 in the text. > > > > The new version is available at = http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-02 . You can = see a diff from version 01 at = http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-dime-o= verload-reqs-02.txt . > > > > Thanks! > > > > Ben. > > > > Begin forwarded message: > > > >> From: internet-drafts@ietf.org > >> Subject: New Version Notification for = draft-ietf-dime-overload-reqs-02.txt > >> Date: December 18, 2012 5:19:27 PM CST > >> To: ben@nostrum.com > >> Cc: emcmurry@computer.org > >> > >> > >> A new version of I-D, draft-ietf-dime-overload-reqs-02.txt > >> has been successfully submitted by Ben Campbell and posted to the > >> IETF repository. > >> > >> Filename: draft-ietf-dime-overload-reqs > >> Revision: 02 > >> Title: Diameter Overload Control Requirements > >> Creation date: 2012-12-17 > >> WG ID: dime > >> Number of pages: 27 > >> URL: = http://www.ietf.org/internet-drafts/draft-ietf-dime-overload-reqs-02.txt > >> Status: = http://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs > >> Htmlized: = http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-02 > >> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-02 > >> > >> Abstract: > >> When a Diameter server or agent becomes overloaded, it needs to be > >> able to gracefully reduce its load, typically by informing clients = to > >> reduce sending traffic for some period of time. Otherwise, it = must > >> continue to expend resources parsing and responding to Diameter > >> messages, possibly resulting in congestion collapse. The existing > >> mechanisms provided by Diameter are not sufficient for this = purpose. > >> This document describes the limitations of the existing = mechanisms, > >> and provides requirements for new overload management mechanisms. > >> > >> > >> > >> > >> The IETF Secretariat > >> > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From mark@azu.ca Wed Dec 19 13:58:59 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F0421F856D for ; Wed, 19 Dec 2012 13:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zr4tBQumHJWn for ; Wed, 19 Dec 2012 13:58:58 -0800 (PST) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) by ietfa.amsl.com (Postfix) with ESMTP id CB01E21F8554 for ; Wed, 19 Dec 2012 13:58:58 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id 13so3607811iea.7 for ; Wed, 19 Dec 2012 13:58:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language:x-gm-message-state; bh=dHVaukLn4Pm5UR79mI+cCY4LZJytzjIWBtHoel+LF8Y=; b=eKrGRDcKDd3Ce/apuvmfmKewrZgHt+BX5imktYKJwR+dnC5FQivOt+krZHSlssAR7H akEzLnHiEh4qvReQaBtLUHP7+2DTjMXL0Cq2BmYUkOAsHOtpjVqgLhdvi59qhXmu3tRO TM0ix+bk40FGd7w835X5FuEMJHgWFqTBcHsC3q+kc0R3CqbFxCAsGS/cp4B1DsG32zQq XsFefCUFu+P61ZX8mjRGixwIrfnD9VzabHJ8kosH/Cp0eOEaw7jDQ+YmmEgRHc1SMeXy ICJHcwXdCCbgNM2lNgynhGQzCt8LQAl90I5ThOMzTf84FA4ol8d6SxkPbE3UHhTgIOE6 flNg== X-Received: by 10.50.13.138 with SMTP id h10mr8711734igc.55.1355954338208; Wed, 19 Dec 2012 13:58:58 -0800 (PST) Received: from victor (75-119-240-140.dsl.teksavvy.com. [75.119.240.140]) by mx.google.com with ESMTPS id uz1sm5198370igb.16.2012.12.19.13.58.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 13:58:56 -0800 (PST) From: "Mark Jones" To: "'Ben Campbell'" , "'Tom Taylor'" References: <20121218231927.31153.89871.idtracker@ietfa.amsl.com> <02FF8071-81D1-4CD2-9D97-E906BAA45FC8@nostrum.com> <8B064DAA-E5D5-4B20-BFBA-225DE9576D70@gmail.com> <50D1E5A3.2030005@gmail.com> <50D21ACB.4060702@gmail.com> <42F0A6F7-CA0F-4F16-9D81-4B21B93A6FFC@nostrum.com> In-Reply-To: <42F0A6F7-CA0F-4F16-9D81-4B21B93A6FFC@nostrum.com> Date: Wed, 19 Dec 2012 16:58:48 -0500 Message-ID: <000001cdde34$09c39250$1d4ab6f0$@azu.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ51F1iApZ/J+YgoUKExYbslzJ06QIE4VajAfTSCAsC0mmzigGx0YWwAs1wf9kCLkLi6pZc7m1A Content-Language: en-ca X-Gm-Message-State: ALoCoQkfdVy4tDtKZD47RTtk/t3fCwTWkLsveFgc+QKPWSpdFTGMzeP08lFwDoEiulWNU7CEf6LI Cc: dime@ietf.org Subject: Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 21:58:59 -0000 Hi Ben, Tom, That explanatory text helps a lot. I still think REQ 2 should be split into two requirements though. I could not find a definition of "default overload control" in the draft. In the context of REQ 2, I interpret it as the overload control mechanism without any application-specific extensions. If I'm right then I think it is safe to replace it with "the overload control mechanism". If I'm wrong, "default overload control" needs to be defined. Could you clarify the difference between the extensibility required by REQ 2 and that required by REQ 34? I assumed the extensibility in REQ 34 was 'application-neutral' but I'd like to confirm. /Mark > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Ben Campbell > Sent: December-19-12 3:16 PM > To: Tom Taylor > Cc: dime@ietf.org > Subject: Re: [Dime] New Version Notification for draft-ietf-dime-overload- > reqs-02.txt > > WFM > > On Dec 19, 2012, at 1:51 PM, Tom Taylor > wrote: > > > > > > > Just a one-word change. > > > > On 19/12/2012 1:30 PM, Ben Campbell wrote: > >> Hi Tom, > >> > >> I think that's on the right track. We've been too focused on > >> specification impact, when the root of the requirement is really a > >> combination of application-independent default behavior, along with > >> extensibility to allow application-specific behavior. > >> > >> To put some finer points on it, how's this? I tried to take the > >> spirit of your proposed text, and added some non-normative > >> elaboration: > >> > >> > >> The mechanism MUST allow Diameter nodes to support default overload > >> control regardless of which Diameter applications they support. It > >> MUST provide sufficient extensibility to allow individual > >> applications to provide more refined overload control. > >> > >> The basic mechanism is intended to be application-independent, that > >> is, a Diameter node can use it across any existing and future > >> Diameter applications and expect reasonable results. Certain Diameter > >> applications might, however, benefit from application-specific > >> behavior over and above the mechanism's defaults. For example, an > >> application might specify relative priorities of > > ^^^^^^^^ > >> messages or selection of a specific overload control algorithm. > >> > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Wed Dec 19 14:03:54 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A854C21F8479 for ; Wed, 19 Dec 2012 14:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d23VOrjuHvRy for ; Wed, 19 Dec 2012 14:03:54 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id BFA5821F862D for ; Wed, 19 Dec 2012 14:03:53 -0800 (PST) Received: from [172.20.10.2] (mobile-166-137-149-039.mycingular.net [166.137.149.39]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qBJM3YhU007912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Dec 2012 16:03:35 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <000001cdde34$09c39250$1d4ab6f0$@azu.ca> Date: Wed, 19 Dec 2012 16:03:35 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121218231927.31153.89871.idtracker@ietfa.amsl.com> <02FF8071-81D1-4CD2-9D97-E906BAA45FC8@nostrum.com> <8B064DAA-E5D5-4B20-BFBA-225DE9576D70@gmail.com> <50D1E5A3.2030005@gmail.com> <50D21ACB.4060702@gmail.com> <42F0A6F7-CA0F-4F16-9D81-4B21B93A6FFC@nostrum.com> <000001cdde34$09c39250$1d4ab6f0$@azu.ca> To: "Mark Jones" X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 166.137.149.39 is authenticated by a trusted mechanism) Cc: dime@ietf.org Subject: Re: [Dime] New Version Notification for draft-ietf-dime-overload-reqs-02.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 22:03:54 -0000 On Dec 19, 2012, at 3:58 PM, "Mark Jones" wrote: > Hi Ben, Tom, >=20 > That explanatory text helps a lot. I still think REQ 2 should be split = into > two requirements though.=20 >=20 > I could not find a definition of "default overload control" in the = draft. In > the context of REQ 2, I interpret it as the overload control mechanism > without any application-specific extensions. If I'm right then I think = it is > safe to replace it with "the overload control mechanism". If I'm = wrong, > "default overload control" needs to be defined. You are correct, and we can probably just say "the overload control = mechanism" >=20 > Could you clarify the difference between the extensibility required by = REQ 2 > and that required by REQ 34? I assumed the extensibility in REQ 34 was > 'application-neutral' but I'd like to confirm. Now that you point it out, I think 34 covers most of what I was trying = to say about extensibility. I don't think anything in 34 prevents = application-specific extensions. (nor does it prevent = application-independent ones). >=20 > /Mark >=20 >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf = Of >> Ben Campbell >> Sent: December-19-12 3:16 PM >> To: Tom Taylor >> Cc: dime@ietf.org >> Subject: Re: [Dime] New Version Notification for = draft-ietf-dime-overload- >> reqs-02.txt >>=20 >> WFM >>=20 >> On Dec 19, 2012, at 1:51 PM, Tom Taylor >> wrote: >>=20 >>>=20 >>>=20 >>> Just a one-word change. >>>=20 >>> On 19/12/2012 1:30 PM, Ben Campbell wrote: >>>> Hi Tom, >>>>=20 >>>> I think that's on the right track. We've been too focused on >>>> specification impact, when the root of the requirement is really a >>>> combination of application-independent default behavior, along with >>>> extensibility to allow application-specific behavior. >>>>=20 >>>> To put some finer points on it, how's this? I tried to take the >>>> spirit of your proposed text, and added some non-normative >>>> elaboration: >>>>=20 >>>>=20 >>>> The mechanism MUST allow Diameter nodes to support default overload >>>> control regardless of which Diameter applications they support. It >>>> MUST provide sufficient extensibility to allow individual >>>> applications to provide more refined overload control. >>>>=20 >>>> The basic mechanism is intended to be application-independent, that >>>> is, a Diameter node can use it across any existing and future >>>> Diameter applications and expect reasonable results. Certain = Diameter >>>> applications might, however, benefit from application-specific >>>> behavior over and above the mechanism's defaults. For example, an >>>> application might specify relative priorities of >>> ^^^^^^^^ >>>> messages or selection of a specific overload control algorithm. >>>>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From jgunn6@csc.com Mon Dec 31 10:43:00 2012 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C537B21F87DE; Mon, 31 Dec 2012 10:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.066 X-Spam-Level: X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDZawjJt4-NU; Mon, 31 Dec 2012 10:42:59 -0800 (PST) Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1CA21F8767; Mon, 31 Dec 2012 10:42:59 -0800 (PST) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-4.tower-85.messagelabs.com!1356979377!27524552!1 X-Originating-IP: [20.137.2.88] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2421 invoked from network); 31 Dec 2012 18:42:57 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-4.tower-85.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Dec 2012 18:42:57 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBVIguSk019047; Mon, 31 Dec 2012 13:42:56 -0500 In-Reply-To: <170E8FCC2134BD42B539B47798ABF8F026C0CA6946@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> References: <170E8FCC2134BD42B539B47798ABF8F026C0CA6946@FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com> To: "THIEBAUT, LAURENT (LAURENT)" MIME-Version: 1.0 X-KeepSent: 897985F4:E538823E-85257AE5:0066B9AA; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Mon, 31 Dec 2012 13:42:55 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 12/31/2012 01:38:06 PM, Serialize complete at 12/31/2012 01:38:06 PM Content-Type: multipart/alternative; boundary="=_alternative 0066CE4885257AE5_=" Cc: dime-bounces@ietf.org, "dime@ietf.org" Subject: Re: [Dime] Dime: Diameter Overload IETF requirements, review: comments on Req 1, 26, 35 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 18:43:00 -0000 This is a multipart message in MIME format. --=_alternative 0066CE4885257AE5_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 VGhleSBsb29rIE9LIHRvIG1lLCBleGNlcHQgZm9yIHRoZSB3b3JkICJhbnlob3ciIHdoaWNoIGNh biBiZSByZW1vdmVkIA0Kd2l0aG91dCBjaGFuZ2luZyB0aGUgc2Vuc2UuDQoNCkphbmV0DQoNClRo aXMgaXMgYSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSANCmRlbGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5kIGtpbmRseSBhZHZpc2Ug dXMgYnkgZS1tYWlsIG9mIHRoZSBtaXN0YWtlIGluIA0KZGVsaXZlcnkuIE5PVEU6IFJlZ2FyZGxl c3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8gDQpiaW5kIENT QyB0byBhbnkgb3JkZXIgb3Igb3RoZXIgY29udHJhY3QgdW5sZXNzIHB1cnN1YW50IHRvIGV4cGxp Y2l0IA0Kd3JpdHRlbiBhZ3JlZW1lbnQgb3IgZ292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJlc3Ns eSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2YgDQplLW1haWwgZm9yIHN1Y2ggcHVycG9zZS4NCg0KDQoN CkZyb206ICAgIlRISUVCQVVULCBMQVVSRU5UIChMQVVSRU5UKSIgDQo8bGF1cmVudC50aGllYmF1 dEBhbGNhdGVsLWx1Y2VudC5jb20+DQpUbzogICAgICJkaW1lQGlldGYub3JnIiA8ZGltZUBpZXRm Lm9yZz4NCkRhdGU6ICAgMTIvMTMvMjAxMiAxMTozMSBBTQ0KU3ViamVjdDogICAgICAgIFJlOiBb RGltZV0gRGltZTogIERpYW1ldGVyIE92ZXJsb2FkIElFVEYgcmVxdWlyZW1lbnRzLCANCnJldmll dzogY29tbWVudHMgb24gUmVxIDEsIDI2LCAzNQ0KU2VudCBieTogICAgICAgIGRpbWUtYm91bmNl c0BpZXRmLm9yZw0KDQoNCg0KIA0KIA0KSGVsbG8gYWxsIA0KV2hpbGUgd2UgdW5kZXJzdGFuZCB0 aGF0IEpKIGNvbW1lbnRzIG9uIFJFUTIgc3RpbGwgcmFpc2VzIGRpc2N1c3Npb24sIGNhbiANCml0 IGJlIGNvbmNsdWRlZCB0aGF0IHRoZXJlIGlzIHNvbWUgc29ydCBvZiBhZ3JlZW1lbnQgb24gdGhl IG90aGVyIGNvbW1lbnRzIA0KZXhwcmVzc2VkIGJ5IEpKPw0KIA0KQmVzdCByZWdhcmRzDQpMYXVy ZW50DQpBTENBVEVMLUxVQ0VOVA0KIA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpEZSA6IFRST1RUSU4sIEpFQU4tSkFDUVVFUyAoSkVBTi1KQUNRVUVTKSAN CkVudm95w6kgOiBqZXVkaSA2IGTDqWNlbWJyZSAyMDEyIDE0OjE3DQrDgCA6IGRpbWVAaWV0Zi5v cmcNCkNjIDogVEhJRUJBVVQsIExBVVJFTlQgKExBVVJFTlQpDQpPYmpldCA6IERpbWU6IERpYW1l dGVyIE92ZXJsb2FkIElFVEYgcmVxdWlyZW1lbnRzLCByZXZpZXcNCiANCkRlYXIgYWxsDQogDQog DQpJbiB0aGUgb2JqZWN0aXZlIG9mIHJlbHlpbmcgb24gSUVURiBzcGVjaWZpY2F0aW9ucyB0byBo YW5kbGUgRGlhbWV0ZXIgDQpvdmVybG9hZCBmb3IgM0dQUCBhcHBsaWNhdGlvbnMsIGFzIEFsY2F0 ZWwtTHVjZW50LCB3ZSBkaWQgYW4gYW5hbHlzaXMgb2YgDQp0aGUgZHJhZnQtaWV0Zi1kaW1lLW92 ZXJsb2FkLXJlcXMtMDEuDQogDQpXZSBjb25zaWRlciB0aGUgbGlzdCBvZiBSRVFzIGRlc2NyaWJl ZCBpbiB0aGUgSUVURiBkcmFmdCBhcyBxdWl0ZSANCmV4dGVuc2l2ZSBhbmQgYWxsIFJFUXMgcmVs ZXZhbnQuIFdlIGhhdmUgdGhlIGZldyBhZGRpdGlvbmFsIGNvbW1lbnRzIHRvIA0Kc3VibWl0IHRv IHRoZSB1cGNvbWluZyBEaW1lIHJldmlldzogDQogDQpXZSBzdWdnZXN0IHRvIHB1dCBtb3JlIGVt cGhhc2lzIGluIFJFUTEgb24gdGhlIGZhY3QgdGhpcyBpcyBib3RoIGZvciBsb2FkIA0KKHByZXZl bnRpdmUpIGFuZCBvdmVybG9hZCAocmVhY3RpdmUpLiBBIHBvc3NpYmxlIHdyaXRpbmc6DQpSRVEg MTogICBUaGUgb3ZlcmxvYWQgbWVjaGFuaXNtIE1VU1QgcHJvdmlkZSBhIGNvbW11bmljYXRpb24g bWV0aG9kIGZvciANCkRpYW1ldGVyIG5vZGVzIHRvIGV4Y2hhbmdlIGxvYWQgYW5kIG92ZXJsb2Fk IGluZm9ybWF0aW9uLg0KIA0KQWJvdXQgUkVRIDIgKOKAnFRoZSBvdmVybG9hZCBtZWNoYW5pc20g TVVTVCBiZSB1c2VhYmxlIHdpdGggYW55IGV4aXN0aW5nIG9yIA0KZnV0dXJlIERpYW1ldGVyIGFw cGxpY2F0aW9uLiAgSXQgTVVTVCBOT1QgcmVxdWlyZSBzcGVjaWZpY2F0aW9uIGNoYW5nZXMgDQpm b3IgZXhpc3RpbmcgRGlhbWV0ZXIgYXBwbGljYXRpb25z4oCdKSwgYW4gZXhpc3RpbmcgYXBwbGlj YXRpb24gbWF5IGV2b2x2ZSANCnRvIHN1cHBvcnQgYW4gb3ZlcmxvYWQgbWVjaGFuaXNtLCBlc3Bl Y2lhbGx5IHdoZW4gdGhlIG92ZXJsb2FkIGhhbmRsaW5nIA0KbWF5IHJlbHkgb24gY2VydGFpbiBh cHBsaWNhdGlvbiBkZXBlbmRlbnQgYmVoYXZpb3JzICh3aGljaCB3b3VsZCBiZSB3aXRoaW4gDQoz R1BQIHNjb3BlIGZvciBhcHBsaWNhdGlvbnMgZGVmaW5lZCBieSAzR1BQKS4gSXQgYWxzbyBtYXkg aGF2ZSBhIA0KY29uc2lzdGVuY3kgaXNzdWUgd2l0aCBSRVExMyDigJxhbGxvd2luZyBmb3IgdGhl IHBvc3NpYmlsaXR5IG9mIGluY3JlYXNlZCANCmZlZWRiYWNrIGZvciBpbmZvcm1hdGlvbiBwaWdn eWJhY2tlZOKAnSBhcyB0aGUgcGlnZ3liYWNraW5nIG1lY2hhbmlzbSBtYXkgDQppbXBhY3QgdGhl IGFwcGxpY2F0aW9uLiBNYXkgYmUgYSBzb2x1dGlvbiBpcyB0byBzdXBwcmVzcyB0aGlzIHNlY29u ZCBwYXJ0IA0Kb2YgdGhlIFJFUTIgKOKAnCBJdCBNVVNUIE5PVCByZXF1aXJlIHNwZWNpZmljYXRp b24gY2hhbmdlcyBmb3IgZXhpc3RpbmcgDQpEaWFtZXRlciBhcHBsaWNhdGlvbnPigJ0pIG9yIHJl dmlldyB0aGUgd29yZGluZy4gDQogDQpPbiBSRVEgMjYsIHdlIGhhdmUgdGhlIGZvbGxvd2luZyBy ZWFkaW5nIHdlIGNvbnNpZGVyIGltcG9ydGFudDogdGhlIA0Kc3BlY2lmaWNhdGlvbnMgb2YgdGhl IGRpYW1ldGVyIGxvYWQvb3ZlcmxvYWQgY29udHJvbCBjYW4gb25seSBnaXZlIGFuIA0Kb3ZlcmFs bCBndWlkYW5jZS4gQWN0dWFsIGFuZCBwcmVjaXNlIHNwZWNpZmljYXRpb24gb2YgdGhlIOKAnHdo aWNoIG1lc3NhZ2UgDQp0eXBlcyBtaWdodCBiZSBkZXNpcmFibGUgdG8gc2VuZCBvciBwcm9jZXNz IG92ZXIgb3RoZXJzIGR1cmluZyB0aW1lcyBvZiANCm92ZXJsb2Fk4oCdIHNob3VsZCBiZSBsZWZ0 IGZvciBlYWNoIGFwcGxpY2F0aW9uIHRvIGRlZmluZSAoZm9yIOKAnCDigKYgIERpYW1ldGVyIA0K c3BlY2lmaWMgY29uc2lkZXJhdGlvbnMpLiBJZiB0aGlzIHJlYWRpbmcgb2YgUkVRIDI2IGlzIHNo YXJlZCwgYSBwb3NzaWJsZSANCnJld29yZGluZyBjb3VsZCBiZTogDQpSRVEgMjY6ICBUaGUgZ2Vu ZXJpYyBzcGVjaWZpY2F0aW9uIGZvciB0aGUgb3ZlcmxvYWQgbWVjaGFuaXNtIFNIT1VMRCBvZmZl ciANCm92ZXJhbGwgZ3VpZGFuY2Ugb24gd2hpY2ggbWVzc2FnZSB0eXBlcyBtaWdodCBiZSBkZXNp cmFibGUgdG8gc2VuZCBvciANCnByb2Nlc3Mgb3ZlciBvdGhlcnMgZHVyaW5nIHRpbWVzIG9mIG92 ZXJsb2FkLCBiYXNlZCBvbiBEaWFtZXRlci1zcGVjaWZpYyANCmNvbnNpZGVyYXRpb25zLiAgRm9y IGV4YW1wbGUsIGl0IG1heSBiZSBtb3JlIGJlbmVmaWNpYWwgdG8gcHJvY2VzcyANCm1lc3NhZ2Vz IGZvciBleGlzdGluZyBzZXNzaW9ucyBhaGVhZCBvZiBuZXcgc2Vzc2lvbnMuIEEgcHJlY2lzZSAN CnNwZWNpZmljYXRpb24gb2YgdGhlIHJlbGF0aXZlIHByaW9yaXRpZXMgb2YgbWVzc2FnZSB0eXBl cyBpbiBjYXNlIG9mIA0Kb3ZlcmxvYWQgd291bGQgYW55aG93IGJlIHVuZGVyIHRoZSByZXNwb25z aWJpbGl0eSBvZiBlYWNoIGFwcGxpY2F0aW9uLg0KIA0KV2UgZXhwcmVzc2VkIHRoZSBwb2ludCB0 aGF0IG92ZXJsb2FkIGhhbmRsaW5nIHNob3VsZCB0YWtlIGludG8gYWNjb3VudCANCnRoYXQgc29t ZSBtZXNzYWdlcyBtYXkgaGF2ZSBhIGhpZ2ggcHJpb3JpdHkgKGVnIHdoZW4gcmVsYXRlZCB0byBh biANCmVtZXJnZW5jeSBvciBhIGhpZ2ggcHJpb3JpdHkgdXNlcuKAnSkuICBUaGlzIGhhbmRsaW5n IHdvdWxkICBiZSBhcHBsaWNhdGlvbiANCmRlcGVuZGVudCBhbmQgc28gZW50ZXJpbmcgdGhlIFJF USAyNiBhcyBhbiBvdmVyYWxsIGd1aWRhbmNlIGJ1dCBpdCBjb3VsZCANCmJlIG1lbnRpb25lZCBp biBSRVEgMjYgYXMgYW4gZXhhbXBsZSB3aXRoIHRoZSBwb3NzaWJsZSB3b3JkaW5nDQrigJwgRm9y IGV4YW1wbGUsIGl0IG1heSBiZSBtb3JlIGJlbmVmaWNpYWwgdG8gcHJvY2VzcyBtZXNzYWdlcyBm b3IgZXhpc3RpbmcgDQpzZXNzaW9ucyBhaGVhZCBvZiBuZXcgc2Vzc2lvbnMgYW5kIHRvIGdpdmUg cHJpb3JpdHkgdG8gcmVxdWVzdHMgYXNzb2NpYXRlZCANCndpdGggZW1lcmdlbmN5IHNlc3Npb25z IG9yIHdpdGggaGlnaCBwcmlvcml0eSB1c2Vyc+KAnQ0KIA0KTGFzdCBzZW50ZW5jZSBvZiBSRVEg MzUgYXBwZWFycyB1bmNsZWFyLCB3b3JkaW5nIG1heSBiZSByZXZpZXdlZCBvciB0aGlzIA0Kc2Vu dGVuY2UgbWF5IGJlIHN1cHByZXNzZWQuDQogDQouIA0KQmVzdCByZWdhcmRzDQogDQpKSmFjcXVl cyBUcm90dGluIA0KQWxjYXRlbC1MdWNlbnQgZGVsZWdhdGUgdG8gM0dQUCBDVDQNCiANCiANCiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWls aW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGltZQ0KDQoNCg== --=_alternative 0066CE4885257AE5_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZXkgbG9vayBPSyB0byBtZSwgZXhjZXB0 IGZvciB0aGUgd29yZA0KJnF1b3Q7YW55aG93JnF1b3Q7IHdoaWNoIGNhbiBiZSByZW1vdmVkIHdp dGhvdXQgY2hhbmdpbmcgdGhlIHNlbnNlLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+SmFuZXQ8YnI+DQo8YnI+DQpUaGlzIGlzIGEgUFJJVkFURSBtZXNz YWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UNCmRlbGV0 ZSB3aXRob3V0IGNvcHlpbmcgYW5kIGtpbmRseSBhZHZpc2UgdXMgYnkgZS1tYWlsIG9mIHRoZSBt aXN0YWtlIGluDQpkZWxpdmVyeS4gTk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0aGlzIGUt bWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0bw0KYmluZCBDU0MgdG8gYW55IG9yZGVyIG9yIG90aGVy IGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNpdCB3cml0dGVuDQphZ3JlZW1lbnQg b3IgZ292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJlc3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2Yg ZS1tYWlsDQpmb3Igc3VjaCBwdXJwb3NlLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48 Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5Gcm9tOiAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij4mcXVvdDtUSElFQkFVVCwgTEFVUkVOVA0KKExBVVJFTlQpJnF1b3Q7ICZsdDtsYXVyZW50LnRo aWViYXV0QGFsY2F0ZWwtbHVjZW50LmNvbSZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNv bG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+VG86ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O2RpbWVAaWV0 Zi5vcmcmcXVvdDsNCiZsdDtkaW1lQGlldGYub3JnJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5EYXRlOiAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4xMi8xMy8y MDEyIDExOjMxIEFNPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9 InNhbnMtc2VyaWYiPlN1YmplY3Q6ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDs8L2ZvbnQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbRGltZV0gRGltZToNCiZuYnNwO0Rp YW1ldGVyIE92ZXJsb2FkIElFVEYgcmVxdWlyZW1lbnRzLCByZXZpZXc6IGNvbW1lbnRzIG9uIFJl cSAxLCAyNiwNCjM1PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9 InNhbnMtc2VyaWYiPlNlbnQgYnk6ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDs8L2ZvbnQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvZm9u dD4NCjxicj4NCjxociBub3NoYWRlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBjb2xv cj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJy PjxhIG5hbWU9X01haWxBdXRvU2lnPjwvYT48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJU YWhvbWEiPkhlbGxvDQphbGwgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZh Y2U9IlRhaG9tYSI+V2hpbGUgd2UgdW5kZXJzdGFuZCB0aGF0IEpKIGNvbW1lbnRzDQpvbiBSRVEy IHN0aWxsIHJhaXNlcyBkaXNjdXNzaW9uLCBjYW4gaXQgYmUgY29uY2x1ZGVkIHRoYXQgdGhlcmUg aXMgc29tZQ0Kc29ydCBvZiBhZ3JlZW1lbnQgb24gdGhlIG90aGVyIGNvbW1lbnRzIGV4cHJlc3Nl ZCBieSBKSj88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFj ZT0iVGFob21hIj5CZXN0IHJlZ2FyZHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJs dWUgZmFjZT0iVGFob21hIj5MYXVyZW50PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1i bHVlIGZhY2U9IlRhaG9tYSI+QUxDQVRFTC1MVUNFTlQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IlRhaG9tYSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGI+PGJyPg0KRGUgOjwvYj4gVFJPVFRJTiwgSkVBTi1KQUNRVUVTIChKRUFOLUpBQ1FVRVMp IDxiPjxicj4NCkVudm95w6kgOjwvYj4gamV1ZGkgNiBkw6ljZW1icmUgMjAxMiAxNDoxNzxiPjxi cj4NCsOAIDo8L2I+IGRpbWVAaWV0Zi5vcmc8Yj48YnI+DQpDYyA6PC9iPiBUSElFQkFVVCwgTEFV UkVOVCAoTEFVUkVOVCk8Yj48YnI+DQpPYmpldCA6PC9iPiBEaW1lOiBEaWFtZXRlciBPdmVybG9h ZCBJRVRGIHJlcXVpcmVtZW50cywgcmV2aWV3PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9 IzAwMDA4MCBmYWNlPSJBcmlhbCI+RGVhciBhbGw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNv bG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkFyaWFsIj5JbiB0aGUgb2JqZWN0aXZlIG9mIHJlbHlpbmcgb24gSUVURiBzcGVjaWZpY2F0 aW9ucw0KdG8gaGFuZGxlIERpYW1ldGVyIG92ZXJsb2FkIGZvciAzR1BQIGFwcGxpY2F0aW9ucywg YXMgQWxjYXRlbC1MdWNlbnQsIHdlDQpkaWQgYW4gYW5hbHlzaXMgb2YgdGhlIDwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxiPmRyYWZ0LWlldGYtZGltZS1vdmVybG9hZC1y ZXFzLTAxLjwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+V2UgY29uc2lk ZXIgdGhlIGxpc3Qgb2YgUkVRcyBkZXNjcmliZWQgaW4NCnRoZSBJRVRGIGRyYWZ0IGFzIHF1aXRl IGV4dGVuc2l2ZSBhbmQgYWxsIFJFUXMgcmVsZXZhbnQuIFdlIGhhdmUgdGhlIGZldw0KYWRkaXRp b25hbCBjb21tZW50cyB0byBzdWJtaXQgdG8gdGhlIHVwY29taW5nIERpbWUgcmV2aWV3OiA8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8dWw+DQo8 bGk+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPlc8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkFyaWFsIj5lDQpzdWdnZXN0IHRvIHB1dCBtb3JlIGVtcGhhc2lzIGluIFJF UTEgb24gdGhlIGZhY3QgdGhpcyBpcyBib3RoIGZvciBsb2FkDQoocHJldmVudGl2ZSkgYW5kIG92 ZXJsb2FkIChyZWFjdGl2ZSkuIEEgcG9zc2libGUgd3JpdGluZzo8L2ZvbnQ+PC91bD48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPlJFUQ0KMTogJm5ic3A7IFRoZSBvdmVybG9hZCBtZWNo YW5pc20gTVVTVCBwcm92aWRlIGEgY29tbXVuaWNhdGlvbiBtZXRob2QgZm9yDQpEaWFtZXRlciBu b2RlcyB0byBleGNoYW5nZTwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzgwMDAwMCBmYWNlPSJD b3VyaWVyIE5ldyI+PHU+DQpsb2FkIGFuZDwvdT48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij4gb3ZlcmxvYWQgaW5mb3JtYXRpb24uPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjx1bD4NCjxsaT48Zm9udCBz aXplPTIgZmFjZT0iQXJpYWwiPkFib3V0IFJFUSAyPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPg0KKOKAnFRoZSBvdmVybG9hZCBtZWNoYW5pc20gTVVTVCBiZSB1c2Vh YmxlIHdpdGggYW55IGV4aXN0aW5nIG9yIGZ1dHVyZSBEaWFtZXRlcg0KYXBwbGljYXRpb24uICZu YnNwO0l0IE1VU1QgTk9UIHJlcXVpcmUgc3BlY2lmaWNhdGlvbiBjaGFuZ2VzIGZvciBleGlzdGlu Zw0KRGlhbWV0ZXIgYXBwbGljYXRpb25z4oCdKSw8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFy aWFsIj4gYW4gZXhpc3RpbmcNCmFwcGxpY2F0aW9uIG1heSBldm9sdmUgdG8gc3VwcG9ydCBhbiBv dmVybG9hZCBtZWNoYW5pc20sIGVzcGVjaWFsbHkgd2hlbg0KdGhlIG92ZXJsb2FkIGhhbmRsaW5n IG1heSByZWx5IG9uIGNlcnRhaW4gYXBwbGljYXRpb24gZGVwZW5kZW50IGJlaGF2aW9ycw0KKHdo aWNoPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48Yj48aT4gPC9p PjwvYj48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj53b3VsZA0KYmUgd2l0aGluIDNH UFAgc2NvcGU8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj5mb3INCmFwcGxpY2F0aW9ucyBkZWZpbmVk IGJ5IDNHUFApLiBJdCBhbHNvIG1heSBoYXZlIGEgY29uc2lzdGVuY3kgaXNzdWUgd2l0aA0KUkVR MTMgPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+4oCcPC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmFsbG93aW5nDQpmb3IgdGhlIHBv c3NpYmlsaXR5IG9mIGluY3JlYXNlZCBmZWVkYmFjayBmb3IgaW5mb3JtYXRpb24gcGlnZ3liYWNr ZWTigJ0NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPmFzIHRoZSBwaWdneWJhY2tp bmcgbWVjaGFuaXNtIG1heSBpbXBhY3QNCnRoZSBhcHBsaWNhdGlvbi4gTWF5IGJlPC9mb250Pjxm b250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48Yj48aT4NCjwvaT48L2I+PC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+YSBzb2x1dGlvbiBpczwvZm9udD48Zm9udCBzaXpl PTIgY29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFy aWFsIj50byBzdXBwcmVzcyB0aGlzIHNlY29uZCBwYXJ0IG9mIHRoZSBSRVEyPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KKOKAnCBJdCBNVVNUIE5PVCByZXF1aXJl IHNwZWNpZmljYXRpb24gY2hhbmdlcyBmb3IgZXhpc3RpbmcgRGlhbWV0ZXIgYXBwbGljYXRpb25z 4oCdKQ0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+b3IgcmV2aWV3IHRoZSB3b3Jk aW5nLiA8L2ZvbnQ+PC91bD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJz cDs8L2ZvbnQ+DQo8dWw+DQo8bGk+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+T24gUkVRIDI2 LCB3ZSBoYXZlIHRoZSBmb2xsb3dpbmcgcmVhZGluZw0Kd2UgY29uc2lkZXIgaW1wb3J0YW50OiB0 aGUgc3BlY2lmaWNhdGlvbnMgb2YgdGhlIGRpYW1ldGVyIGxvYWQvb3ZlcmxvYWQNCmNvbnRyb2wg Y2FuIG9ubHkgZ2l2ZSBhbiBvdmVyYWxsIGd1aWRhbmNlLiBBY3R1YWwgYW5kIHByZWNpc2Ugc3Bl Y2lmaWNhdGlvbg0Kb2YgPHN0cmlrZT50aGU8L3N0cmlrZT48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+IOKAnHdoaWNoDQptZXNzYWdlIHR5cGVzIG1pZ2h0IGJlIGRl c2lyYWJsZSB0byBzZW5kIG9yIHByb2Nlc3Mgb3ZlciBvdGhlcnMgZHVyaW5nDQp0aW1lcyBvZiBv dmVybG9hZOKAnSA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+c2hvdWxkIGJlIGxl ZnQgZm9yDQplYWNoIGFwcGxpY2F0aW9uIHRvIGRlZmluZTwvZm9udD48Zm9udCBzaXplPTIgY29s b3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPg0KKDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGFob21h Ij5mb3I8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj4NCjwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj7igJwg4oCmICZuYnNwO0RpYW1l dGVyIHNwZWNpZmljDQpjb25zaWRlcmF0aW9uczwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGFo b21hIj4pLiBJZiB0aGlzIHJlYWRpbmcgb2YgUkVRDQoyNiBpcyBzaGFyZWQsIDwvZm9udD48Zm9u dCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPmEgPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJUYWhvbWEiPnBvc3NpYmxlDQpyZXdvcmRpbmcgY291bGQgYmU6IDwvZm9udD48L3VsPjxm b250IHNpemU9MiBmYWNlPSJDb25zb2xhcyI+UkVRIDI2OiAmbmJzcDtUaGUNCjwvZm9udD48Zm9u dCBzaXplPTIgY29sb3I9IzgwMDAwMCBmYWNlPSJDb25zb2xhcyI+Z2VuZXJpYyA8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvbnNvbGFzIj5zcGVjaWZpY2F0aW9uDQpmb3IgdGhlIG92ZXJsb2Fk IG1lY2hhbmlzbSBTSE9VTEQgb2ZmZXIgPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jODAwMDAw IGZhY2U9IkNvbnNvbGFzIj5vdmVyYWxsDQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvbnNv bGFzIj5ndWlkYW5jZSBvbiB3aGljaCBtZXNzYWdlIHR5cGVzIG1pZ2h0DQpiZSBkZXNpcmFibGUg dG8gc2VuZCBvciBwcm9jZXNzIG92ZXIgb3RoZXJzIGR1cmluZyB0aW1lcyBvZiBvdmVybG9hZCwg PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxzdHJpa2U+YmFzZWQNCm9uIERpYW1l dGVyLXNwZWNpZmljIGNvbnNpZGVyYXRpb25zPC9zdHJpa2U+PC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJDb25zb2xhcyI+Lg0KJm5ic3A7Rm9yIGV4YW1wbGUsIGl0IG1heSBiZSBtb3JlIGJlbmVm aWNpYWwgdG8gcHJvY2VzcyBtZXNzYWdlcyBmb3IgZXhpc3RpbmcNCnNlc3Npb25zIGFoZWFkIG9m IG5ldyBzZXNzaW9ucy4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jODAwMDAwIGZhY2U9IkNv bnNvbGFzIj5BDQpwcmVjaXNlIHNwZWNpZmljYXRpb24gb2YgdGhlIHJlbGF0aXZlIHByaW9yaXRp ZXMgb2YgbWVzc2FnZSB0eXBlcyBpbiBjYXNlDQpvZiBvdmVybG9hZCB3b3VsZCBhbnlob3cgYmUg dW5kZXIgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIGVhY2ggYXBwbGljYXRpb24uPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjx1bD4N CjxsaT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5XZSBleHByZXNzZWQgdGhlIHBvaW50IHRo YXQgb3ZlcmxvYWQgaGFuZGxpbmcNCnNob3VsZCB0YWtlIGludG8gYWNjb3VudCB0aGF0IHNvbWUg bWVzc2FnZXMgbWF5IGhhdmUgYSBoaWdoIHByaW9yaXR5IChlZw0Kd2hlbiByZWxhdGVkIHRvIGFu IGVtZXJnZW5jeSBvciBhIGhpZ2ggcHJpb3JpdHkgdXNlcuKAnSkuICZuYnNwO1RoaXMgaGFuZGxp bmcNCndvdWxkICZuYnNwO2JlIGFwcGxpY2F0aW9uIGRlcGVuZGVudCBhbmQgc28gZW50ZXJpbmcg dGhlIFJFUSAyNiBhcyBhbiBvdmVyYWxsDQpndWlkYW5jZSBidXQgaXQgY291bGQgYmUgbWVudGlv bmVkIGluIFJFUSAyNiBhcyBhbiBleGFtcGxlIHdpdGggdGhlIHBvc3NpYmxlDQp3b3JkaW5nPC9m b250PjwvdWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj7i gJwgPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkZvcg0KZXhhbXBs ZTwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiwgaXQgbWF5IGJlIG1vcmUg YmVuZWZpY2lhbA0KdG8gcHJvY2VzcyBtZXNzYWdlcyBmb3IgZXhpc3Rpbmcgc2Vzc2lvbnMgYWhl YWQgb2YgbmV3IHNlc3Npb25zIDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzgwMDAwMCBmYWNl PSJDb3VyaWVyIE5ldyI+PHU+YW5kPC91Pg0KPHU+dG8gZ2l2ZSBwcmlvcml0eSB0byByZXF1ZXN0 cyBhc3NvY2lhdGVkIHdpdGggZW1lcmdlbmN5IHNlc3Npb25zIG9yIHdpdGgNCmhpZ2ggcHJpb3Jp dHkgdXNlcnM8L3U+4oCdPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPiZuYnNwOzwvZm9udD4NCjx1bD4NCjxsaT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21h Ij5MYXN0IHNlbnRlbmNlIG9mIFJFUSAzNSBhcHBlYXJzIHVuY2xlYXIsDQp3b3JkaW5nIG1heSBi ZSByZXZpZXdlZCBvciB0aGlzIHNlbnRlbmNlIG1heSBiZSBzdXBwcmVzc2VkLjwvZm9udD48L3Vs Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj4uIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iVGFob21hIj5CZXN0IHJlZ2FyZHM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJBcmlh bCI+SkphY3F1ZXMgVHJvdHRpbiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFs Ij5BbGNhdGVsLUx1Y2VudCBkZWxlZ2F0ZSB0byAzR1BQIENUNDwvZm9udD4NCjxicj48Zm9udCBz aXplPTMgY29sb3I9IzAwMDA4MCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pjx0dD48 Zm9udCBzaXplPTI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpEaU1FIG1haWxpbmcgbGlzdDxicj4NCkRpTUVAaWV0Zi5vcmc8YnI+DQo8L2ZvbnQ+ PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZT48 dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlt ZTwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwvZm9udD48L3R0Pg0KPGJy Pg0K --=_alternative 0066CE4885257AE5_=--