From jouni.nospam@gmail.com Thu Nov 1 05:41: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 9D6FA21F8C20 for ; Thu, 1 Nov 2012 05:41:20 -0700 (PDT) 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 elAExAXGJqmd for ; Thu, 1 Nov 2012 05:41:20 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C9EB821F8C19 for ; Thu, 1 Nov 2012 05:41:19 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so1988532lbo.31 for ; Thu, 01 Nov 2012 05:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ZM17gMABA68DhSY7b05cfrnBjtAa6eh8L3+6hRj14WY=; b=fupxUnLEBZAJSKC5nS+C7dGWTEcv6yB82652w7pS/9dpKEXk57allsPHjQrrMjoJoE THqKjF1tF0E2Sah5eoYfiRssTMVaptmPiyARhFQSDtNYQI0ciPXgWlqEq57Vygpglkci k9euxkntajQbv6k+nAS3rdzfNs3+kjaK9afeMG+JtcUDeOYiqtUnVu1GF+j0xSo9sWCz eA06z2S6ReXxI0X/yuj+Fzy1dvcQfZn60E2Qf+90DnSQHTf8chvXMRjHiLTEZ6X+O/H/ Op9UWa1mHIq+rm5gu08nKa2G77LVWMU7Wes3TzKOQsB4BznRdG+hac0LZMOAiVhwcrUT 1cYA== Received: by 10.112.39.233 with SMTP id s9mr16027848lbk.71.1351773678744; Thu, 01 Nov 2012 05:41:18 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id jk8sm2181273lab.7.2012.11.01.05.41.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 01 Nov 2012 05:41:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <349791D5-EC6A-42ED-BBBA-C35EBCD4586B@nostrum.com> Date: Thu, 1 Nov 2012 14:41:09 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <349791D5-EC6A-42ED-BBBA-C35EBCD4586B@nostrum.com> To: dime@ietf.org X-Mailer: Apple Mail (2.1084) Cc: dime-chairs@tools.ietf.org Subject: Re: [Dime] Preliminary draft agenda.. 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, 01 Nov 2012 12:41:20 -0000 Folks, There is a small change in the agenda: http://www.ietf.org/proceedings/85/agenda/agenda-85-dime I encourage people to read both overload drafts. They share quite a bit of similarities in certain areas (authors did share information prior the submission). There are also different views on how to approach the information dissemination. - Jouni On Oct 23, 2012, at 5:01 PM, Ben Campbell wrote: > Looks good to me! > > Thanks! > > Ben. > > On Oct 23, 2012, at 5:20 AM, jouni korhonen wrote: > >> Folks, >> >> Below is a very drafty draft agenda for the Dime meeting in Atlanta. We >> encourage people to read the documents on both "main topics": Diameter >> overload control and e2e security. Both are now getting hot topics among >> our customer SDOs.. >> >> - Jouni & Lionel >> >> ----- >> >> DIME WG IETF 85: 120 min total >> >> Chairs >> o Agenda and WG update 15 min >> >> Diameter overload control: >> >> Eric McMurry >> o draft-ietf-dime-overload-reqs 15 min >> >> Adam Roach >> o draft-roach-dime-overload-ctrl 30 min >> >> Jouni Korhonen >> o draft-korhonen-dime-ovl 20 min >> >> Buffer for discussion 15 min >> >> Diameter e2e security: >> >> Jouni Korhonen >> o draft-korhonen-dime-e2e-security 15 min >> >> Buffer for discussion 10 min >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > From lionel.morand@orange.com Thu Nov 1 06:22: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 0987921F8BCC for ; Thu, 1 Nov 2012 06:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=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 YtOHCxrmVP3q for ; Thu, 1 Nov 2012 06:22:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 6820C21F8BD9 for ; Thu, 1 Nov 2012 06:22:05 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id E41EF32425A for ; Thu, 1 Nov 2012 14:22:03 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id CE04C4C017 for ; Thu, 1 Nov 2012 14:22:03 +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, 1 Nov 2012 14:22:03 +0100 From: To: "dime@ietf.org" Thread-Topic: Help the NomCom Thread-Index: AQHNuDPhPJh125PvyUaeisGflbl0gg== Date: Thu, 1 Nov 2012 13:22:03 +0000 Message-ID: <14607_1351776123_5092777B_14607_1704_1_6B7134B31289DC4FAF731D844122B36E096BE0@PEXCVZYM13.corporate.adroot.infra.ftgroup> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.24.110314 Subject: [Dime] Help the NomCom 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, 01 Nov 2012 13:22:10 -0000 VGhlIElFVEYgTm9taW5hdGlvbnMgQ29tbWl0dGVlIChOb21Db20pIGNvbnRpbnVlcyB0byBzZWVr IGlucHV0IGZyb20NCnRoZSBJRVRGIENvbW11bml0eS4gVGhlIE5vbUNvbSB3b3VsZCBncmVhdGx5 IGFwcHJlY2lhdGUgYW55IGhlbHAgeW91DQpjb3VsZCBwcm92aWRlIGluIG1ha2luZyBtZW1iZXJz IG9mIHlvdXIgd29ya2luZyBncm91cCBhd2FyZSBvZiB3YXlzIGluDQp3aGljaCB0aGV5IGNhbiBw cm92aWRlIHZhbHVhYmxlIGZlZWRiYWNrIHRvIHRoZSBOb21Db20uDQoNCkluIG9yZGVyIHRvIGVu c3VyZSB0aGF0IHlvdXIgaW5wdXQgaXMgcmVjZWl2ZWQgaW4gdGltZSB0byBiZSB1c2VmdWwsIHRo ZSANCk5vbUNvbSBuZWVkcyB0byByZWNlaXZlIGNvbW11bml0eSBmZWVkYmFjayBvbiBvciBiZWZv cmUgU3VuZGF5LCBOb3ZlbWJlciAxMS4NCg0KVGhlIGZpbmFsIGxpc3Qgb2YgY2FuZGlkYXRlcyAo YXMgcGVyIFJGQyA1NjgwKSB0aGF0IHRoZSBOb21Db20gaXMgDQpjb25zaWRlcmluZyBmb3Igb3Bl biBwb3NpdGlvbnMgY2FuIGJlIGZvdW5kIGF0OiANCmh0dHBzOi8vd3d3LmlldGYub3JnL2dyb3Vw L25vbWNvbS8yMDEyL2lucHV0Lw0KDQpUaGUgTm9tQ29tIHdpbGwgYmUgaG9sZGluZyBvZmZpY2Ug aG91cnMgZHVyaW5nIElFVEYgODUsIE1vbmRheS0NClRodXJzZGF5IGZyb20gMTowMHBtIHRvIDM6 MDBwbSBpbiBSb29tIDMwNS4gVGhlIE5vbUNvbSB3ZWxjb21lcyANCmNvbW1lbnRzIG9uIHNwZWNp ZmljIGluZGl2aWR1YWxzLCBhcyB3ZWxsIGFzIGdlbmVyYWwgZmVlZGJhY2sgcmVsYXRlZCB0byAN CmFueSBvZiB0aGUgcG9zaXRpb25zIHRoYXQgTm9tQ29tIGlzIGNvbnNpZGVyaW5nLg0KDQpOb3Rl OiBBIGxpc3Qgb2YgbGVhZGVyc2hpcCBwb3NpdGlvbnMgdGhhdCB0aGUgTm9tQ29tIGlzIGNvbnNp ZGVyaW5nIGNhbiBiZSANCmZvdW5kIGF0OiBodHRwczovL3d3dy5pZXRmLm9yZy9ncm91cC9ub21j b20vMjAxMi8NCg0KSWYgdGhlIE5vbUNvbSBvZmZpY2UgaG91cnMgYXJlIGluY29udmVuaWVudCBm b3IgeW91IG9yIGlmIHlvdSBjYW5ub3QgDQphdHRlbmQgSUVURiA4NSwgdGhlIE5vbUNvbSBpcyBo YXBweSB0byB0YWtlIGNvbW11bml0eSBpbnB1dCB2aWEgZW1haWwgDQp0byBub21jb20xMiBhdCBp ZXRmLm9yZy4gQWRkaXRpb25hbGx5LCB0aGUgTm9tQ29tIGlzIGhhcHB5IHRvIGFycmFuZ2UgYSAN Cm1lZXRpbmcgb3V0c2lkZSBvZiBvZmZpY2UgaG91cnMsIGp1c3Qgc2VuZCB1cyBlbWFpbCBhbmQg d2UgY2FuIHNldCANCnNvbWV0aGluZyB1cC4NCg0KQ29tbWVudHMgb24gc3BlY2lmaWMgY2FuZGlk YXRlcyBjYW4gYWxzbyBiZSBwcm92aWRlZCB0byB0aGUgTm9tQ29tDQp2aWEgdGhlIHdlYiBmZWVk YmFjayB0b29sOiANCmh0dHBzOi8vd3d3LmlldGYub3JnL2dyb3VwL25vbWNvbS8yMDEyL2lucHV0 Lw0KDQpUaGFuayB5b3UgZm9yIHlvdXIgaGVscCwNCi0gTWF0dCBMZXBpbnNraQ0KICBub21jb20t Y2hhaXIgYXQgaWV0Zi5vcmcNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9p bnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91 IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQg bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKRnJhbmNlIFRlbGVj b20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBp bmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3Qg YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVt YWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm aWVkLgpUaGFuayB5b3UuCgo= From isj-dime@i1.dk Sat Nov 3 09:35: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 965EE21F8B9A for ; Sat, 3 Nov 2012 09:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.45 X-Spam-Level: *** X-Spam-Status: No, score=3.45 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_EQ_DK=1.009, HELO_MISMATCH_DK=1.7, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.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 NgALGjQCgolf for ; Sat, 3 Nov 2012 09:35:56 -0700 (PDT) Received: from i1.dk (unknown [188.176.48.94]) by ietfa.amsl.com (Postfix) with ESMTP id A392E21F8ACA for ; Sat, 3 Nov 2012 09:35:55 -0700 (PDT) Received: from i1.dk (isjsys5 [127.0.0.1]) by i1.dk (Postfix) with ESMTP id DB5235C009C; Sat, 3 Nov 2012 17:35:53 +0100 (CET) Received: from isjsys.int.i1.dk (isjsys-i0.int.i1.dk [IPv6:2001:16d8:dd31:1:219:d1ff:fe90:2bfa]) by i1.dk (Postfix) with ESMTP; Sat, 3 Nov 2012 17:35:53 +0100 (CET) Received: from isjsys.localnet (localhost [IPv6:::1]) by isjsys.int.i1.dk (Postfix) with ESMTP id B11BAE78D1; Sat, 3 Nov 2012 17:35:53 +0100 (CET) From: Ivan Skytte =?iso-8859-1?q?J=F8rgensen?= To: dime@ietf.org Date: Sat, 3 Nov 2012 17:35:53 +0100 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.11-desktop; KDE/4.6.0; x86_64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201211031735.53449.isj-dime@i1.dk> Subject: [Dime] New Version Notification for draft-roach-dime-overload-ctrl-01.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: Sat, 03 Nov 2012 16:35:56 -0000 I have a few comments below. >3. Diameter Node Behavior ... > OPEN ISSUE: SIP Overload Control includes a sequence parameter to > ensure that out-of-order messages do not cause the receiver to act on > state that is no longer accurate. Is message reordering a concern in > Diameter? That is, do we need to include sequence numbers in the > messages to ensure that the receiver does not act on stale state > information? Because Diameter uses only reliable, in-order > transports, it seems that this isn't likely to be an issue. Is there > room for a race when multiple connections are in use? When using multiple streams in SCTP newer packets can overtake older ones if sent on different streams. But is is likely to be only at few seconds out-of-order, so I don't think it matters for load information. >3.2. Diameter Client and Diameter Server Behavior ... > In order to allow recipients of overload information to perform > certain performance optimizations, we also define a new command flag, > called 'O'verload. This bit, when set, indicates that the message > contains at least one Load-Info AVP with a non-zero Overload-Metric > -- in other words, the sending node is overloaded for at least one > context. See Section 7.4 for the definition of the 'O'verload bit. I don't think the O bit will be useful at all. In some diameter stacks it would be easiest to just insert Load-Info AVPs in all answers, thereby making the potential O-bit optimization useless. >3.4. Proactive Load and Overload Communication ... > Similarly, in order to provide > peers the proper data for load distribution, nodes SHOULD send DWR > messages to a peer if the load information most recently sent to that > peer has changed by more than 20% and is more than 5 seconds old. Doesn't the 5 seconds conflicts with RFC3539 section 3.4.1 which calls of minimum DW interval to be 6 seconds ? Also, how was the values 20% and 5 seconds chosen? >5.4. Overload-Info-Scope AVP ... Is there any overwhelming reason for using this format? It would be more in the spirit of diameter to used a grouped AVP for this Finally, I don't like the use of the words "drop" and "loss". I have seen at least one implementation that thinks diameter nodes can silently discard requests, and has therefore implemented timer-based retransmits instead of link-failure-based retransmits. Perhaps a note in the introduction that the word drop is to mean "respond with an error". From isj-dime@i1.dk Sat Nov 3 09:37:22 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 0492D21F8CAB for ; Sat, 3 Nov 2012 09:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.82 X-Spam-Level: *** X-Spam-Status: No, score=3.82 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_EQ_DK=1.009, HELO_MISMATCH_DK=1.7, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.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 VdJSJf66HkR5 for ; Sat, 3 Nov 2012 09:37:21 -0700 (PDT) Received: from i1.dk (unknown [188.176.48.94]) by ietfa.amsl.com (Postfix) with ESMTP id A1F6D21F9136 for ; Sat, 3 Nov 2012 09:37:21 -0700 (PDT) Received: from i1.dk (isjsys5 [127.0.0.1]) by i1.dk (Postfix) with ESMTP id D2E0E5C009F for ; Sat, 3 Nov 2012 17:37:19 +0100 (CET) Received: from isjsys.int.i1.dk (isjsys-i0.int.i1.dk [IPv6:2001:16d8:dd31:1:219:d1ff:fe90:2bfa]) by i1.dk (Postfix) with ESMTP for ; Sat, 3 Nov 2012 17:37:19 +0100 (CET) Received: from isjsys.localnet (localhost [IPv6:::1]) by isjsys.int.i1.dk (Postfix) with ESMTP id C5DBFE78D1 for ; Sat, 3 Nov 2012 17:37:19 +0100 (CET) From: Ivan Skytte =?iso-8859-1?q?J=F8rgensen?= To: dime@ietf.org Date: Sat, 3 Nov 2012 17:37:19 +0100 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.11-desktop; KDE/4.6.0; x86_64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201211031737.19545.isj-dime@i1.dk> Subject: Re: [Dime] New Version Notification for draft-korhonen-dime-ovl-00. 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, 03 Nov 2012 16:37:22 -0000 > 4.5. OC-Algorithm AVP > Drop (0x00000001) > > Messages are plain dropped. It is RECOMMENDED to drop messages > selectively based, for example, on application priorities. This > is the default algorithm. By "drop" don't you mean "not send" ? >4.9. OC-Sending-Rate AVP > > The OC-Sending-Rate (AVP Code TBD11) is of type Float32 and tells the > the maximum Diameter message sending rate per second the sender of > this information wishes to receive Diameter messages. Only positive > values are valid. A value of zero (0.0) of the absence of this AVP > means the information sender has no specific rate preference. The special treatment of the value 0.0 sounds a bit ugly. Are there any diamter stacks that would have difficulties in simply not including the AVP? > If a DOCA server finds the sending rate value proposed by a DOCA > client too big (i.e. too frequent periodic messages), then the DOCA > server MUST send the DOCA-Report-Answer indicating an error and set > the Result-Code to the DIAMETER_RATE_TOO_BIG value. Wouldn't it be better if the DOCA client send a proposed rate, and the server responded with an accepted rate ? From jouni.nospam@gmail.com Sat Nov 3 11:44: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 DAE7D21F9C68 for ; Sat, 3 Nov 2012 11:44:56 -0700 (PDT) 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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 dplDlYxgCZb7 for ; Sat, 3 Nov 2012 11:44:56 -0700 (PDT) Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4398021F9C34 for ; Sat, 3 Nov 2012 11:44:56 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id 56so808022yhq.31 for ; Sat, 03 Nov 2012 11:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=JbI+uQ1Wr70ABiazMvnXgK1tq3kISP+KZhGpBUgY13o=; b=A6lcPU1huwJMrgnCDLylv9v+jUG4iR4Nv5dIB+9w+zrNLbbGCzuVK6cnaTbePJ0xe8 uuSs0ndoRolhTD9nPfkwKBceRiDHKJEzW77XLMe3eW7LjCnx3kqhvYFIq4hG/cbAcVHv htsBrR/K0wQDxRn+SNsrD4LKm9akT70dn+wEr2iC1rHZpXPDPXGEZynkAI6GhfxvBWH+ L9HV9BcqgOiu3qo2kV9avNp6s6tY0rWB7XJKjTxTmTaldo/XVq+EyY2Xu7aT9PypOy/y m/R7dWgx8DbMYEjB3WN3Lq0aAcSnnV8GDRZOlagIL4hYi3dBvbONT8BJD12+HjR2ORQD ohxQ== Received: by 10.236.82.178 with SMTP id o38mr5053478yhe.70.1351968295808; Sat, 03 Nov 2012 11:44:55 -0700 (PDT) Received: from [10.187.88.155] ([38.101.231.254]) by mx.google.com with ESMTPS id z6sm12954494yhl.8.2012.11.03.11.44.54 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 03 Nov 2012 11:44:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: jouni korhonen In-Reply-To: <201211031732.25598.isj@i1.dk> Date: Sat, 3 Nov 2012 20:44:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201211031732.25598.isj@i1.dk> To: =?iso-8859-1?Q?Ivan_Skytte_J=F8rgensen?= X-Mailer: Apple Mail (2.1084) Cc: dime@ietf.org Subject: Re: [Dime] New Version Notification for draft-korhonen-dime-ovl-00.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: Sat, 03 Nov 2012 18:44:57 -0000 Hi, Thanks for the review. See my comments inline. On Nov 3, 2012, at 6:32 PM, Ivan Skytte J=F8rgensen wrote: >> 4.5. OC-Algorithm AVP >> Drop (0x00000001) >>=20 >> Messages are plain dropped. It is RECOMMENDED to drop messages >> selectively based, for example, on application priorities. This >> is the default algorithm. >=20 > By "drop" don't you mean "not send" ? Correct. >> 4.9. OC-Sending-Rate AVP >>=20 >> The OC-Sending-Rate (AVP Code TBD11) is of type Float32 and tells = the >> the maximum Diameter message sending rate per second the sender of >> this information wishes to receive Diameter messages. Only positive >> values are valid. A value of zero (0.0) of the absence of this AVP >> means the information sender has no specific rate preference. >=20 > The special treatment of the value 0.0 sounds a bit ugly. Are there = any diamter stacks that would have difficulties in simply not including = the AVP? Good point. THat could easily be defined as a default behavior when the AVP is absent. >> If a DOCA server finds the sending rate value proposed by a DOCA >> client too big (i.e. too frequent periodic messages), then the DOCA >> server MUST send the DOCA-Report-Answer indicating an error and set >> the Result-Code to the DIAMETER_RATE_TOO_BIG value. >=20 > Wouldn't it be better if the DOCA client send a proposed rate, and the = server responded with an accepted rate ? Could be. I'll think about it. - JOuni From internet-drafts@ietf.org Mon Nov 5 11:42: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 CC77721F85E3; Mon, 5 Nov 2012 11:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 2QStETCgMUzd; Mon, 5 Nov 2012 11:42:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCFE21F8665; Mon, 5 Nov 2012 11:42:10 -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.35 Message-ID: <20121105194210.31773.41583.idtracker@ietfa.amsl.com> Date: Mon, 05 Nov 2012 11:42:10 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-realm-based-redirect-07.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, 05 Nov 2012 19:42: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 : Realm-Based Redirection In Diameter Author(s) : Tina Tsou Ruibing Hao Tom Taylor Filename : draft-ietf-dime-realm-based-redirect-07.txt Pages : 8 Date : 2012-11-05 Abstract: The Diameter protocol allows a Diameter redirect agent to specify one or more individual hosts to which a Diameter message may be redirected by an upstream Diameter node. However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies a mechanism by which this can be achieved. New applications may incorporate this capability by reference to the present document. This memo updates Sections 6.13 and 6.14 of RFC6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time AVPs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-realm-based-redirect There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-realm-based-redirect-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-realm-based-redirect-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From eric.mcmurry@tekelec.com Mon Nov 5 12:44:18 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 4230E21F8A9D for ; Mon, 5 Nov 2012 12:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 unrVWhT5KaD5 for ; Mon, 5 Nov 2012 12:44:17 -0800 (PST) Received: from estacado.net (vicuna.estacado.net [4.30.77.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4537621F8A40 for ; Mon, 5 Nov 2012 12:44:16 -0800 (PST) Received: from [192.168.193.102] (dhcp-43eb.meeting.ietf.org [130.129.67.235]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id qA5Ki6nq070836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 5 Nov 2012 14:44:11 -0600 (CST) (envelope-from eric.mcmurry@tekelec.com) Content-Type: multipart/alternative; boundary="Apple-Mail=_0A78C962-7513-4DB7-8347-B0E6E27C6CBC" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Eric McMurry In-Reply-To: <29B2DD63-402F-4C6C-A8C6-14DDDD9A8EDB@computer.org> Date: Mon, 5 Nov 2012 15:43:58 -0500 Message-Id: <72D702FE-0D1A-4F52-B9FF-E4274BB35966@tekelec.com> References: <709FF87F-1E3E-4117-A848-18E927AB898B@tekelec.com> <9BE16775-D5D4-4822-B5E3-68C9912F428D@computer.org> <29B2DD63-402F-4C6C-A8C6-14DDDD9A8EDB@computer.org> To: Janet P Gunn X-Mailer: Apple Mail (2.1499) 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: Mon, 05 Nov 2012 20:44:18 -0000 --Apple-Mail=_0A78C962-7513-4DB7-8347-B0E6E27C6CBC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Based on discussion in the dime meeting today, I think I understand the = disconnect now. Here's another stab at clear language for this (I'll = get there eventually :-) the network operators may not want the interconnect network to use overload or loading = information. They may only want the information to pass through the = interconnect network without further processing or action by the = interconnect network even if the elements in the interconnect network do = support diameter overload control. How does that work? Thanks, Eric On Oct 30, 2012, at 19:19 , Eric McMurry wrote: > Thanks Janet. comments inline. >=20 > On Oct 30, 2012, at 16:31 , Janet P Gunn wrote: >=20 >> My further comments in line=20 >>=20 >>=20 >>=20 >> In=20 >> =93=85the network operators may not want the=20 >> interconnect to use overload or loading information intended to = pass=20 >> through the interconnect even if the elements in the interconnect=20= >> network do support diameter overload control.=94=20 >> Should that be =93not intended to pass=94?=20 >>=20 >> how about:=20 >>=20 >> the network operators may not=20 >> want the interconnect to use overload or loading information = intended=20 >> to to be conveyed to elements outside of the interconnect = network,=20 >> even if the elements in the interconnect network do support = diameter=20 >> overload control=20 >>=20 >> is that more clear?=20 >>=20 >> I don't think that helps It still seems contradictory - "may = not want ... to use ...information intended to be conveyed to elements = outside..."=20 >> It seems that "information intended to be conveyed to elements = outside ..." is EXACTLY (and only) what you DO WANT the interconnect = to use.=20 >=20 > well, information, and overload or loading information are not = the same thing. Taking the qualifiers off changes the meaning. Even = so, the text is apparently still not working. How about: >=20 >=20 > the network operators may not=20 > want the interconnect to use or act on overload or loading = information intended=20 > for consumption by elements outside of the interconnect = network,=20 > even if the elements in the interconnect network do support = diameter=20 > overload control=20 ... --Apple-Mail=_0A78C962-7513-4DB7-8347-B0E6E27C6CBC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Based = on discussion in the dime meeting today, I think I understand the = disconnect now.  Here's another stab at clear language for this =  (I'll get there eventually :-)

the = network operators may not
        =  want the interconnect network to use overload or loading = information.
         They may only = want the information to pass through the interconnect
  =        network without further processing or action = by the interconnect
         network = even if the elements in the interconnect network do = support
         diameter overload = control.


How does that = work?

Thanks,

Eric
=


On Oct 30, 2012, at 19:19 , Eric = McMurry <emcmurry@computer.org> = wrote:

jgunn6@csc.com> wrote:

My further comments in line



In =
=93=85the network operators may not want the =
  interconnect to use overload or loading information intended to pass
=   through the interconnect even if the elements in the = interconnect
  network do support diameter overload control.=94
Should that be =93not intended to pass=94? =

how about:

the network operators may not
         want the = interconnect to use overload or loading information intended
         to to be conveyed = to elements outside of the interconnect network,
         even if the = elements in the interconnect network do support diameter
         overload = control

is that more clear?

<JPG>  I don't think that helps  It = still seems contradictory -  "may not want ... to use ...information  intended to be conveyed to elements outside..."
It seems that "information  intended to be = conveyed to elements outside ..." is EXACTLY  (and only) what you DO =  WANT the interconnect to use.

<em> well, information, and = overload or loading information are not the same thing.  Taking the = qualifiers off changes the meaning.  Even so, the text is = apparently still not working.  How = about:


the = network operators may not 
    =      want the interconnect to use or act on overload or = loading information intended 
  =        for consumption by elements outside of the = interconnect network, 
    =      even if the elements in the interconnect network do = support diameter 
      =    overload = control 

..= .

= --Apple-Mail=_0A78C962-7513-4DB7-8347-B0E6E27C6CBC-- From jgunn6@csc.com Tue Nov 6 05:57:55 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 34ECD21F8689 for ; Tue, 6 Nov 2012 05:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.844 X-Spam-Level: X-Spam-Status: No, score=-5.844 tagged_above=-999 required=5 tests=[AWL=0.754, BAYES_00=-2.599, 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 nz0bRyh5VF-p for ; Tue, 6 Nov 2012 05:57:54 -0800 (PST) Received: from mail86.messagelabs.com (mail86.messagelabs.com [216.82.242.179]) by ietfa.amsl.com (Postfix) with ESMTP id 3550321F866B for ; Tue, 6 Nov 2012 05:57:53 -0800 (PST) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-11.tower-86.messagelabs.com!1352210272!32376500!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3648 invoked from network); 6 Nov 2012 13:57:52 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-11.tower-86.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Nov 2012 13:57:52 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qA6DvmXd032062 for ; Tue, 6 Nov 2012 08:57:51 -0500 In-Reply-To: <72D702FE-0D1A-4F52-B9FF-E4274BB35966@tekelec.com> References: <709FF87F-1E3E-4117-A848-18E927AB898B@tekelec.com> <9BE16775-D5D4-4822-B5E3-68C9912F428D@computer.org> <29B2DD63-402F-4C6C-A8C6-14DDDD9A8EDB@computer.org> <72D702FE-0D1A-4F52-B9FF-E4274BB35966@tekelec.com> To: Eric McMurry MIME-Version: 1.0 X-KeepSent: 0FB7C385:BE206846-85257AAE:004C9116; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Tue, 6 Nov 2012 08:57:16 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 11/06/2012 08:53:21 AM, Serialize complete at 11/06/2012 08:53:21 AM Content-Type: multipart/alternative; boundary="=_alternative 004CA78585257AAE_=" 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, 06 Nov 2012 13:57:55 -0000 This is a multipart message in MIME format. --=_alternative 004CA78585257AAE_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 WWVzLiAgTm93IEkgdW5kZXJzdGFuZCBpdC4NCg0KVGhhbmtzDQoNCkphbmV0DQoNClRoaXMgaXMg YSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHBsZWFzZSANCmRlbGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5kIGtpbmRseSBhZHZpc2UgdXMgYnkg ZS1tYWlsIG9mIHRoZSBtaXN0YWtlIGluIA0KZGVsaXZlcnkuIE5PVEU6IFJlZ2FyZGxlc3Mgb2Yg Y29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8gDQpiaW5kIENTQyB0byBh bnkgb3JkZXIgb3Igb3RoZXIgY29udHJhY3QgdW5sZXNzIHB1cnN1YW50IHRvIGV4cGxpY2l0IA0K d3JpdHRlbiBhZ3JlZW1lbnQgb3IgZ292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJlc3NseSBwZXJt aXR0aW5nIHRoZSB1c2Ugb2YgDQplLW1haWwgZm9yIHN1Y2ggcHVycG9zZS4NCg0KDQoNCkZyb206 ICAgRXJpYyBNY011cnJ5IDxlcmljLm1jbXVycnlAdGVrZWxlYy5jb20+DQpUbzogICAgIEphbmV0 IFAgR3Vubi9VU0EvQ1NDQENTQw0KQ2M6ICAgICBkaW1lQGlldGYub3JnLCBCZW4gQWxsZW4gQ2Ft cGJlbGwgPGJlbkBub3N0cnVtLmNvbT4NCkRhdGU6ICAgMTEvMDUvMjAxMiAwMzo0NCBQTQ0KU3Vi amVjdDogICAgICAgIFJlOiBbRGltZV0gZGlhbWV0ZXIgb3ZlcmxvYWQgY29udHJvbCByZXF1aXJl bWVudHMgcmV2aWV3DQoNCg0KDQpCYXNlZCBvbiBkaXNjdXNzaW9uIGluIHRoZSBkaW1lIG1lZXRp bmcgdG9kYXksIEkgdGhpbmsgSSB1bmRlcnN0YW5kIHRoZSANCmRpc2Nvbm5lY3Qgbm93LiAgSGVy ZSdzIGFub3RoZXIgc3RhYiBhdCBjbGVhciBsYW5ndWFnZSBmb3IgdGhpcyAgKEknbGwgZ2V0IA0K dGhlcmUgZXZlbnR1YWxseSA6LSkNCg0KdGhlIG5ldHdvcmsgb3BlcmF0b3JzIG1heSBub3QNCiAg ICAgICAgIHdhbnQgdGhlIGludGVyY29ubmVjdCBuZXR3b3JrIHRvIHVzZSBvdmVybG9hZCBvciBs b2FkaW5nIA0KaW5mb3JtYXRpb24uDQogICAgICAgICBUaGV5IG1heSBvbmx5IHdhbnQgdGhlIGlu Zm9ybWF0aW9uIHRvIHBhc3MgdGhyb3VnaCB0aGUgDQppbnRlcmNvbm5lY3QNCiAgICAgICAgIG5l dHdvcmsgd2l0aG91dCBmdXJ0aGVyIHByb2Nlc3Npbmcgb3IgYWN0aW9uIGJ5IHRoZSBpbnRlcmNv bm5lY3QNCiAgICAgICAgIG5ldHdvcmsgZXZlbiBpZiB0aGUgZWxlbWVudHMgaW4gdGhlIGludGVy Y29ubmVjdCBuZXR3b3JrIGRvIA0Kc3VwcG9ydA0KICAgICAgICAgZGlhbWV0ZXIgb3ZlcmxvYWQg Y29udHJvbC4NCg0KDQpIb3cgZG9lcyB0aGF0IHdvcms/DQoNClRoYW5rcywNCg0KRXJpYw0KDQoN Ck9uIE9jdCAzMCwgMjAxMiwgYXQgMTk6MTkgLCBFcmljIE1jTXVycnkgPGVtY211cnJ5QGNvbXB1 dGVyLm9yZz4gd3JvdGU6DQoNClRoYW5rcyBKYW5ldC4gIGNvbW1lbnRzIGlubGluZS4NCg0KT24g T2N0IDMwLCAyMDEyLCBhdCAxNjozMSAsIEphbmV0IFAgR3VubiA8amd1bm42QGNzYy5jb20+IHdy b3RlOg0KDQpNeSBmdXJ0aGVyIGNvbW1lbnRzIGluIGxpbmUgDQoNCg0KDQpJbiANCuKAnOKApnRo ZSBuZXR3b3JrIG9wZXJhdG9ycyBtYXkgbm90IHdhbnQgdGhlIA0KICBpbnRlcmNvbm5lY3QgdG8g dXNlIG92ZXJsb2FkIG9yIGxvYWRpbmcgaW5mb3JtYXRpb24gaW50ZW5kZWQgdG8gcGFzcyANCiAg dGhyb3VnaCB0aGUgaW50ZXJjb25uZWN0IGV2ZW4gaWYgdGhlIGVsZW1lbnRzIGluIHRoZSBpbnRl cmNvbm5lY3QgDQogIG5ldHdvcmsgZG8gc3VwcG9ydCBkaWFtZXRlciBvdmVybG9hZCBjb250cm9s LuKAnSANClNob3VsZCB0aGF0IGJlIOKAnG5vdCBpbnRlbmRlZCB0byBwYXNz4oCdPyANCg0KaG93 IGFib3V0OiANCg0KdGhlIG5ldHdvcmsgb3BlcmF0b3JzIG1heSBub3QgDQogICAgICAgICB3YW50 IHRoZSBpbnRlcmNvbm5lY3QgdG8gdXNlIG92ZXJsb2FkIG9yIGxvYWRpbmcgaW5mb3JtYXRpb24g DQppbnRlbmRlZCANCiAgICAgICAgIHRvIHRvIGJlIGNvbnZleWVkIHRvIGVsZW1lbnRzIG91dHNp ZGUgb2YgdGhlIGludGVyY29ubmVjdCANCm5ldHdvcmssIA0KICAgICAgICAgZXZlbiBpZiB0aGUg ZWxlbWVudHMgaW4gdGhlIGludGVyY29ubmVjdCBuZXR3b3JrIGRvIHN1cHBvcnQgDQpkaWFtZXRl ciANCiAgICAgICAgIG92ZXJsb2FkIGNvbnRyb2wgDQoNCmlzIHRoYXQgbW9yZSBjbGVhcj8gDQoN CjxKUEc+ICBJIGRvbid0IHRoaW5rIHRoYXQgaGVscHMgIEl0IHN0aWxsIHNlZW1zIGNvbnRyYWRp Y3RvcnkgLSAgIm1heSBub3QgDQp3YW50IC4uLiB0byB1c2UgLi4uaW5mb3JtYXRpb24gIGludGVu ZGVkIHRvIGJlIGNvbnZleWVkIHRvIGVsZW1lbnRzIA0Kb3V0c2lkZS4uLiIgDQpJdCBzZWVtcyB0 aGF0ICJpbmZvcm1hdGlvbiAgaW50ZW5kZWQgdG8gYmUgY29udmV5ZWQgdG8gZWxlbWVudHMgb3V0 c2lkZSANCi4uLiIgaXMgRVhBQ1RMWSAgKGFuZCBvbmx5KSB3aGF0IHlvdSBETyAgV0FOVCB0aGUg aW50ZXJjb25uZWN0IHRvIHVzZS4gDQoNCjxlbT4gd2VsbCwgaW5mb3JtYXRpb24sIGFuZCBvdmVy bG9hZCBvciBsb2FkaW5nIGluZm9ybWF0aW9uIGFyZSBub3QgdGhlIA0Kc2FtZSB0aGluZy4gIFRh a2luZyB0aGUgcXVhbGlmaWVycyBvZmYgY2hhbmdlcyB0aGUgbWVhbmluZy4gIEV2ZW4gc28sIHRo ZSANCnRleHQgaXMgYXBwYXJlbnRseSBzdGlsbCBub3Qgd29ya2luZy4gIEhvdyBhYm91dDoNCg0K DQp0aGUgbmV0d29yayBvcGVyYXRvcnMgbWF5IG5vdCANCiAgICAgICAgIHdhbnQgdGhlIGludGVy Y29ubmVjdCB0byB1c2Ugb3IgYWN0IG9uIG92ZXJsb2FkIG9yIGxvYWRpbmcgDQppbmZvcm1hdGlv biBpbnRlbmRlZCANCiAgICAgICAgIGZvciBjb25zdW1wdGlvbiBieSBlbGVtZW50cyBvdXRzaWRl IG9mIHRoZSBpbnRlcmNvbm5lY3QgbmV0d29yaywgDQogICAgICAgICBldmVuIGlmIHRoZSBlbGVt ZW50cyBpbiB0aGUgaW50ZXJjb25uZWN0IG5ldHdvcmsgZG8gc3VwcG9ydCANCmRpYW1ldGVyIA0K ICAgICAgICAgb3ZlcmxvYWQgY29udHJvbCANCg0KLi4uDQoNCg0K --=_alternative 004CA78585257AAE_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllcy4gJm5ic3A7Tm93IEkgdW5kZXJzdGFu ZCBpdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRo YW5rczwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SmFu ZXQ8YnI+DQo8YnI+DQpUaGlzIGlzIGEgUFJJVkFURSBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UNCmRlbGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5k IGtpbmRseSBhZHZpc2UgdXMgYnkgZS1tYWlsIG9mIHRoZSBtaXN0YWtlIGluDQpkZWxpdmVyeS4g Tk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0aGlzIGUtbWFpbCBzaGFsbCBub3Qgb3BlcmF0 ZSB0bw0KYmluZCBDU0MgdG8gYW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJz dWFudCB0byBleHBsaWNpdCB3cml0dGVuDQphZ3JlZW1lbnQgb3IgZ292ZXJubWVudCBpbml0aWF0 aXZlIGV4cHJlc3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2YgZS1tYWlsDQpmb3Igc3VjaCBwdXJw b3NlLjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVm NWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5Gcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5FcmljIE1jTXVycnkgJmx0O2Vy aWMubWNtdXJyeUB0ZWtlbGVjLmNvbSZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9y PSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+VG86ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPkphbmV0IFAgR3Vubi9VU0Ev Q1NDQENTQzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5z LXNlcmlmIj5DYzogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzwvZm9udD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+ZGltZUBpZXRmLm9yZywgQmVuDQpBbGxlbiBDYW1wYmVsbCAm bHQ7YmVuQG5vc3RydW0uY29tJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVm NWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5EYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4xMS8wNS8yMDEyIDAzOjQ0IFBN PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYi PlN1YmplY3Q6ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbRGltZV0gZGlhbWV0ZXINCm92ZXJsb2FkIGNvbnRyb2wg cmVxdWlyZW1lbnRzIHJldmlldzwvZm9udD4NCjxicj4NCjxociBub3NoYWRlPg0KPGJyPg0KPGJy Pg0KPGJyPjxmb250IHNpemU9Mz5CYXNlZCBvbiBkaXNjdXNzaW9uIGluIHRoZSBkaW1lIG1lZXRp bmcgdG9kYXksIEkgdGhpbmsNCkkgdW5kZXJzdGFuZCB0aGUgZGlzY29ubmVjdCBub3cuICZuYnNw O0hlcmUncyBhbm90aGVyIHN0YWIgYXQgY2xlYXIgbGFuZ3VhZ2UNCmZvciB0aGlzICZuYnNwOyhJ J2xsIGdldCB0aGVyZSBldmVudHVhbGx5IDotKTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTM+dGhlIG5ldHdvcmsgb3BlcmF0b3JzIG1heSBub3Q8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt3YW50IHRoZSBpbnRlcmNvbm5lY3QN Cm5ldHdvcmsgdG8gdXNlIG92ZXJsb2FkIG9yIGxvYWRpbmcgaW5mb3JtYXRpb24uPC9mb250Pg0K PGJyPjxmb250IHNpemU9Mz4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhleSBt YXkgb25seSB3YW50IHRoZQ0KaW5mb3JtYXRpb24gdG8gcGFzcyB0aHJvdWdoIHRoZSBpbnRlcmNv bm5lY3Q8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtuZXR3b3JrIHdpdGhvdXQgZnVydGhlcg0KcHJvY2Vzc2luZyBvciBhY3Rpb24gYnkg dGhlIGludGVyY29ubmVjdDwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO25ldHdvcmsgZXZlbiBpZiB0aGUNCmVsZW1lbnRzIGluIHRoZSBp bnRlcmNvbm5lY3QgbmV0d29yayBkbyBzdXBwb3J0PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGlhbWV0ZXIgb3ZlcmxvYWQgY29udHJv bC48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkhvdyBkb2VzIHRoYXQgd29y az88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPlRoYW5rcyw8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0zPkVyaWM8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0z Pk9uIE9jdCAzMCwgMjAxMiwgYXQgMTk6MTkgLCBFcmljIE1jTXVycnkgJmx0OzwvZm9udD48YSBo cmVmPW1haWx0bzplbWNtdXJyeUBjb21wdXRlci5vcmc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+ PHU+ZW1jbXVycnlAY29tcHV0ZXIub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPiZndDsN Cndyb3RlOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+VGhhbmtzIEphbmV0LiAmbmJz cDtjb21tZW50cyBpbmxpbmUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5PbiBPY3Qg MzAsIDIwMTIsIGF0IDE2OjMxICwgSmFuZXQgUCBHdW5uICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWls dG86amd1bm42QGNzYy5jb20+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+amd1bm42QGNzYy5j b208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+Jmd0Ow0Kd3JvdGU6PC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5NeSBmdXJ0aGVyIGNvbW1lbnRzIGlu IGxpbmU8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPGJyPg0KPGJyPg0KPGJyPg0KPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJDYWxpYnJpIj48YnI+DQpJbjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+PGJyPg0K4oCc4oCmdGhlIG5ldHdvcmsgb3Bl cmF0b3JzIG1heSBub3Qgd2FudCB0aGU8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkNhbGlicmkiPjxicj4NCiAmbmJzcDtpbnRlcmNvbm5lY3QgdG8gdXNlIG92 ZXJsb2FkIG9yIGxvYWRpbmcgaW5mb3JtYXRpb24gaW50ZW5kZWQgdG8NCnBhc3M8L2ZvbnQ+PGZv bnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPjxicj4NCiAmbmJz cDt0aHJvdWdoIHRoZSBpbnRlcmNvbm5lY3QgZXZlbiBpZiB0aGUgZWxlbWVudHMgaW4gdGhlIGlu dGVyY29ubmVjdDwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNhbGlicmkiPjxicj4NCiAmbmJzcDtuZXR3b3JrIGRvIHN1cHBvcnQgZGlhbWV0ZXIgb3Zlcmxv YWQgY29udHJvbC7igJ08L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJDYWxpYnJpIj48YnI+DQpTaG91bGQgdGhhdCBiZSDigJxub3QgaW50ZW5kZWQgdG8gcGFz c+KAnT88L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8YnI+DQpob3cgYWJvdXQ6IDxicj4NCjxi cj4NCnRoZSBuZXR3b3JrIG9wZXJhdG9ycyBtYXkgbm90IDxicj4NCiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgd2FudCB0aGUgaW50ZXJjb25uZWN0IHRvIHVzZSBvdmVybG9hZCBvciBsb2Fk aW5nDQppbmZvcm1hdGlvbiBpbnRlbmRlZCA8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHRvIHRvIGJlIGNvbnZleWVkIHRvIGVsZW1lbnRzIG91dHNpZGUgb2YgdGhlDQppbnRlcmNv bm5lY3QgbmV0d29yaywgPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBldmVuIGlm IHRoZSBlbGVtZW50cyBpbiB0aGUgaW50ZXJjb25uZWN0IG5ldHdvcmsNCmRvIHN1cHBvcnQgZGlh bWV0ZXIgPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBvdmVybG9hZCBjb250cm9s IDxicj4NCjxicj4NCmlzIHRoYXQgbW9yZSBjbGVhcj8gPGJyPg0KPGJyPg0KJmx0O0pQRyZndDsg Jm5ic3A7SSBkb24ndCB0aGluayB0aGF0IGhlbHBzICZuYnNwO0l0IHN0aWxsIHNlZW1zIGNvbnRy YWRpY3RvcnkNCi0gJm5ic3A7JnF1b3Q7bWF5IG5vdCB3YW50IC4uLiB0byB1c2UgLi4uaW5mb3Jt YXRpb24gJm5ic3A7aW50ZW5kZWQgdG8NCmJlIGNvbnZleWVkIHRvIGVsZW1lbnRzIG91dHNpZGUu Li4mcXVvdDsgPGJyPg0KSXQgc2VlbXMgdGhhdCAmcXVvdDtpbmZvcm1hdGlvbiAmbmJzcDtpbnRl bmRlZCB0byBiZSBjb252ZXllZCB0byBlbGVtZW50cw0Kb3V0c2lkZSAuLi4mcXVvdDsgaXMgRVhB Q1RMWSAmbmJzcDsoYW5kIG9ubHkpIHdoYXQgeW91IERPICZuYnNwO1dBTlQgdGhlDQppbnRlcmNv bm5lY3QgdG8gdXNlLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPiZsdDtlbSZndDsg d2VsbCwgaW5mb3JtYXRpb24sIGFuZCBvdmVybG9hZCBvciBsb2FkaW5nDQppbmZvcm1hdGlvbiBh cmUgbm90IHRoZSBzYW1lIHRoaW5nLiAmbmJzcDtUYWtpbmcgdGhlIHF1YWxpZmllcnMgb2ZmIGNo YW5nZXMNCnRoZSBtZWFuaW5nLiAmbmJzcDtFdmVuIHNvLCB0aGUgdGV4dCBpcyBhcHBhcmVudGx5 IHN0aWxsIG5vdCB3b3JraW5nLiAmbmJzcDtIb3cNCmFib3V0OjwvZm9udD4NCjxicj4NCjxicj4N Cjxicj48Zm9udCBzaXplPTM+dGhlIG5ldHdvcmsgb3BlcmF0b3JzIG1heSBub3QgPGJyPg0KICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB3YW50IHRoZSBpbnRlcmNvbm5lY3QgdG8gdXNlIG9y IGFjdCBvbiBvdmVybG9hZA0Kb3IgbG9hZGluZyBpbmZvcm1hdGlvbiBpbnRlbmRlZCA8YnI+DQog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGZvciBjb25zdW1wdGlvbiBieSBlbGVtZW50cyBv dXRzaWRlIG9mIHRoZQ0KaW50ZXJjb25uZWN0IG5ldHdvcmssIDxicj4NCiAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgZXZlbiBpZiB0aGUgZWxlbWVudHMgaW4gdGhlIGludGVyY29ubmVjdCBu ZXR3b3JrDQpkbyBzdXBwb3J0IGRpYW1ldGVyIDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgb3ZlcmxvYWQgY29udHJvbCA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPi4u LjwvZm9udD4NCjxicj4NCjxicj4NCg== --=_alternative 004CA78585257AAE_=-- From jouni.korhonen@iki.fi Sun Nov 11 16:49:16 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 2E54821F8460 for ; Sun, 11 Nov 2012 16:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 LBSMJZdbG1Yv for ; Sun, 11 Nov 2012 16:49:15 -0800 (PST) Received: from vs15.mail.saunalahti.fi (vs15.mail.saunalahti.fi [62.142.117.202]) by ietfa.amsl.com (Postfix) with ESMTP id 95FE621F84A0 for ; Sun, 11 Nov 2012 16:49:15 -0800 (PST) Received: from vams (localhost [127.0.0.1]) by vs15.mail.saunalahti.fi (Postfix) with SMTP id 02FD84004B; Mon, 12 Nov 2012 02:49:12 +0200 (EET) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by vs15.mail.saunalahti.fi (Postfix) with ESMTP id DBBEB4004B; Mon, 12 Nov 2012 02:49:11 +0200 (EET) Received: from [188.117.15.106] (unknown [188.117.15.106]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id 4D78321662F; Mon, 12 Nov 2012 02:49:09 +0200 (EET) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 12 Nov 2012 02:49:08 +0200 Message-Id: <43BD79B0-588D-4571-B1F3-FBBE9526F376@iki.fi> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [Dime] draft meeting minutes uploaded; please verify 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, 12 Nov 2012 00:49:16 -0000 Folks, The draft meeting minutes are available: http://www.ietf.org/proceedings/85/minutes/minutes-85-dime Thanks to Jean for excellent job on writing the bulk of those down! I did only minor editing on this. There is one comment that I could not memorize what was the ending of it. The place is during the overload control discussion part and on Ben's comment (marked with [??]). That should get fixed there. - Jouni From internet-drafts@ietf.org Mon Nov 12 12:39: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 41E9D21F877C; Mon, 12 Nov 2012 12:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=-0.027, 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 ql8nS6G2TxQq; Mon, 12 Nov 2012 12:39:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82A721F8772; Mon, 12 Nov 2012 12:39:20 -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: <20121112203920.29570.44441.idtracker@ietfa.amsl.com> Date: Mon, 12 Nov 2012 12:39:20 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-overload-reqs-01.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, 12 Nov 2012 20:39:21 -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-01.txt Pages : 26 Date : 2012-11-12 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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From eric.mcmurry@tekelec.com Mon Nov 12 12:44: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 A0CDB21F8765 for ; Mon, 12 Nov 2012 12:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 JhH2lHdZPrp0 for ; Mon, 12 Nov 2012 12:44:02 -0800 (PST) Received: from estacado.net (vicuna.estacado.net [4.30.77.35]) by ietfa.amsl.com (Postfix) with ESMTP id 01F4921F857C for ; Mon, 12 Nov 2012 12:44:01 -0800 (PST) Received: from [10.12.30.152] ([10.12.30.152]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id qACKi0KQ050495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 12 Nov 2012 14:44:01 -0600 (CST) (envelope-from eric.mcmurry@tekelec.com) From: Eric McMurry Content-Type: multipart/alternative; boundary="Apple-Mail=_8A5DA31A-F810-41C6-B1F7-C8D03806E1B2" Message-Id: <41C1746D-F60D-4D3B-BADF-35DD7423D013@tekelec.com> Date: Mon, 12 Nov 2012 14:44:00 -0600 To: "dime@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [Dime] overload requirements update 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, 12 Nov 2012 20:44:02 -0000 --Apple-Mail=_8A5DA31A-F810-41C6-B1F7-C8D03806E1B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Per Glen's recommendation, I cut an 01 version of the requirements draft = for overload control: Filename: draft-ietf-dime-overload-reqs Revision: 01 Title: Diameter Overload Control Requirements Creation date: 2012-11-12 WG ID: dime Number of pages: 26 URL: = http://www.ietf.org/internet-drafts/draft-ietf-dime-overload-reqs-01.txt Status: = http://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs Htmlized: = http://tools.ietf.org/html/draft-ietf-dime-overload-reqs-01 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-01 This addresses list comments to date. Still outstanding are comments = from Jouni and Tom, which will be incorporated into an 02 along with any = other feedback received. This is pretty close to done, so please have a = look and provide comments if you have not done so already. Thanks, Eric --Apple-Mail=_8A5DA31A-F810-41C6-B1F7-C8D03806E1B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Per = Glen's recommendation, I cut an 01 version of the requirements draft for = overload control:

Filename:  01
Title:  Diameter Overload Control Requirements
Creation date:  2012-11-12
WG ID: Number of pages: 26
URL: =             Status: =          Htmlized: =        Diff: =            <= a = href=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-0= 1" style=3D"font-family: monospace; = ">http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-overload-reqs-01<= br style=3D"font-family: monospace; = ">


This addresses list comments = to date.  Still outstanding are comments from Jouni and Tom, which = will be incorporated into an 02 along with any other feedback received. =  This is pretty close to done, so please have a look and provide = comments if you have not done so = already.

Thanks,

Eric


= --Apple-Mail=_8A5DA31A-F810-41C6-B1F7-C8D03806E1B2-- From jouni.nospam@gmail.com Thu Nov 22 06:28:18 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 55DF321F8485 for ; Thu, 22 Nov 2012 06:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=-1.025, BAYES_00=-2.599, FRT_BELOW2=2.154, 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 nYrCoq7WADVU for ; Thu, 22 Nov 2012 06:28:17 -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 6E2BD21F8467 for ; Thu, 22 Nov 2012 06:28:17 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so6785087lah.31 for ; Thu, 22 Nov 2012 06:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=zonKni5TTXn6sVHtVfwtRI8INYo/YlnzgR4UkR7E2Yk=; b=e2IOj3VM9DfZ3MFUyt23Jr8pObihbDo/+boe17dcQn6Jv0u14bfgwehKjvHOyUWhzl kiLEk9BO07139gm8TWtvH1Csss2RM7rf1S75DOTQMBYk/coeAXsNaQFL/yit36ZF6gIl rBOcEgJaVPr4KMVtCeOawf2jiezsPuniGaEDzLVGaQOnxvlwcLk5VR7aeJ/KhztRuCNF MOqPpPrESvtXzUcyh/vb59cKCZbTClUIeGi1Yn8YgGevgvq9e+c9EURGsYO93vGRGX9H nAkqXBQnBwdwgnOdG0RAcucaYzK1l7KyG92Qs0Usa4QrA9EKryj6alYBEb72RS0q4TLr lV0g== Received: by 10.152.111.131 with SMTP id ii3mr606785lab.37.1353594496408; Thu, 22 Nov 2012 06:28:16 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id jk8sm1317004lab.7.2012.11.22.06.28.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Nov 2012 06:28:14 -0800 (PST) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 22 Nov 2012 16:28:12 +0200 Message-Id: <5E7FEE8E-F6E8-4470-8823-E97382C73661@gmail.com> To: dime@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [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, 22 Nov 2012 14:28:18 -0000 Hi, I have briefly reviewed draft-ietf-dime-overload-req-00 again. Sorry for the extended delay! Some comments beflow: Section 2.3. Interconnect Scenario o Explain IPX and provide appropriate references so that the reader can get the context. Section 4. Existing Mechanisms o I would also add DPR with Disconnect-Cause=DO_NOT_WANT_TO_TALK_TO_YOU discussion here. IMHO it is also valid mechanism, though a bit cruel. Section 5.2. Problems with Explicit Mechanisms o See the DPR above. o Then a flow of mind/thinking.. since protocol level errors like DIAMETER_UNABLE_TO_DELIVER and DIAMETER_TOO_BUSY are delivered using a specific CCF, why cannot we just put overload whatever information there? That would be a better than nothing approach to tackle a class of overload cases. Basically one could add AVPs that describe specifically why DIAMETER_UNABLE_TO_DELIVER and DIAMETER_TOO_BUSY took place and what need to be done to get over that situation. And these errors can be sent by any intermediate Diameter node, not just the end points. I think we need to cover these errors a bit better than just saying they are no usable. (the additional data falls into *[AVP] wildcard in the error response and is understood by the receiver or then not..) 6.1. Overload in Mobile Data Networks o I'd like to see quite a few references here.. 23.002, 29.272, 29.002, IR.92, .. o PCC and IMS seem to have been skipped here (except indirectly covered by VoLTE). 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. o Req13: related to this, I would also have some text here or on some other requirement regarding the additional size overhead introduced by the overload mechanism. That must also be taken into account. 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. o Req21: I see the intention but how do you qualify some node meets the requirement? To me this requirement equals to implicit mechanisms i.e. the other end does not really respond so it probably i having issues. Typically the other ends start resending, which just worsens the situation, right? 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? 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.. - JOuni From jouni.nospam@gmail.com Thu Nov 22 10:37: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 31E4821F853F for ; Thu, 22 Nov 2012 10:37:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.106, 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 oHmZqvSL2A8u for ; Thu, 22 Nov 2012 10:37:42 -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 0BC4821F8443 for ; Thu, 22 Nov 2012 10:37:41 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so7062734lbk.31 for ; Thu, 22 Nov 2012 10:37:41 -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 :content-transfer-encoding:message-id:references:to:x-mailer; bh=GYitDAFvekfZuFAChLkbLpYMYHc0OgwwfBDY0Bb3BPg=; b=itdXKdOCkMU9YM5JGyRNBlSSExbSLS/io9nO2Uc5Qqwt0vDelFG/+48sZ2e2w2Zqmv p3kSWRE1wjSnNkR54zO3tdAZrAPtA3skaSb5uMBaw3YJjfaEg7kW9Ic4KQuM9+mS7wzn 2hQAQIybHonk8Cb5GspzX8yAniikAuPkVTHCwkFG9g9Bn3NIkuVcenOI/pQ8XcKYWQsi R/teasOm3oorthn4cLSSl8jakpOy4jjLch7EK062FtLHhtl1f+kt4dNRBw3w2wMbKyY2 lnrZnXmDZ4s11wYKC8Lmu4n5o0r31aTPflGzPPw2Bc680rx4YrUm11FYO2P8zFUhh+wg 55jg== Received: by 10.112.36.200 with SMTP id s8mr909567lbj.92.1353609460903; Thu, 22 Nov 2012 10:37:40 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id gr12sm1562114lab.3.2012.11.22.10.37.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Nov 2012 10:37:39 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: jouni korhonen In-Reply-To: <5E7FEE8E-F6E8-4470-8823-E97382C73661@gmail.com> Date: Thu, 22 Nov 2012 20:37:35 +0200 Content-Transfer-Encoding: 7bit Message-Id: <59CD75A7-CCC7-4A82-B662-5FB8B701C0D5@gmail.com> References: <5E7FEE8E-F6E8-4470-8823-E97382C73661@gmail.com> To: dime@ietf.org X-Mailer: Apple Mail (2.1085) 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, 22 Nov 2012 18:37:43 -0000 On Nov 22, 2012, at 4:28 PM, jouni korhonen wrote: > Hi, > > I have briefly reviewed draft-ietf-dime-overload-req-00 again. Sorry for ^^^ meant -01 - Jouni [snip] From emcmurry@computer.org Mon Nov 26 17:17: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 88D4321F8427 for ; Mon, 26 Nov 2012 17:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.445 X-Spam-Level: X-Spam-Status: No, score=-0.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154] 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 96-SDa-4cAGI for ; Mon, 26 Nov 2012 17:17:47 -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 BD43D21F842C for ; Mon, 26 Nov 2012 17:17:47 -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 1Td9o2-000Ix6-Ti; Tue, 27 Nov 2012 01:17:47 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id 6844FA426F1; Mon, 26 Nov 2012 19:17:45 -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+n10FKCVAaNwL7Dx9uLMfDKzDaqzlPyg8= 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 xDbkdrFNBneW; Mon, 26 Nov 2012 19:17:45 -0600 (CST) Received: from ericlaptop.casamcmurry.com (ericlaptop.casamcmurry.com [192.168.111.91]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 1588FA426E7; Mon, 26 Nov 2012 19:17: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: <5E7FEE8E-F6E8-4470-8823-E97382C73661@gmail.com> Date: Mon, 26 Nov 2012 19:17:43 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E7FEE8E-F6E8-4470-8823-E97382C73661@gmail.com> To: jouni korhonen X-Mailer: Apple Mail (2.1499) Cc: ERIC C NOEL , 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, 27 Nov 2012 01:17:48 -0000 Thanks Jouni! Comments are greatly appreciated. commentary inline. On Nov 22, 2012, at 8:28 , jouni korhonen = wrote: > Hi, >=20 > I have briefly reviewed draft-ietf-dime-overload-req-00 again. Sorry = for > the extended delay! Some comments beflow: >=20 > Section 2.3. Interconnect Scenario >=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? >=20 > Section 4. Existing Mechanisms >=20 > o I would also add DPR with = Disconnect-Cause=3DDO_NOT_WANT_TO_TALK_TO_YOU > discussion here. IMHO it is also valid mechanism, though a bit = cruel. agree, I'll add that to the discussion. I think BUSY may be a better = disconnect cause for this case though, right? The effects are the same = either way. >=20 > Section 5.2. Problems with Explicit Mechanisms >=20 > o See the DPR above. >=20 yep > o Then a flow of mind/thinking.. since protocol level errors like > DIAMETER_UNABLE_TO_DELIVER and DIAMETER_TOO_BUSY are delivered using > a specific CCF, why cannot we just put overload whatever information > there? That would be a better than nothing approach to tackle a = class > of overload cases. Basically one could add AVPs that describe = specifically > why DIAMETER_UNABLE_TO_DELIVER and DIAMETER_TOO_BUSY took place and=20= > what need to be done to get over that situation. And these errors = can > be sent by any intermediate Diameter node, not just the end points. = I > think we need to cover these errors a bit better than just saying = they > are no usable. (the additional data falls into *[AVP] wildcard in = the > error response and is understood by the receiver or then not..) I agree that work needs to be done on the error responses. I don't = think that would be sufficient to cover overload control though and I = have been thinking of this as a different problem. The lack of = information on the error responses that can be used for overload control = is only one of the issues with them. A separate effort to fix those = would be worthwhile. >=20 > 6.1. Overload in Mobile Data Networks >=20 > o I'd like to see quite a few references here.. 23.002, 29.272, = 29.002, > IR.92, .. Well, those will certainly send anyone not familiar with 3GPP stuff down = a rat hole... thanks for pointing that section out. I had forgotten that there was = still a note in there about needing citations. >=20 > o PCC and IMS seem to have been skipped here (except indirectly = covered by > VoLTE). I can add a bit more here. You are wanting to beef up the info showing = how much use of Diameter (and subsequently, the impact of overload) = there is in mobile networks?=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. 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 > o Req13: related to this, I would also have some text here or on some = other > requirement regarding the additional size overhead introduced by the > overload mechanism. That must also be taken into account. doesn't this get captured by the not introducing substantial additional = work bit? it seems to be a derivative. If the size overhead is large, = that would introduce additional work, right? >=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. >=20 > o Req21: I see the intention but how do you qualify some node meets = the > requirement? To me this requirement equals to implicit mechanisms = i.e. > the other end does not really respond so it probably i having = issues. > Typically the other ends start resending, which just worsens the > situation, right? An overload control mechanism will have to consider and handle this case = and the requirement is more for the mechanism than a node that = implements it. It would be possible to design a mechanism that did just = what you are suggesting and started resending, which would indeed cause = a worsening of the situation. I think this requirement is there to = ensure that a compliant mechanism has considered this and that it = specifies rational behavior when this happens. >=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? 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. >=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.. okay, I will add some text to that effect in the summary. >=20 > - JOuni >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From jouni.nospam@gmail.com Tue Nov 27 03:33:05 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 8F28321F849A for ; Tue, 27 Nov 2012 03:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154, 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 E67xJfTIObmR for ; Tue, 27 Nov 2012 03:33:04 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D84721F849B for ; Tue, 27 Nov 2012 03:33:04 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so5778990bku.31 for ; Tue, 27 Nov 2012 03:33:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=RKHeX1SgG1mNZ48hQ3cwA2yqVZT58d0lfJDcsoPXisA=; b=fgu+rYzSuOWO3EAKU4mDnNifzT1ZbH33eNtESQ0iybKrO/jDWpS3sFzPGxCv+Ic99Y gIj+TRsr4SqwY/KJr+lFp7Kx4z5A0CSxhF0zv/qbdQaPL0CjALImnrTsgCVvnyoL/1GB mC2mAkp1HkI3JvnjQkPmjmwtLwdFdftYVLay2Gdyi0M4tz7Stzf29vqVh+0E+GyMi6NZ l4FrQWiYuX5SEp3tp/AjASh4dgJdzxxXHDJXWzDGAyjQB1pIoiD8VKOyT78rYVn+8oQb CV4lna8CJsIxpRhnixymr4G+LsZWjh4QxfddQiW5757FMO9siL+VT2cyXjm2DR6rfARc Ocrw== Received: by 10.204.147.6 with SMTP id j6mr4348918bkv.61.1354015983269; Tue, 27 Nov 2012 03:33:03 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id q22sm10001022bkv.16.2012.11.27.03.32.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Nov 2012 03:33:02 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Tue, 27 Nov 2012 13:32:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E7FEE8E-F6E8-4470-8823-E97382C73661@gmail.com> To: Eric McMurry X-Mailer: Apple Mail (2.1085) Cc: ERIC C NOEL , 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, 27 Nov 2012 11:33:05 -0000 Eric, See responses inline. On Nov 27, 2012, at 3:17 AM, Eric McMurry wrote: > Thanks Jouni! Comments are greatly appreciated. >=20 > commentary inline. >=20 > On Nov 22, 2012, at 8:28 , jouni korhonen = wrote: >=20 >> Hi, >>=20 >> I have briefly reviewed draft-ietf-dime-overload-req-00 again. Sorry = for >> the extended delay! Some comments beflow: >>=20 >> Section 2.3. Interconnect Scenario >>=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? 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 >> Section 4. Existing Mechanisms >>=20 >> o I would also add DPR with = Disconnect-Cause=3DDO_NOT_WANT_TO_TALK_TO_YOU >> discussion here. IMHO it is also valid mechanism, though a bit = cruel. >=20 > agree, I'll add that to the discussion. I think BUSY may be a better = disconnect cause for this case though, right? The effects are the same = either way. Ok. >>=20 >> Section 5.2. Problems with Explicit Mechanisms >>=20 >> o See the DPR above. >>=20 >=20 > yep >=20 >> o Then a flow of mind/thinking.. since protocol level errors like >> DIAMETER_UNABLE_TO_DELIVER and DIAMETER_TOO_BUSY are delivered using >> a specific CCF, why cannot we just put overload whatever information >> there? That would be a better than nothing approach to tackle a = class >> of overload cases. Basically one could add AVPs that describe = specifically >> why DIAMETER_UNABLE_TO_DELIVER and DIAMETER_TOO_BUSY took place and=20= >> what need to be done to get over that situation. And these errors = can >> be sent by any intermediate Diameter node, not just the end points. = I >> think we need to cover these errors a bit better than just saying = they >> are no usable. (the additional data falls into *[AVP] wildcard in = the >> error response and is understood by the receiver or then not..) >=20 > I agree that work needs to be done on the error responses. I don't = think that would be sufficient to cover overload control though and I = have been thinking of this as a different problem. The lack of = information on the error responses that can be used for overload control = is only one of the issues with them. A separate effort to fix those = would be worthwhile. This would be good to point out. >=20 >>=20 >> 6.1. Overload in Mobile Data Networks >>=20 >> o I'd like to see quite a few references here.. 23.002, 29.272, = 29.002, >> IR.92, .. >=20 > Well, those will certainly send anyone not familiar with 3GPP stuff = down a rat hole... >=20 > thanks for pointing that section out. I had forgotten that there was = still a note in there about needing citations. >=20 >>=20 >> o PCC and IMS seem to have been skipped here (except indirectly = covered by >> VoLTE). >=20 > I can add a bit more here. You are wanting to beef up the info = showing how much use of Diameter (and subsequently, the impact of = overload) there is in mobile networks?=20 Something towards that direction. I could/would add more weight to our requirements doc. >> 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. 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 >> o Req13: related to this, I would also have some text here or on some = other >> requirement regarding the additional size overhead introduced by the >> overload mechanism. That must also be taken into account. >=20 > doesn't this get captured by the not introducing substantial = additional work bit? it seems to be a derivative. If the size overhead = is large, that would introduce additional work, right? Could be. I am fine whatever you do here.. or choose not to do. >> 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. Right. Maybe someone who contributed to SIP overload can shift their ideas & reasoning on this requirement into this document? >> o Req21: I see the intention but how do you qualify some node meets = the >> requirement? To me this requirement equals to implicit mechanisms = i.e. >> the other end does not really respond so it probably i having = issues. >> Typically the other ends start resending, which just worsens the >> situation, right? >=20 > An overload control mechanism will have to consider and handle this = case and the requirement is more for the mechanism than a node that = implements it. It would be possible to design a mechanism that did just = what you are suggesting and started resending, which would indeed cause = a worsening of the situation. I think this requirement is there to = ensure that a compliant mechanism has considered this and that it = specifies rational behavior when this happens. Ok. >> 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. 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. >> 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. \o/ - Jouni >=20 >>=20 >> - JOuni >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 >>=20 >>=20 From emcmurry@computer.org Tue Nov 27 09:23: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 870EB21F8555 for ; Tue, 27 Nov 2012 09:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=1.077, 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 aerRrfBA6n-f for ; Tue, 27 Nov 2012 09:23:02 -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 689A921F85CE for ; Tue, 27 Nov 2012 09:23:02 -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 1TdOs9-000Agz-A4; Tue, 27 Nov 2012 17:23:01 +0000 Received: from localhost (localhost [127.0.0.1]) by antikythera.casamcmurry.com (Postfix) with ESMTP id A82C6A4B691; Tue, 27 Nov 2012 11:22:59 -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/VUDTHF6FVlInShsVQU69jCsalVUanCQ0= 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 r2qiBBrMT0o0; Tue, 27 Nov 2012 11:22:59 -0600 (CST) Received: from [192.168.1.2] (mobile-166-137-149-130.mycingular.net [166.137.149.130]) by antikythera.casamcmurry.com (Postfix) with ESMTPSA id 0475BA4B686; Tue, 27 Nov 2012 11:22:58 -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: Date: Tue, 27 Nov 2012 11:22:57 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E7FEE8E-F6E8-4470-8823-E97382C73661@gmail.com> To: jouni korhonen X-Mailer: Apple Mail (2.1499) Cc: ERIC C NOEL , 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, 27 Nov 2012 17:23:03 -0000 Thanks Jouni. inline. On Nov 27, 2012, at 5:32 , jouni korhonen = wrote: [...] >>>=20 >>> Section 2.3. Interconnect Scenario >>>=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. Thanks! >=20 >>>=20 >>> Section 4. Existing Mechanisms >>>=20 >>> o I would also add DPR with = Disconnect-Cause=3DDO_NOT_WANT_TO_TALK_TO_YOU >>> discussion here. IMHO it is also valid mechanism, though a bit = cruel. >>=20 >> agree, I'll add that to the discussion. I think BUSY may be a better = disconnect cause for this case though, right? The effects are the same = either way. >=20 > Ok. >=20 >>>=20 >>> Section 5.2. Problems with Explicit Mechanisms >>>=20 >>> o See the DPR above. >>>=20 >>=20 >> yep >>=20 >>> o Then a flow of mind/thinking.. since protocol level errors like >>> DIAMETER_UNABLE_TO_DELIVER and DIAMETER_TOO_BUSY are delivered using >>> a specific CCF, why cannot we just put overload whatever information >>> there? That would be a better than nothing approach to tackle a = class >>> of overload cases. Basically one could add AVPs that describe = specifically >>> why DIAMETER_UNABLE_TO_DELIVER and DIAMETER_TOO_BUSY took place and=20= >>> what need to be done to get over that situation. And these errors = can >>> be sent by any intermediate Diameter node, not just the end points. = I >>> think we need to cover these errors a bit better than just saying = they >>> are no usable. (the additional data falls into *[AVP] wildcard in = the >>> error response and is understood by the receiver or then not..) >>=20 >> I agree that work needs to be done on the error responses. I don't = think that would be sufficient to cover overload control though and I = have been thinking of this as a different problem. The lack of = information on the error responses that can be used for overload control = is only one of the issues with them. A separate effort to fix those = would be worthwhile. >=20 > This would be good to point out. ack. will do. >=20 >>=20 >>>=20 >>> 6.1. Overload in Mobile Data Networks >>>=20 >>> o I'd like to see quite a few references here.. 23.002, 29.272, = 29.002, >>> IR.92, .. >>=20 >> Well, those will certainly send anyone not familiar with 3GPP stuff = down a rat hole... >>=20 >> thanks for pointing that section out. I had forgotten that there was = still a note in there about needing citations. >>=20 >>>=20 >>> o PCC and IMS seem to have been skipped here (except indirectly = covered by >>> VoLTE). >>=20 >> I can add a bit more here. You are wanting to beef up the info = showing how much use of Diameter (and subsequently, the impact of = overload) there is in mobile networks?=20 >=20 > Something towards that direction. I could/would add more weight to our > requirements doc. okay >=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. okay >=20 >>>=20 >>> o Req13: related to this, I would also have some text here or on = some other >>> requirement regarding the additional size overhead introduced by the >>> overload mechanism. That must also be taken into account. >>=20 >> doesn't this get captured by the not introducing substantial = additional work bit? it seems to be a derivative. If the size overhead = is large, that would introduce additional work, right? >=20 > Could be. I am fine whatever you do here.. or choose not to do. >=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 >=20 >>> o Req21: I see the intention but how do you qualify some node meets = the >>> requirement? To me this requirement equals to implicit mechanisms = i.e. >>> the other end does not really respond so it probably i having = issues. >>> Typically the other ends start resending, which just worsens the >>> situation, right? >>=20 >> An overload control mechanism will have to consider and handle this = case and the requirement is more for the mechanism than a node that = implements it. It would be possible to design a mechanism that did just = what you are suggesting and started resending, which would indeed cause = a worsening of the situation. I think this requirement is there to = ensure that a compliant mechanism has considered this and that it = specifies rational behavior when this happens. >=20 > Ok. >=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. okay >=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 > \o/ >=20 > - Jouni >=20 >=20 >>=20 >>>=20 >>> - JOuni >>>=20 >>>=20 >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>=20 >>>=20 >>>=20 >=20