From nobody Thu Oct 1 00:36:55 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3811A1BC2; Thu, 1 Oct 2015 00:36:52 -0700 (PDT) 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=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcbRW3-duIg2; Thu, 1 Oct 2015 00:36:49 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98F71A00AC; Thu, 1 Oct 2015 00:36:48 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id F24DF18C1AC; Thu, 1 Oct 2015 09:36:46 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.69]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id C500D35C06A; Thu, 1 Oct 2015 09:36:46 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%19]) with mapi id 14.03.0248.002; Thu, 1 Oct 2015 09:36:46 +0200 From: To: Janet P Gunn , "DOLLY, MARTIN C" Thread-Topic: [Dime] [dime] #92 (drmp): Range of priority levels Thread-Index: AQHQ+7/7gjQt6THBK0qRj4pp4rg/GJ5VZy8AgAADsACAAM9WwA== Date: Thu, 1 Oct 2015 07:36:46 +0000 Message-ID: <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E01D3889EOPEXCLILM43corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.10.1.70320 Archived-At: Cc: DiME , "dime@ietf.org" Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 07:36:52 -0000 --_000_6B7134B31289DC4FAF731D844122B36E01D3889EOPEXCLILM43corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgdGhpbmsgdGhhdCB0aGUgY2FzZSAibm8gUHJpb3JpdHkgaW5kaWNhdGlvbiBpbiBy ZXF1ZXN0IiBpcyB0aGUgZGVmYXVsdCBzaXR1YXRpb24gdG9kYXkuDQpTbyBpZiB3ZSBhZ3JlZSB0 aGF0IGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBleHBsaWNpdGx5IGluZGljYXRlIGEgcmVxdWVz dCB3aXRoIGEgbG93ZXIgcHJpb3JpdHksIHdlIHNob3VsZCBkaXZpZGUgdGhlIHJhbmdlIG9mIHBy aW9yaXR5IHZhbHVlcyBpbiB0aHJlZSBzdWItcmFuZ2VzOiBbbG93ZXIgcHJpb3JpdGllc11bbm8g cHJpb3JpdHkgaW5kaWNhdGlvbl1baGlnaGVyIHByaW9yaXRpZXNdLCBlLmcuIHdpdGggMTcgdmFs dWVzOiBbMC03XVs4XVs5LTE2XS4NCklmIGFueSBvcGVyYXRvciBjYW4gZnJlZWx5IGZpeCB0aGUg ZGVmYXVsdCB2YWx1ZSwgdGhlcmUgd291bGQgYmUgbm8gd2F5IHRvIGVuc3VyZSB0aGUgc2VuZGVy IHRoYXQgYSByZXF1ZXN0IHdpdGggYSBzcGVjaWZpYyBwcmlvcml0eSB2YWx1ZSAoZS5nLiA2KSB3 aWxsIGJlIGhhbmRsZWQgd2l0aCBhIGxvd2VyIG9yIGhpZ2hlciBwcmlvcml0eSB0aGFuIGEgcmVx dWVzdCB3aXRoIG5vIHByaW9yaXR5IGluZGljYXRpb24uDQoNClRoZXJlZm9yZSwgZm9yIGEgZGV0 ZXJtaW5pc3RpYyBoYW5kbGluZyBtZWNoYW5pc20sIEkgdGhpbmsgdGhhdCBpdCBpcyB0aGVuIG1v cmUgcmVsZXZhbnQgdG8gZGVmaW5lIGEgc3RhbmRhcmQgdmFsdWUgZm9yIHRoZSBkZWZhdWx0IHZh bHVlLg0KDQpSZWdhcmRzLA0KDQpMaW9uZWwNCg0KDQpEZSA6IERpTUUgW21haWx0bzpkaW1lLWJv dW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSmFuZXQgUCBHdW5uDQpFbnZvecOpIDogbWVy Y3JlZGkgMzAgc2VwdGVtYnJlIDIwMTUgMjI6NTMNCsOAIDogRE9MTFksIE1BUlRJTiBDDQpDYyA6 IERpTUU7IGRpbWVAaWV0Zi5vcmcNCk9iamV0IDogUmU6IFtEaW1lXSBbZGltZV0gIzkyIChkcm1w KTogUmFuZ2Ugb2YgcHJpb3JpdHkgbGV2ZWxzDQoNClNhbWUgaGVyZS4gIFRoZSAiZGVmYXVsdCBw cmlvcml0eSIgc2hvdWxkIGJlIGEgbWF0dGVyIG9mIGxvY2FsIHBvbGljeS4NCg0KSmFuZXQNCg0K VGhpcyBpcyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5kIGtpbmRseSBhZHZpc2Ug dXMgYnkgZS1tYWlsIG9mIHRoZSBtaXN0YWtlIGluIGRlbGl2ZXJ5LiBOT1RFOiBSZWdhcmRsZXNz IG9mIGNvbnRlbnQsIHRoaXMgZS1tYWlsIHNoYWxsIG5vdCBvcGVyYXRlIHRvIGJpbmQgQ1NDIHRv IGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGljaXQg d3JpdHRlbiBhZ3JlZW1lbnQgb3IgZ292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJlc3NseSBwZXJt aXR0aW5nIHRoZSB1c2Ugb2YgZS1tYWlsIGZvciBzdWNoIHB1cnBvc2UuDQoNCg0KDQpGcm9tOiAg ICAgICAgIkRPTExZLCBNQVJUSU4gQyIgPG1kMzEzNUBhdHQuY29tPG1haWx0bzptZDMxMzVAYXR0 LmNvbT4+DQpUbzogICAgICAgIFN0ZXZlIERvbm92YW4gPHNyZG9ub3ZhbkB1c2Rvbm92YW5zLmNv bTxtYWlsdG86c3Jkb25vdmFuQHVzZG9ub3ZhbnMuY29tPj4sICJkaW1lQGlldGYub3JnPG1haWx0 bzpkaW1lQGlldGYub3JnPiIgPGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+Pg0K RGF0ZTogICAgICAgIDA5LzMwLzIwMTUgMDQ6NDAgUE0NClN1YmplY3Q6ICAgICAgICBSZTogW0Rp bWVdIFtkaW1lXSAjOTIgKGRybXApOiBSYW5nZSBvZiBwcmlvcml0eSBsZXZlbHMNClNlbnQgYnk6 ICAgICAgICAiRGlNRSIgPGRpbWUtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZGltZS1ib3VuY2Vz QGlldGYub3JnPj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpNZSBh cyB3ZWxsDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBTdGV2ZSBEb25vdmFuDQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAzMCwgMjAx NSA0OjM4IFBNDQpUbzogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbRGltZV0gW2RpbWVdICM5MiAoZHJtcCk6IFJhbmdlIG9mIHByaW9yaXR5IGxldmVs cw0KDQpJJ20gb2theSB3aXRoIEpheSdzIHByb3Bvc2FsIG9uIG5vdCBzcGVjaWZ5aW5nIGEgZGVm YXVsdCB2YWx1ZS4NCg0KU3RldmUNCk9uIDkvMzAvMTUgMzoyNyBQTSwgTGVlLCBKYXkgd3JvdGU6 DQpIaSBTdGV2ZSBhbmQgYWxsLA0KDQpGb3IgdGhlIGZpcnN0IHByb3Bvc2FsLCBhcyBJIGluZGlj YXRlZCwgSSBzdXBwb3J0IGluY3JlYXNpbmcgdGhlIG51bWJlciBvZiBwcmlvcml0eSBsZXZlbHMg dXAgdG8gMTYuDQoNCkkgYW0gYWxzbyBmaW5lIHdpdGggdGhlIHNlY29uZCBwcm9wb3NhbC4gTXkg cXVlc3Rpb24gaXM6IGRvIHdlIG5lZWQgdG8gbWFuZGF0ZSB0aGlzIGZlYXR1cmUsIGFzIGluZGl2 aWR1YWwgb3BlcmF0b3JzIGhhdmUgZGlmZmVyZW50IHNpdHVhdGlvbnM/IFBlcmhhcHMgc29tZSBm bGV4aWJpbGl0eSBzaG91bGQgYmUgYWxsb3dlZD8gSW5zdGVhZCBvZiBtYW5kYXRpbmcgaXQsIHdl IGNhbiBpbmNsdWRlIHRoZSBzdGF0ZW1lbnQgdGhhdCB3aGVuIHRoZXJlIGlzIG5vIERSTVAgQVZQ LCB0aGlzIGNvcnJlc3BvbmQgdG8g4oCYbm9ybWFsIHRyYWZmaWPigJkgd2l0aG91dCBhIHBhcnRp Y3VsYXIgaGlnaCBvciBsb3cgcHJpb3JpdHkuIFRoZW4gZWFjaCBvcGVyYXRvciBjYW4gbWFwIHRo aXMgZGVmYXVsdCB0byBhIHZhbHVlIChlLmcuLCA4IG9yIHNvbWV0aGluZyBlbHNlKSB0aGF0IHRo ZXkgZmVlbCBhcHByb3ByaWF0ZS4NCg0KVGhhbmtzLA0KDQpKYXkNCg0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0K RGlNRUBpZXRmLm9yZzxtYWlsdG86RGlNRUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGltZQ0KIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZzxtYWlsdG86 RGlNRUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlt ZQ0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29u dGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0 IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVy LCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z aSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFu dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4g TWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25m aWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQg YnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdp dGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5v dCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y IGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_6B7134B31289DC4FAF731D844122B36E01D3889EOPEXCLILM43corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnR0DQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44 NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhp LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoYXQgdGhlIGNh c2UgJnF1b3Q7bm8gUHJpb3JpdHkgaW5kaWNhdGlvbiBpbiByZXF1ZXN0JnF1b3Q7IGlzIHRoZSBk ZWZhdWx0IHNpdHVhdGlvbiB0b2RheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlNvIGlmIHdlIGFncmVlIHRoYXQgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGV4 cGxpY2l0bHkgaW5kaWNhdGUgYSByZXF1ZXN0IHdpdGggYSBsb3dlciBwcmlvcml0eSwgd2Ugc2hv dWxkIGRpdmlkZSB0aGUgcmFuZ2Ugb2YgcHJpb3JpdHkgdmFsdWVzDQogaW4gdGhyZWUgc3ViLXJh bmdlczogW2xvd2VyIHByaW9yaXRpZXNdW25vIHByaW9yaXR5IGluZGljYXRpb25dW2hpZ2hlciBw cmlvcml0aWVzXSwgZS5nLiB3aXRoIDE3IHZhbHVlczogWzAtN11bOF1bOS0xNl0uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiBhbnkgb3BlcmF0b3IgY2FuIGZy ZWVseSBmaXggdGhlIGRlZmF1bHQgdmFsdWUsIHRoZXJlIHdvdWxkIGJlIG5vIHdheSB0byBlbnN1 cmUgdGhlIHNlbmRlciB0aGF0IGEgcmVxdWVzdCB3aXRoIGEgc3BlY2lmaWMgcHJpb3JpdHkgdmFs dWUgKGUuZy4NCiA2KSB3aWxsIGJlIGhhbmRsZWQgd2l0aCBhIGxvd2VyIG9yIGhpZ2hlciBwcmlv cml0eSB0aGFuIGEgcmVxdWVzdCB3aXRoIG5vIHByaW9yaXR5IGluZGljYXRpb24uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJlZm9yZSwgZm9yIGEgZGV0ZXJtaW5pc3Rp YyBoYW5kbGluZyBtZWNoYW5pc20sIEkgdGhpbmsgdGhhdCBpdCBpcyB0aGVuIG1vcmUgcmVsZXZh bnQgdG8gZGVmaW5lIGEgc3RhbmRhcmQgdmFsdWUgZm9yIHRoZSBkZWZhdWx0IHZhbHVlLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkxpb25lbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBKYW5ldCBQIEd1bm48YnI+DQo8Yj5FbnZvecOpJm5i c3A7OjwvYj4gbWVyY3JlZGkgMzAgc2VwdGVtYnJlIDIwMTUgMjI6NTM8YnI+DQo8Yj7DgCZuYnNw Ozo8L2I+IERPTExZLCBNQVJUSU4gQzxicj4NCjxiPkNjJm5ic3A7OjwvYj4gRGlNRTsgZGltZUBp ZXRmLm9yZzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtEaW1lXSBbZGltZV0gIzkyIChk cm1wKTogUmFuZ2Ugb2YgcHJpb3JpdHkgbGV2ZWxzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TYW1lIGhlcmUuICZuYnNwO1RoZSAmcXVv dDtkZWZhdWx0IHByaW9yaXR5JnF1b3Q7IHNob3VsZCBiZSBhIG1hdHRlciBvZiBsb2NhbCBwb2xp Y3kuPC9zcGFuPg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SmFuZXQ8 YnI+DQo8YnI+DQpUaGlzIGlzIGEgUFJJVkFURSBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHdpdGhvdXQgY29weWluZyBhbmQga2lu ZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YgdGhlIG1pc3Rha2UgaW4gZGVsaXZlcnkuIE5PVEU6 IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8g YmluZCBDU0MgdG8gYW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0DQogdW5sZXNzIHB1cnN1YW50 IHRvIGV4cGxpY2l0IHdyaXR0ZW4gYWdyZWVtZW50IG9yIGdvdmVybm1lbnQgaW5pdGlhdGl2ZSBl eHByZXNzbHkgcGVybWl0dGluZyB0aGUgdXNlIG9mIGUtbWFpbCBmb3Igc3VjaCBwdXJwb3NlLjwv c3Bhbj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojNUY1RjVGIj5Gcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mcXVvdDtET0xMWSwgTUFSVElOIEMmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzptZDMxMzVAYXR0LmNvbSI+bWQzMTM1QGF0dC5jb208L2E+Jmd0Ozwvc3Bh bj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNUY1RjVGIj5UbzogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ U3RldmUgRG9ub3ZhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNyZG9ub3ZhbkB1c2Rvbm92YW5zLmNv bSI+c3Jkb25vdmFuQHVzZG9ub3ZhbnMuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0 bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJt YWlsdG86ZGltZUBpZXRmLm9yZyI+ZGltZUBpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPiA8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+RGF0ZTogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MDkvMzAvMjAx NSAwNDo0MCBQTTwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj NUY1RjVGIj5TdWJqZWN0OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZTogW0RpbWVdIFtkaW1lXSAjOTIgKGRybXApOiBSYW5nZSBv ZiBwcmlvcml0eSBsZXZlbHM8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzVGNUY1RiI+U2VudCBieTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+JnF1b3Q7RGlNRSZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+ZGltZS1ib3VuY2VzQGlldGYub3JnPC9hPiZn dDs8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0i MTAwJSIgbm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6I0EwQTBBMCIgYWxpZ249ImNlbnRlciI+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDQw ODAiPk1lIGFzIHdlbGw8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzAwNDA4MCI+Jm5ic3A7PC9zcGFuPg0KPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g RGlNRSBbPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvc3Bh bj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PlN0ZXZlIERvbm92YW48Yj48YnI+DQpTZW50OjwvYj4gV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMzAs IDIwMTUgNDozOCBQTTxiPjxicj4NClRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5v cmciPmRpbWVAaWV0Zi5vcmc8L2E+PGI+PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBbRGltZV0gW2Rp bWVdICM5MiAoZHJtcCk6IFJhbmdlIG9mIHByaW9yaXR5IGxldmVsczwvc3Bhbj4gPGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+SSdtIG9rYXkgd2l0aCBKYXkncyBwcm9wb3NhbCBvbiBub3Qgc3Bl Y2lmeWluZyBhIGRlZmF1bHQgdmFsdWUuPGJyPg0KPGJyPg0KU3RldmU8L3NwYW4+IDxicj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T24gOS8zMC8xNSAzOjI3IFBNLCBMZWUsIEpheSB3 cm90ZTo8L3NwYW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpIFN0ZXZl IGFuZCBhbGwsPC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz cDs8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIHRoZSBmaXJz dCBwcm9wb3NhbCwgYXMgSSBpbmRpY2F0ZWQsIEkgc3VwcG9ydCBpbmNyZWFzaW5nIHRoZSBudW1i ZXIgb2YgcHJpb3JpdHkgbGV2ZWxzIHVwIHRvIDE2Ljwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkkgYW0gYWxzbyBmaW5lIHdpdGggdGhlIHNlY29uZCBwcm9wb3NhbC4gTXkgcXVl c3Rpb24gaXM6IGRvIHdlIG5lZWQgdG8gbWFuZGF0ZSB0aGlzIGZlYXR1cmUsIGFzIGluZGl2aWR1 YWwgb3BlcmF0b3JzIGhhdmUgZGlmZmVyZW50IHNpdHVhdGlvbnM/IFBlcmhhcHMgc29tZSBmbGV4 aWJpbGl0eSBzaG91bGQgYmUgYWxsb3dlZD8gSW5zdGVhZA0KIG9mIG1hbmRhdGluZyBpdCwgd2Ug Y2FuIGluY2x1ZGUgdGhlIHN0YXRlbWVudCB0aGF0IHdoZW4gdGhlcmUgaXMgbm8gRFJNUCBBVlAs IHRoaXMgY29ycmVzcG9uZCB0byDigJhub3JtYWwgdHJhZmZpY+KAmSB3aXRob3V0IGEgcGFydGlj dWxhciBoaWdoIG9yIGxvdyBwcmlvcml0eS4gVGhlbiBlYWNoIG9wZXJhdG9yIGNhbiBtYXAgdGhp cyBkZWZhdWx0IHRvIGEgdmFsdWUgKGUuZy4sIDggb3Igc29tZXRoaW5nIGVsc2UpIHRoYXQgdGhl eSBmZWVsIGFwcHJvcHJpYXRlLjwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jm5ic3A7PC9zcGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRo YW5rcyw8L3NwYW4+IDxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9z cGFuPiA8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkpheTwvc3Bhbj4gPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkRpTUUgbWFpbGluZyBs aXN0PC9zcGFuPg0KPGJyPg0KPGEgaHJlZj0ibWFpbHRvOkRpTUVAaWV0Zi5vcmciPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5EaU1FQGlldGYub3JnPC9zcGFuPjwvYT4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZGltZTwvc3Bhbj48L2E+DQo8YnI+DQombmJzcDs8dHQ+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD5EaU1FIG1h aWxpbmcgbGlzdDwvdHQ+PGJyPg0KPHR0PjxhIGhyZWY9Im1haWx0bzpEaU1FQGlldGYub3JnIj5E aU1FQGlldGYub3JnPC9hPjwvdHQ+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZSI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L3NwYW4+ PC90dD48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxQUkU+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBl dHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2 b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVy CmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50 ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy YXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2Ug YSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5v dCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3Uu CjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6B7134B31289DC4FAF731D844122B36E01D3889EOPEXCLILM43corp_-- From nobody Fri Oct 2 08:57:24 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322BC1B2C5E for ; Fri, 2 Oct 2015 08:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yr8AmWE9gS_T for ; Fri, 2 Oct 2015 08:57:21 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BAF1B2C5B for ; Fri, 2 Oct 2015 08:57:21 -0700 (PDT) Received: by qgev79 with SMTP id v79so98016863qge.0 for ; Fri, 02 Oct 2015 08:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zLqdNHiveLMO2sZCCFStsC3OqlvNmbkF/6Jh0V4PZUY=; b=Wb00ZYycuNzvvdz8mOaBWyqL62jniys3Ac0Cg29jgOeZSSjbIREdgiKN9yf87mk0sD 01DR5JzACFselOXRIdVHk0p8NGi1u4AD0Huswvas9FY5j8aozeK+NZzRSUNud5J09P4K Zi6MJcR3lcXVqdn5YRUT51V/WWXoez1F+7ecFqkInVrKOFYs63t3SAwjjH2DaqnMxGSj Zm1QQXEXFww10F0g+7QfHG69zdhrIlhYmOsSqSYoWEqY0Q9sYYKmbzZq28Jqa3Wo4Tch 0wTBu3Ak+kfEhK8kl8jHloFa6O3LUltVWBWaIab2nulKgGwOKWImsBxUV9w5wa0/xI/n 3vyw== MIME-Version: 1.0 X-Received: by 10.140.93.139 with SMTP id d11mr20853061qge.83.1443801440388; Fri, 02 Oct 2015 08:57:20 -0700 (PDT) Received: by 10.55.68.79 with HTTP; Fri, 2 Oct 2015 08:57:20 -0700 (PDT) Date: Fri, 2 Oct 2015 17:57:20 +0200 Message-ID: From: =?UTF-8?Q?Henrik_Villf=C3=B6r?= To: dime@ietf.org Content-Type: multipart/alternative; boundary=001a113958c8fb2b7c0521213758 Archived-At: Subject: [Dime] Use of multiple result-code AVPs in RFC 4006 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2015 15:57:22 -0000 --001a113958c8fb2b7c0521213758 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, RFC 4006 allows multiple result-code AVPs. "...Result-Code AVP MAY be present both on the command level and within the Multiple-Services-Credit-Control AVP." But a CCA may also contain several Multiple-Services-Credit-Control AVPs. Is the use of result codes in more than on MSCC AVP regulated in any way? What happens to the state of the session if contradictory result codes are sent in different MSCC AVPs? I can guess, but I'd like to know. Grateful for pointers. Henrik Villf=C3=B6r --001a113958c8fb2b7c0521213758 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
RFC 4006 allows multiple result-code AVPs.=C2=A0
"...Result-= Code AVP MAY be present both on the=C2=A0command level and within the Multiple-Services-Credit-Control AVP."

But a CCA may also contain several Multiple-Services-Credit= -Control AVPs.=C2=A0

Is the use of result codes in= more than on MSCC AVP regulated in any way? What happens to the state of t= he session if contradictory result codes are sent in different MSCC AVPs?

I can guess, but I'd like to know.=C2=A0
<= div>
Grateful for pointers.

Henrik V= illf=C3=B6r
--001a113958c8fb2b7c0521213758-- From nobody Fri Oct 2 16:21:13 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EA61B324A; Fri, 2 Oct 2015 16:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oZ4-YF89xiR; Fri, 2 Oct 2015 16:21:09 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B2E1B322F; Fri, 2 Oct 2015 16:21:08 -0700 (PDT) Received: from bambi.appcomsci.com (bambi.appcomsci.com [192.4.5.54]) by thumper.appcomsci.com (8.14.4/8.14.4) with ESMTP id t92NGWLm013291; Fri, 2 Oct 2015 19:16:32 -0400 Received: from brg-ats-exhb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.112]) by bambi.appcomsci.com (8.14.4/8.13.4) with ESMTP id t92NL3WE011293; Fri, 2 Oct 2015 19:21:03 -0400 Received: from RRC-ATS-EXMB2.ats.atsinnovate.com ([2002:c004:56a::c004:56a]) by brg-ats-exhb1.ats.atsinnovate.com ([2002:c004:570::c004:570]) with mapi; Fri, 2 Oct 2015 19:20:58 -0400 From: "Shaikh, Viqar A" To: "lionel.morand@orange.com" , Janet P Gunn , "DOLLY, MARTIN C" Thread-Topic: [Dime] [dime] #92 (drmp): Range of priority levels Thread-Index: AQHQ+8AL5If6gk8Kl0mwHkRghBwCAJ5Vy8QAgAADsACAALPzAIACVknP Date: Fri, 2 Oct 2015 23:20:33 +0000 Message-ID: <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> , <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_341B32B15901F94185C9E67CAAE133030E252A9Brrcatsexmb2atsa_" MIME-Version: 1.0 Archived-At: Cc: DiME , "dime@ietf.org" , "Pollini, Gregory P" Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 02 Oct 2015 23:21:12 -0000 --_000_341B32B15901F94185C9E67CAAE133030E252A9Brrcatsexmb2atsa_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello all, Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.21= 2 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defi= ned. Having 15 rather than 16 would be useful from an interworking point of view= on Diameter interfaces connecting to the EPS. Also, my understanding has been that the default value is per local policy. My 2 cents.... Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf of lionel.morand@orange.com [l= ionel.morand@orange.com] Sent: Thursday, October 01, 2015 3:36 AM To: Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Hi, I think that the case "no Priority indication in request" is the default si= tuation today. So if we agree that it should be possible to explicitly indicate a request = with a lower priority, we should divide the range of priority values in thr= ee sub-ranges: [lower priorities][no priority indication][higher priorities= ], e.g. with 17 values: [0-7][8][9-16]. If any operator can freely fix the default value, there would be no way to = ensure the sender that a request with a specific priority value (e.g. 6) wi= ll be handled with a lower or higher priority than a request with no priori= ty indication. Therefore, for a deterministic handling mechanism, I think that it is then = more relevant to define a standard value for the default value. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn Envoy=E9 : mercredi 30 septembre 2015 22:53 =C0 : DOLLY, MARTIN C Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels Same here. The "default priority" should be a matter of local policy. Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "DOLLY, MARTIN C" > To: Steve Donovan >, "dime@ietf.org" > Date: 09/30/2015 04:40 PM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" = > ________________________________ Me as well From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, September 30, 2015 4:38 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels I'm okay with Jay's proposal on not specifying a default value. Steve On 9/30/15 3:27 PM, Lee, Jay wrote: Hi Steve and all, For the first proposal, as I indicated, I support increasing the number of = priority levels up to 16. I am also fine with the second proposal. My question is: do we need to mand= ate this feature, as individual operators have different situations? Perhap= s some flexibility should be allowed? Instead of mandating it, we can inclu= de the statement that when there is no DRMP AVP, this correspond to =91norm= al traffic=92 without a particular high or low priority. Then each operator= can map this default to a value (e.g., 8 or something else) that they feel= appropriate. Thanks, Jay _______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_341B32B15901F94185C9E67CAAE133030E252A9Brrcatsexmb2atsa_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello all,

 

Note that the 3GPP priority, e.g., Priority-Level AVP (ARP = AVP) in TS 29.212 takes 15 values, value 1 the highest, 15 the lowest,= and value 0 not defined.

Having 15 rather than 16 would be useful from an interworking po= int of view on Diameter interfaces connecting to the EPS.  

Also, my understanding has been that the default value is per loc= al policy. 

My 2 cents....
Viqar 
From: DiME [dime-bounces@ietf.org] on beha= lf of lionel.morand@orange.com [lionel.morand@orange.com]
Sent: Thursday, October 01, 2015 3:36 AM
To: Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels

Hi,

=  

I think= that the case "no Priority indication in request" is the default= situation today.

So if w= e agree that it should be possible to explicitly indicate a request with a = lower priority, we should divide the range of priority values in three sub-ranges: [lower priorities][no priority indication][higher pri= orities], e.g. with 17 values: [0-7][8][9-16].

If any = operator can freely fix the default value, there would be no way to ensure = the sender that a request with a specific priority value (e.g. 6) will be handled with a lower or higher priority than a request with no = priority indication.

=  

Therefo= re, for a deterministic handling mechanism, I think that it is then more re= levant to define a standard value for the default value.

=  

Regards= ,

=  

Lionel<= /span>

=  

=  

De : Di= ME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn
Envoy=E9 : mercredi 30 septembre 2015 22:53
=C0 : DOLLY, MARTIN C
Cc : DiME; dime@ietf.org
Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels<= /span>

 

Same here.  The "default prior= ity" should be a matter of local policy.

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose.



From:        "DOLLY, MARTIN C" <md3135@att.com>
To:        Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org= " <dime@ietf.org= >
Date:        09/30/2015 04:40 PM
Subject:        Re: [Dime] [dime] #92 (drmp): Range of priority levels
Sent by:        "DiME" <dime-bounces@ietf.org>




Me as well
 
From: DiME [mailto:dime-boun= ces@ietf.org] On Behalf Of Steve Donovan
Sent: Wednesday, September 30, 2015 4:38 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels =
 
I'm okay with Jay's proposal on not specifying a default valu= e.

Steve
On 9/30/15 3:27 PM, Lee, Jay wrote:
Hi Steve and all,
 
For the first proposal, as I indicated, I support increasing = the number of priority levels up to 16.
 
I am also fine with the second proposal. My question is: do w= e need to mandate this feature, as individual operators have different situ= ations? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that when there is no DRMP A= VP, this correspond to =91normal traffic=92 without a particular high or lo= w priority. Then each operator can map this default to a value (e.g., 8 or = something else) that they feel appropriate.
 
Thanks,
 
Jay



_____= __________________________________________
DiME = mailing list
DiME@ietf.org
https:/= /www.ietf.org/mailman/listinfo/dime
 _________________________________= ______________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listi= nfo/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,
Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_341B32B15901F94185C9E67CAAE133030E252A9Brrcatsexmb2atsa_-- From nobody Tue Oct 6 08:11:30 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442F91B40D6 for ; Tue, 6 Oct 2015 08:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h810uPH2uHiN for ; Tue, 6 Oct 2015 08:11:22 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C2D51B40CB for ; Tue, 6 Oct 2015 08:11:22 -0700 (PDT) Received: by pacex6 with SMTP id ex6so213313220pac.0 for ; Tue, 06 Oct 2015 08:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=w3a3o+eB11YpPWB2kmFKMuv+nG7yQFv7nzaNlTAjVYU=; b=wQnslxLRQrJVOrqUhOXwfrEf1JsjWl8TncNhrZVvWbKDY/IsUS41Dz8pMtIfRQd7o9 FGK8LHPQKE5UKnxE24dINTg6NQtV+AnRFfvoufBrj7vhJq6+UbTE9Q7/tEOnff2hbIAf GdNLYuexfV+eBwC5NQ5la3E2IpqE0mO47koKoFofbkBi8IOkSEJequ8EvcyphTSj39jf Ynu6qoKysuqnf/yKz/S37xaZ4hf0fyYbs0+xoVPQ6XHR9ITXTM2LEmSRjGmGHQLN6203 +W6ZPqXZLOQEu5AI4PQxomrR1t63yFYT1KhwKx+Z3Khhl7ZWj3hShb7mN46h/UAYgvaQ 6PBw== X-Received: by 10.68.107.133 with SMTP id hc5mr47203999pbb.5.1444144281689; Tue, 06 Oct 2015 08:11:21 -0700 (PDT) Received: from [10.16.11.20] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id gt1sm34087604pbc.10.2015.10.06.08.11.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Oct 2015 08:11:18 -0700 (PDT) To: RFC Errata System , bclaise@cisco.com, joelja@bogus.com, lionel.morand@orange.com, keshab@smsgt.com, dime@ietf.org References: <20150914075821.1B9CA180204@rfc-editor.org> From: Jouni Korhonen Message-ID: <5613E495.9040606@gmail.com> Date: Tue, 6 Oct 2015 08:11:17 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20150914075821.1B9CA180204@rfc-editor.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (4473) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 15:11:28 -0000 (trimming the TO: and CC: lists) Quick comment on the proposed resolution. I think it is wrong since the text in 6.1.4 concerning Destination-Host is in the context of the request message i.e. there is no Destination-Host AVP present in the request. The proposed resolution now makes it into a context of the peer table content, which is not what the original text intended to say IMHO. Also there in no Destination-Host _AVP_ per se in the peer table as the proposed resolution now suggests. - Jouni 9/14/2015, 12:58 AM, RFC Errata System kirjoitti: > The following errata report has been submitted for RFC6733, > "Diameter Base Protocol". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4473 > > -------------------------------------- > Type: Technical > Reported by: Keshab Upadhya > > Section: 6.1.4 > > Original Text > ------------- > 6.1.4. Processing Local Requests > > The Destination-Host AVP is not present, the Destination-Realm AVP > contains a realm the server is configured to process locally, and > the Diameter application is locally supported; or > > > Corrected Text > -------------- > 6.1.4. Processing Local Requests > > The Destination-Host AVP is not present in peer routing table, > the Destination-Realm AVP contains a realm the server is > configured to process locally, and > the Diameter application is locally supported; or > > > Notes > ----- > 6.1.4 - Processing Local Requests > > The Destination-Host AVP is not present, the Destination-Realm AVP > contains a realm the server is configured to process locally, and > the Diameter application is locally supported > > 6.1.6 - Request Routing > > When a request is received that includes a realm > and/or application that is not locally supported, the message is > routed to the peer configured > > As given above 6.1.4 second rule contradicts with 6.1.6 para 2. > > Instructions: > ------------- > This erratum 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. > > -------------------------------------- > RFC6733 (draft-ietf-dime-rfc3588bis-33) > -------------------------------------- > Title : Diameter Base Protocol > Publication Date : October 2012 > Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. > Category : PROPOSED STANDARD > Source : Diameter Maintenance and Extensions > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > From nobody Tue Oct 6 08:26:56 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621151B40F9 for ; Tue, 6 Oct 2015 08:26:52 -0700 (PDT) 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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IQeT-q_4Whg for ; Tue, 6 Oct 2015 08:26:49 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D3611B40F5 for ; Tue, 6 Oct 2015 08:26:49 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 83551190714; Tue, 6 Oct 2015 17:26:47 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.41]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 42FA51580AB; Tue, 6 Oct 2015 17:26:47 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0248.002; Tue, 6 Oct 2015 17:26:46 +0200 From: To: Jouni Korhonen , RFC Errata System , "bclaise@cisco.com" , "joelja@bogus.com" , "keshab@smsgt.com" , "dime@ietf.org" Thread-Topic: [Technical Errata Reported] RFC6733 (4473) Thread-Index: AQHRAEk/73/1wkDa+keIFYRIJLURYJ5ekvzA Date: Tue, 6 Oct 2015 15:26:45 +0000 Message-ID: <6479_1444145207_5613E837_6479_710_1_6B7134B31289DC4FAF731D844122B36E01D3C7D1@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20150914075821.1B9CA180204@rfc-editor.org> <5613E495.9040606@gmail.com> In-Reply-To: <5613E495.9040606@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.10.6.90315 Archived-At: Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (4473) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 15:26:52 -0000 I agree with Jouni's answer. The proposed modification is not correct. Moreover, it is difficult for me to understand the issue that needs to be a= ddressed . It would be easier to detail/discuss the issue on the mailing list and afte= r see if there is something to correct in the RFC6733.=20 Regards, Lionel -----Message d'origine----- De=A0: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Envoy=E9=A0: mardi 6 octobre 2015 17:11 =C0=A0: RFC Errata System; bclaise@cisco.com; joelja@bogus.com; MORAND Lion= el IMT/OLN; keshab@smsgt.com; dime@ietf.org Objet=A0: Re: [Technical Errata Reported] RFC6733 (4473) (trimming the TO: and CC: lists) Quick comment on the proposed resolution. I think it is wrong since the tex= t in 6.1.4 concerning Destination-Host is in the context of the request mes= sage i.e. there is no Destination-Host AVP present in the request. The prop= osed resolution now makes it into a context of the peer table content, whic= h is not what the original text intended to say IMHO.=20 Also there in no Destination-Host _AVP_ per se in the peer table as the pro= posed resolution now suggests. - Jouni 9/14/2015, 12:58 AM, RFC Errata System kirjoitti: > The following errata report has been submitted for RFC6733, "Diameter=20 > Base Protocol". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6733&eid=3D4473 > > -------------------------------------- > Type: Technical > Reported by: Keshab Upadhya > > Section: 6.1.4 > > Original Text > ------------- > 6.1.4. Processing Local Requests > > The Destination-Host AVP is not present, the Destination-Realm AVP=20 > contains a realm the server is configured to process locally, and the=20 > Diameter application is locally supported; or > > > Corrected Text > -------------- > 6.1.4. Processing Local Requests > > The Destination-Host AVP is not present in peer routing table, the=20 > Destination-Realm AVP contains a realm the server is configured to=20 > process locally, and the Diameter application is locally supported; or > > > Notes > ----- > 6.1.4 - Processing Local Requests > > The Destination-Host AVP is not present, the Destination-Realm AVP > contains a realm the server is configured to process locally, and > the Diameter application is locally supported > > 6.1.6 - Request Routing > > When a request is received that includes a realm > and/or application that is not locally supported, the message is > routed to the peer configured > > As given above 6.1.4 second rule contradicts with 6.1.6 para 2. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please=20 > use "Reply All" to discuss whether it should be verified or rejected.=20 > When a decision is reached, the verifying party (IESG) can log in to=20 > change the status and edit the report, if necessary. > > -------------------------------------- > RFC6733 (draft-ietf-dime-rfc3588bis-33) > -------------------------------------- > Title : Diameter Base Protocol > Publication Date : October 2012 > Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. > Category : PROPOSED STANDARD > Source : Diameter Maintenance and Extensions > Area : Operations and Management > Stream : IETF > Verifying Party : IESG > ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Oct 7 08:09:51 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CBA1ABC74; Wed, 7 Oct 2015 08:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UR-nXK9MPnHt; Wed, 7 Oct 2015 08:09:29 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 99D141ABC75; Wed, 7 Oct 2015 08:09:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 14A02187FA9; Wed, 7 Oct 2015 08:08:16 -0700 (PDT) To: keshab@smsgt.com, vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151007150816.14A02187FA9@rfc-editor.org> Date: Wed, 7 Oct 2015 08:08:16 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, dime@ietf.org, iesg@ietf.org Subject: [Dime] [Errata Rejected] RFC6733 (4473) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 07 Oct 2015 15:09:31 -0000 The following errata report has been rejected for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=4473 -------------------------------------- Status: Rejected Type: Technical Reported by: Keshab Upadhya Date Reported: 2015-09-14 Rejected by: Stephen Farrell (IESG) Section: 6.1.4 Original Text ------------- 6.1.4. Processing Local Requests The Destination-Host AVP is not present, the Destination-Realm AVP contains a realm the server is configured to process locally, and the Diameter application is locally supported; or Corrected Text -------------- 6.1.4. Processing Local Requests The Destination-Host AVP is not present in peer routing table, the Destination-Realm AVP contains a realm the server is configured to process locally, and the Diameter application is locally supported; or Notes ----- 6.1.4 - Processing Local Requests The Destination-Host AVP is not present, the Destination-Realm AVP contains a realm the server is configured to process locally, and the Diameter application is locally supported 6.1.6 - Request Routing When a request is received that includes a realm and/or application that is not locally supported, the message is routed to the peer configured As given above 6.1.4 second rule contradicts with 6.1.6 para 2. --VERIFIER NOTES-- DIME chairs recommended reject -------------------------------------- RFC6733 (draft-ietf-dime-rfc3588bis-33) -------------------------------------- Title : Diameter Base Protocol Publication Date : October 2012 Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Mon Oct 12 09:15:55 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9A21A8886; Mon, 12 Oct 2015 09:15:52 -0700 (PDT) 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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lV30rs30h8vf; Mon, 12 Oct 2015 09:15:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 287E21A887F; Mon, 12 Oct 2015 09:15:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.5.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151012161546.14607.93723.idtracker@ietfa.amsl.com> Date: Mon, 12 Oct 2015 09:15:46 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-drmp-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 16:15:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Routing Message Priority Author : Steve Donovan Filename : draft-ietf-dime-drmp-01.txt Pages : 15 Date : 2015-10-12 Abstract: When making routing and resource allocation decisions, Diameter nodes currently have no generic mechanism to determine the relative priority of Diameter messages. This document addresses this by defining a mechanism to allow Diameter endpoints to indicate the relative priority of Diameter transactions. With this information Diameter nodes can factor that priority into routing, resource allocation and overload abatement decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-drmp-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-drmp-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 13 10:54:56 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1CA1A0204; Tue, 13 Oct 2015 10:54:53 -0700 (PDT) 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=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OOkqCESqK5e; Tue, 13 Oct 2015 10:54:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F3F71A01F7; Tue, 13 Oct 2015 10:54:47 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 83A371B846F; Tue, 13 Oct 2015 19:54:45 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.17]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 60994C8017; Tue, 13 Oct 2015 19:54:45 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%19]) with mapi id 14.03.0248.002; Tue, 13 Oct 2015 19:54:45 +0200 From: To: "Shaikh, Viqar A" , Janet P Gunn , "DOLLY, MARTIN C" Thread-Topic: [Dime] [dime] #92 (drmp): Range of priority levels Thread-Index: AQHQ+7/7gjQt6THBK0qRj4pp4rg/GJ5VZy8AgAADsACAAM9WwIACfqKAgBDpAPA= Date: Tue, 13 Oct 2015 17:54:43 +0000 Message-ID: <4618_1444758885_561D4565_4618_1311_2_6B7134B31289DC4FAF731D844122B36E01D43A89@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> , <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> In-Reply-To: <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E01D43A89OPEXCLILM43corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.10.8.134516 Archived-At: Cc: DiME , "dime@ietf.org" , "Pollini, Gregory P" Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 13 Oct 2015 17:54:53 -0000 --_000_6B7134B31289DC4FAF731D844122B36E01D43A89OPEXCLILM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Assuming that we define a range of 3 values, Assuming that 0 is the lowest priority and 2 the highest, Assuming that an agent receives 4 messages at the same time while being in = overload control: =B7 1) ULR with Prio-0 =B7 2) ULR with Prio-1 =B7 3) ULR with Prio-2 =B7 4) ULR with no priority AVP Assuming that the default is locally defined as proposed below, How do you know that the ULR with priority 2 will be handled with a higher = priority than the request without priority indication? And what about ULR message with priority 1 with two levels of highest prior= ity e.g. emergency/Important and government/very important? Sorry if the answer is obvious but I fail to understand. Lionel De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] Envoy=E9 : samedi 3 octobre 2015 01:21 =C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C Cc : DiME; dime@ietf.org; Pollini, Gregory P Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels Hello all, Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.21= 2 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defi= ned. Having 15 rather than 16 would be useful from an interworking point of view= on Diameter interfaces connecting to the EPS. Also, my understanding has been that the default value is per local policy. My 2 cents.... Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf of lionel.morand@orange.com [lionel.morand@orange.com] Sent: Thursday, October 01, 2015 3:36 AM To: Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Hi, I think that the case "no Priority indication in request" is the default si= tuation today. So if we agree that it should be possible to explicitly indicate a request = with a lower priority, we should divide the range of priority values in thr= ee sub-ranges: [lower priorities][no priority indication][higher priorities= ], e.g. with 17 values: [0-7][8][9-16]. If any operator can freely fix the default value, there would be no way to = ensure the sender that a request with a specific priority value (e.g. 6) wi= ll be handled with a lower or higher priority than a request with no priori= ty indication. Therefore, for a deterministic handling mechanism, I think that it is then = more relevant to define a standard value for the default value. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn Envoy=E9 : mercredi 30 septembre 2015 22:53 =C0 : DOLLY, MARTIN C Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels Same here. The "default priority" should be a matter of local policy. Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "DOLLY, MARTIN C" > To: Steve Donovan >, "dime@ietf.org" > Date: 09/30/2015 04:40 PM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" > ________________________________ Me as well From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, September 30, 2015 4:38 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels I'm okay with Jay's proposal on not specifying a default value. Steve On 9/30/15 3:27 PM, Lee, Jay wrote: Hi Steve and all, For the first proposal, as I indicated, I support increasing the number of = priority levels up to 16. I am also fine with the second proposal. My question is: do we need to mand= ate this feature, as individual operators have different situations? Perhap= s some flexibility should be allowed? Instead of mandating it, we can inclu= de the statement that when there is no DRMP AVP, this correspond to 'normal= traffic' without a particular high or low priority. Then each operator can= map this default to a value (e.g., 8 or something else) that they feel app= ropriate. Thanks, Jay _______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E01D43A89OPEXCLILM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Assuming t= hat we define a range of 3 values,

Assuming t= hat 0 is the lowest priority and 2 the highest,

Assuming t= hat an agent receives 4 messages at the same time while being in overload c= ontrol:

=B7    =      1)= ULR with Prio-0

=B7    =      2)= ULR with Prio-1

=B7    =      3)= ULR with Prio-2

=B7    =      4)= ULR with no priority AVP

 = ;

Assuming t= hat the default is locally defined as proposed below,

 = ;

How do you= know that the ULR with priority 2 will be handled with a higher priority &= nbsp;than the request without priority indication?

And what a= bout ULR message with priority 1 with two levels of highest priority e.g. e= mergency/Important and government/very important?

 = ;

Sorry if t= he answer is obvious but I fail to understand.

 = ;

Lionel

 = ;

 = ;

 &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  

De : Shai= kh, Viqar A [mailto:vshaikh@appcomsci.com]
Envoy=E9 : samedi 3 octobre 2015 01:21
=C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; dime@ietf.org; Pollini, Gregory P
Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels<= o:p>

 

Hello all,

 

Note that the 3GPP prio= rity, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 takes 15 values,= value 1 the highest, 15 the lowest, and value 0 not defined.

 

Having 15 rather than 16 wou= ld be useful from an interworking point of view on Diameter interfaces conn= ecting to the EPS.  

 

Also, my understanding has b= een that the default value is per local policy. 

 

My 2 cents....

Viqar 

From: DiME [dime-bounces@ietf.org]= on behalf of lionel.morand@orange.com [lionel.morand@orange.com]
Sent: Thursday, October 01, 2015 3:36 AM
To: Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels

Hi,=

 =

I think th= at the case "no Priority indication in request" is the default si= tuation today.

So if we a= gree that it should be possible to explicitly indicate a request with a low= er priority, we should divide the range of priority values in three sub-ranges: [lower priorities][no priority indication][higher pri= orities], e.g. with 17 values: [0-7][8][9-16].

If any ope= rator can freely fix the default value, there would be no way to ensure the= sender that a request with a specific priority value (e.g. 6) will be handled with a lower or higher priority than a request with no = priority indication.

 =

Therefore,= for a deterministic handling mechanism, I think that it is then more relev= ant to define a standard value for the default value.

 =

Regards,

 =

Lionel

 =

 =

De : DiME [mailto:d= ime-bounces@ietf.org] De la part de Janet P Gunn
Envoy=E9 : mercredi 30 septembre 2015 22:53
=C0 : DOLLY, MARTIN C
Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels<= /span>

 =

Same here.  The "de= fault priority" should be a matter of local policy.

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose.



From:        "DOLLY, MARTIN C" <md3135@att.com>
To:        Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org= " <dime@ietf.org= >
Date:        09/30/2015 04:40 PM
Subject:        <= span style=3D"font-size:7.5pt;font-family:"Arial","sans-seri= f";color:black">Re: [Dime] [dime] #92 (drmp): Range of priority levels=
Sent by:        <= span style=3D"font-size:7.5pt;font-family:"Arial","sans-seri= f";color:black">"DiME" <dime-bounces@ietf.org>




Me as well
 
From: DiME [mailto:dime-bounces@ietf.org= ] On Behalf Of Steve Donovan
Sent: Wednesday, September 30, 2015 4:38 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels<= span style=3D"color:black">
 
I'm okay with Jay's proposal on not specify= ing a default value.

Steve
On 9/30/15 3:27 PM, Lee, Jay wrote:<= span style=3D"color:black">
Hi Steve and all,
 
For the first proposal, as I indicated, I s= upport increasing the number of priority levels up to 16.
 
I am also fine with the second proposal. My= question is: do we need to mandate this feature, as individual operators h= ave different situations? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that whe= n there is no DRMP AVP, this correspond to ‘normal traffic’ wit= hout a particular high or low priority. Then each operator can map this def= ault to a value (e.g., 8 or something else) that they feel appropriate.
 
Thanks,
 
Jay



_______________________________________________
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 c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies san=
s autorisation. Si vous avez recu ce message par erreur, veuillez le signal=
er
a l'expediteur et le detruire ainsi que le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n,
Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may conta=
in confidential or privileged information that may be protected by law;
they should not be distributed, used or co=
pied without authorisation.
If you have received this email in error, =
please notify the sender and delete this message and its attachments.<=
/o:p>
As emails may be altered, Orange is not li=
able for messages 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,
Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E01D43A89OPEXCLILM43corp_-- From nobody Wed Oct 14 00:59:49 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9A61B2C1E; Wed, 14 Oct 2015 00:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfrOaFsumghm; Wed, 14 Oct 2015 00:59:41 -0700 (PDT) Received: from eris.verizonwireless.com (eris.verizonwireless.com [137.188.99.119]) by ietfa.amsl.com (Postfix) with ESMTP id 062E21B2C1F; Wed, 14 Oct 2015 00:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizonwireless.com; i=@verizonwireless.com; q=dns/txt; s=prodmail; t=1444809581; x=1476345581; h=from:to:cc:subject:date:references:in-reply-to: mime-version; bh=bmmoBuGTaYW/+XDYs0p/pjTW/LkA1fJxOidQQHnl9II=; b=EO6+HlOOg/pGKu9937M4UGzTuoG64cCXt0MAKht2WT7fRsFn+BLlfVUm Sg522XEEpERa47gdaer+lOQ6f5/PF3JNdP2Z0BAxH0HVuj1mJ42na1QJg H+pykLUhSMWqs1PIsS7ZcHIfpoccz5Ev4LcJZr5ByZQnfdfVVKPaOKuyN o=; X-Host: mariner.tdc.vzwcorp.com Received: from casac1exh003.uswin.ad.vzwcorp.com ([10.11.218.45]) by eris.verizonwireless.com with ESMTP/TLS/AES128-SHA; 14 Oct 2015 03:59:39 -0400 Received: from CASAC1EXP009.uswin.ad.vzwcorp.com ([fe80::558c:d7cc:1a42:f4d6]) by CASAC1EXH003.uswin.ad.vzwcorp.com ([fe80::ac7a:86c8:a3d2:d734%11]) with mapi id 14.03.0146.000; Wed, 14 Oct 2015 00:59:37 -0700 From: "Lee, Jay" To: "lionel.morand@orange.com" , "Shaikh, Viqar A" , Janet P Gunn , "DOLLY, MARTIN C" Thread-Topic: [Dime] [dime] #92 (drmp): Range of priority levels Thread-Index: AQHQ+7/7gjQt6THBK0qRj4pp4rg/GJ5VZy8AgAADsACAAM9WwIACfqKAgBDpAPCAAQNi0A== Date: Wed, 14 Oct 2015 07:59:37 +0000 References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> , <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.11.60.250] Content-Type: multipart/alternative; boundary="_000_C026C31E3CD6CA43953D6D95AB48048001A313CASAC1EXP009uswin_" MIME-Version: 1.0 Message-Id: <20151014075941.062E21B2C1F@ietfa.amsl.com> Archived-At: Cc: DiME , "dime@ietf.org" , "Pollini, Gregory P" Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2015 07:59:48 -0000 --_000_C026C31E3CD6CA43953D6D95AB48048001A313CASAC1EXP009uswin_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Regarding the issue of whether we need to specify a default value or not, t= here are pros and cons. If we specify a value for the default case, we can see the benefits in scen= arios between different operator networks, but we take away important optio= ns on what operators can do with priority values. On the other hand, if we = do not specify the default value, operators may have more options, but ther= e is a question of what to do for this inter-PLMN cases when the networks m= ay use different default values. In practice, this issue can be addressed at the edge of the network, where = Diameter edge agent (DEA) can perform some priority mapping based on bilate= ral roaming agreement (or SLA (service level agreement)) and other means to= insure the proper handling. One may argue that this is not as good as the = 'deterministic' case, but operator should be able handle this in a reasonab= le way. We are fully aware of the fact that, in case of this 'non-determini= stic' case, the default value can differ from one operator network to anoth= er, and it becomes difficult to guarantee the intended priority handling. D= espite this, we still prefer giving options to operators by not specifying = the default value. What we are saying here, however, is not anything new. This is the typical = way of handling priority levels. If anything, specifying the default value = would be something new. As already mentioned in CT discussion, there is a g= ood example of this - Internet QoS, more specifically DiffServ. In order to guarantee end-to-end QoS for a specific service, IETF could hav= e specified a value (DiffServ codepoint) for the specific service to have p= redetermined handling of the traffic, but IETF did not. Instead, DiffServ s= imply provided a framework for operators to have its own classification an= d differentiated treatment of the services. To guarantee end-to-end QoS acr= oss different networks, then, operators need to do packet inspection, (re)c= lassification, QoS mapping, use of SLA and possibly others at the edge of n= etwork (edge router). Therefore, in the DiffServ architecture, intelligence= was pushed to the edge of the network. While the end results may not be gu= aranteed as well as in the case of predetermined handling, it was still a p= referred way to give flexibility to operators. My point is that we went thr= ough all these troubles to give options of priority handling to operators. By the way, if we are thinking of possibility of specifying the default val= ue, are we assuming that all operators are interested in this feature (defa= ult value in the middle, and high and low priorities at other ends)? Aren't= there other operators who are not interested in this feature? I know that = at least there is one - Verizon. We have no interest in this feature, and n= o plan for implementing it. We are OK, if other operators are interested in= this feature, and the default value is NOT specified. But we are certainly= not happy if DIME is trying to impose this on us. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, October 13, 2015 10:55 AM To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org; Pollini, Gregory P Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Assuming that we define a range of 3 values, Assuming that 0 is the lowest priority and 2 the highest, Assuming that an agent receives 4 messages at the same time while being in = overload control: =B7 1) ULR with Prio-0 =B7 2) ULR with Prio-1 =B7 3) ULR with Prio-2 =B7 4) ULR with no priority AVP Assuming that the default is locally defined as proposed below, How do you know that the ULR with priority 2 will be handled with a higher = priority than the request without priority indication? And what about ULR message with priority 1 with two levels of highest prior= ity e.g. emergency/Important and government/very important? Sorry if the answer is obvious but I fail to understand. Lionel De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] Envoy=E9 : samedi 3 octobre 2015 01:21 =C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C Cc : DiME; dime@ietf.org; Pollini, Gregory P Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels Hello all, Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.21= 2 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defi= ned. Having 15 rather than 16 would be useful from an interworking point of view= on Diameter interfaces connecting to the EPS. Also, my understanding has been that the default value is per local policy. My 2 cents.... Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf of lionel.morand@orange.com [lionel.morand@orange.com] Sent: Thursday, October 01, 2015 3:36 AM To: Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Hi, I think that the case "no Priority indication in request" is the default si= tuation today. So if we agree that it should be possible to explicitly indicate a request = with a lower priority, we should divide the range of priority values in thr= ee sub-ranges: [lower priorities][no priority indication][higher priorities= ], e.g. with 17 values: [0-7][8][9-16]. If any operator can freely fix the default value, there would be no way to = ensure the sender that a request with a specific priority value (e.g. 6) wi= ll be handled with a lower or higher priority than a request with no priori= ty indication. Therefore, for a deterministic handling mechanism, I think that it is then = more relevant to define a standard value for the default value. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn Envoy=E9 : mercredi 30 septembre 2015 22:53 =C0 : DOLLY, MARTIN C Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels Same here. The "default priority" should be a matter of local policy. Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "DOLLY, MARTIN C" > To: Steve Donovan >, "dime@ietf.org" > Date: 09/30/2015 04:40 PM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" = > ________________________________ Me as well From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, September 30, 2015 4:38 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels I'm okay with Jay's proposal on not specifying a default value. Steve On 9/30/15 3:27 PM, Lee, Jay wrote: Hi Steve and all, For the first proposal, as I indicated, I support increasing the number of = priority levels up to 16. I am also fine with the second proposal. My question is: do we need to mand= ate this feature, as individual operators have different situations? Perhap= s some flexibility should be allowed? Instead of mandating it, we can inclu= de the statement that when there is no DRMP AVP, this correspond to 'normal= traffic' without a particular high or low priority. Then each operator can= map this default to a value (e.g., 8 or something else) that they feel app= ropriate. Thanks, Jay _______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_C026C31E3CD6CA43953D6D95AB48048001A313CASAC1EXP009uswin_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Regarding the issue of wh= ether we need to specify a default value or not, there are pros and cons.

 <= /p>

If we specify a value for= the default case, we can see the benefits in scenarios between different o= perator networks, but we take away important options on what operators can do with priority values. On the other hand, if we do no= t specify the default value, operators may have more options, but there is = a question of what to do for this inter-PLMN cases when the networks may us= e different default values.

 <= /p>

In practice, this issue c= an be addressed at the edge of the network, where Diameter edge agent (DEA)= can perform some priority mapping based on bilateral roaming agreement (or SLA (service level agreement)) and other means to insure the= proper handling. One may argue that this is not as good as the ‘dete= rministic’ case, but operator should be able handle this in a reasona= ble way. We are fully aware of the fact that, in case of this ‘non-deterministic’ case, the default value ca= n differ from one operator network to another, and it becomes difficult to = guarantee the intended priority handling. Despite this, we still prefer giv= ing options to operators by not specifying the default value.

 <= /p>

What we are saying here, = however, is not anything new. This is the typical way of handling priority = levels. If anything, specifying the default value would be something new. As already mentioned in CT discussion, there is a good e= xample of this – Internet QoS, more specifically DiffServ.=

 <= /p>

In order to guarantee end= -to-end QoS for a specific service, IETF could have specified a value (Diff= Serv codepoint) for the specific service to have predetermined handling of the traffic, but IETF did not. Instead, DiffServ simply provid= ed a framework for operators to have its own  classification and diffe= rentiated treatment of the services. To guarantee end-to-end QoS across dif= ferent networks, then, operators need to do packet inspection, (re)classification, QoS mapping, use of SLA and p= ossibly others at the edge of network (edge router). Therefore, in the Diff= Serv architecture, intelligence was pushed to the edge of the network. Whil= e the end results may not be guaranteed as well as in the case of predetermined handling, it was still a preferred= way to give flexibility to operators. My point is that we went through all= these troubles to give options of priority handling to operators.

 <= /p>

By the way, if we are thi= nking of possibility of specifying the default value, are we assuming that = all operators are interested in this feature (default value in the middle, and high and low priorities at other ends)? Aren’t th= ere other operators who are not interested in this feature? I know that at = least there is one – Verizon. We have no interest in this feature, an= d no plan for implementing it. We are OK, if other operators are interested in this feature, and the default value is N= OT specified. But we are certainly not happy if DIME is trying to impose th= is on us.

 <= /p>

Jay

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Tuesday, October 13, 2015 10:55 AM
To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; dime@ietf.org; Pollini, Gregory P
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels=

 

Assuming that we define a= range of 3 values,

Assuming that 0 is the lo= west priority and 2 the highest,

Assuming that an agent re= ceives 4 messages at the same time while being in overload control:

=B7       1) ULR with Prio-= 0

=B7       2) ULR with Prio-= 1

=B7       3) ULR with Prio-= 2

=B7       4) ULR with no pr= iority AVP

 <= /p>

Assuming that the default= is locally defined as proposed below,

 <= /p>

How do you know that the = ULR with priority 2 will be handled with a higher priority  than the r= equest without priority indication?

And what about ULR messag= e with priority 1 with two levels of highest priority e.g. emergency/Import= ant and government/very important?

 <= /p>

Sorry if the answer is ob= vious but I fail to understand.

 <= /p>

Lionel<= /p>

 <= /p>

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;

De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com]
Envoy=E9 : samedi 3 octobre 2015 01:21
=C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; dime@ietf.org; = Pollini, Gregory P
Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels<= o:p>

 

Hello all,

 

Note that t= he 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 take= s 15 values, value 1 the highest, 15 the lowest, and value 0 not defined.

 

Having 15 rather= than 16 would be useful from an interworking point of view on Diameter int= erfaces connecting to the EPS.  

 

Also, my underst= anding has been that the default value is per local policy. =

 

My 2 cents....

Viqar =

From: DiME= [dime-bounces@ietf.org] on behalf of lionel.morand@ora= nge.com [lionel.morand@orange.com]
Sent: Thursday, October 01, 2015 3:36 AM
To: Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels

Hi,

 <= /o:p>

I think that the case &qu= ot;no Priority indication in request" is the default situation today.<= /span>

So if we agree that it sh= ould be possible to explicitly indicate a request with a lower priority, we= should divide the range of priority values in three sub-ranges: [lower priorities][no priority indication][higher priorities], e.g. with 1= 7 values: [0-7][8][9-16].

If any operator can freel= y fix the default value, there would be no way to ensure the sender that a = request with a specific priority value (e.g. 6) will be handled with a lower or higher priority than a request with no priority in= dication.<= /p>

 <= /o:p>

Therefore, for a determin= istic handling mechanism, I think that it is then more relevant to define a= standard value for the default value.

 <= /o:p>

Regards,

 <= /o:p>

Lionel

 <= /o:p>

 <= /o:p>

De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn
Envoy=E9 : mercredi 30 septembre 2015 22:53
=C0 : DOLLY, MARTIN C
Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels<= /span>

 <= /o:p>

Same here.  = The "default priority" should be a matter of local policy.=

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose.



From:        = ;"DOLLY, MARTIN C" <<= a href=3D"mailto:md3135@att.com" target=3D"_blank">md3135@att.com>
To:        <= /span>Steve Donovan <srdonovan@usdonovans.com&g= t;, "dime@ietf.org= " <dime@ietf.org= >
Date:        = ;09/30/2015 04:40 PM
Subject:       &n= bsp;Re: [Dime] [dime] #92 (drmp): = Range of priority levels
Sent by:       &n= bsp;"DiME" <dime-bounces@ietf.org>




Me as well
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Wednesday, September 30, 2015 4:38 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels<= span lang=3D"FR" style=3D"color:black">
 
I'm okay with Jay's proposal on= not specifying a default value.

Steve
On 9/30/15 3:27 PM, Lee, Jay wr= ote:
Hi Steve and all,
 
For the first proposal, as I in= dicated, I support increasing the number of priority levels up to 16.
 
I am also fine with the second = proposal. My question is: do we need to mandate this feature, as individual= operators have different situations? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement t= hat when there is no DRMP AVP, this correspond to ‘normal trafficR= 17; without a particular high or low priority. Then each operator can map t= his default to a value (e.g., 8 or something else) that they feel appropriate.
 
Thanks,
 
Jay



_______________________________________________
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 joint=
es peuvent contenir des informations confidentielles ou privilegiees et ne =
doivent donc
pas etre diffuses, exploites o=
u copies sans autorisation. Si vous avez recu ce message par erreur, veuill=
ez le signaler
a l'expediteur et le detruire =
ainsi que les pieces jointes. Les messages electroniques etant susceptibles=
 d'alteration,
Orange decline toute responsab=
ilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachmen=
ts 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 emai=
l in error, please notify the sender and delete this message and its attach=
ments.
As emails may be altered, Oran=
ge is not liable for messages that have been modified, changed or falsified=
.
Thank you.

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_C026C31E3CD6CA43953D6D95AB48048001A313CASAC1EXP009uswin_-- From nobody Wed Oct 14 07:12:35 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B45A1A8771 for ; Wed, 14 Oct 2015 07:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os8hUrJ5G_g9 for ; Wed, 14 Oct 2015 07:12:29 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8ED1A8753 for ; Wed, 14 Oct 2015 07:12:28 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:58852 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1ZmMn4-001QP5-1L for dime@ietf.org; Wed, 14 Oct 2015 07:12:28 -0700 To: dime@ietf.org References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> <20151014075941.062E21B2C1F@ietfa.amsl.com> From: Steve Donovan Message-ID: <561E62C9.20500@usdonovans.com> Date: Wed, 14 Oct 2015 09:12:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151014075941.062E21B2C1F@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------030900020306090705050503" X-OutGoing-Spam-Status: No, score=0.6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2015 14:12:33 -0000 This is a multi-part message in MIME format. --------------030900020306090705050503 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Jay, The current text is a SHOULD level requirement: When there is a mix of transactions specifying priority in request messages and transactions that do not have the priority specified, transactions that do not have a specified priority SHOULD be treated as having the PRIORITY_14 priority. As such, operators can choose to either not implement a priority or define a different value for their network. I propose adding the following note after this paragraph to further explain why it is a SHOULD and not a MUST: Note: There are scenarios where operators might want to specify a different default value for transactions that do not have an explicit priority. In this case, the operator defined local policy would override the use of PRIORITY_14 as the default priority. This leaves the ability for there to be deterministic behavior in Diameter networks that require a default to be defined and are happy with the specified default. It also gives operators the ability to define a different behavior, most likely with some priority handling/mapping at the edge of the network. Does this address your concerns? Regards, Steve On 10/14/15 2:59 AM, Lee, Jay wrote: > > Regarding the issue of whether we need to specify a default value or > not, there are pros and cons. > > If we specify a value for the default case, we can see the benefits in > scenarios between different operator networks, but we take away > important options on what operators can do with priority values. On > the other hand, if we do not specify the default value, operators may > have more options, but there is a question of what to do for this > inter-PLMN cases when the networks may use different default values. > > In practice, this issue can be addressed at the edge of the network, > where Diameter edge agent (DEA) can perform some priority mapping > based on bilateral roaming agreement (or SLA (service level > agreement)) and other means to insure the proper handling. One may > argue that this is not as good as the ‘deterministic’ case, but > operator should be able handle this in a reasonable way. We are fully > aware of the fact that, in case of this ‘non-deterministic’ case, the > default value can differ from one operator network to another, and it > becomes difficult to guarantee the intended priority handling. Despite > this, we still prefer giving options to operators by not specifying > the default value. > > What we are saying here, however, is not anything new. This is the > typical way of handling priority levels. If anything, specifying the > default value would be something new. As already mentioned in CT > discussion, there is a good example of this – Internet QoS, more > specifically DiffServ. > > In order to guarantee end-to-end QoS for a specific service, IETF > could have specified a value (DiffServ codepoint) for the specific > service to have predetermined handling of the traffic, but IETF did > not. Instead, DiffServ simply provided a framework for operators to > have its own classification and differentiated treatment of the > services. To guarantee end-to-end QoS across different networks, then, > operators need to do packet inspection, (re)classification, QoS > mapping, use of SLA and possibly others at the edge of network (edge > router). Therefore, in the DiffServ architecture, intelligence was > pushed to the edge of the network. While the end results may not be > guaranteed as well as in the case of predetermined handling, it was > still a preferred way to give flexibility to operators. My point is > that we went through all these troubles to give options of priority > handling to operators. > > By the way, if we are thinking of possibility of specifying the > default value, are we assuming that all operators are interested in > this feature (default value in the middle, and high and low priorities > at other ends)? Aren’t there other operators who are not interested in > this feature? I know that at least there is one – Verizon. We have no > interest in this feature, and no plan for implementing it. We are OK, > if other operators are interested in this feature, and the default > value is NOT specified. But we are certainly not happy if DIME is > trying to impose this on us. > > Jay > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of > *lionel.morand@orange.com > *Sent:* Tuesday, October 13, 2015 10:55 AM > *To:* Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C > *Cc:* DiME; dime@ietf.org; Pollini, Gregory P > *Subject:* Re: [Dime] [dime] #92 (drmp): Range of priority levels > > Assuming that we define a range of 3 values, > > Assuming that 0 is the lowest priority and 2 the highest, > > Assuming that an agent receives 4 messages at the same time while > being in overload control: > > ·1) ULR with Prio-0 > > ·2) ULR with Prio-1 > > ·3) ULR with Prio-2 > > ·4) ULR with no priority AVP > > Assuming that the default is locally defined as proposed below, > > How do you know that the ULR with priority 2 will be handled with a > higher priority than the request without priority indication? > > And what about ULR message with priority 1 with two levels of highest > priority e.g. emergency/Important and government/very important? > > Sorry if the answer is obvious but I fail to understand. > > Lionel > > *De :*Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] > *Envoyé :* samedi 3 octobre 2015 01:21 > *À :* MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C > *Cc :* DiME; dime@ietf.org ; Pollini, Gregory P > *Objet :* RE: [Dime] [dime] #92 (drmp): Range of priority levels > > Hello all, > > Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS > 29.212 takes 15 values, value 1 the highest, 15 the lowest, and value > 0 not defined. > > Having 15 rather than 16 would be useful from an interworking point of > view on Diameter interfaces connecting to the EPS. > > Also, my understanding has been that the default value is per local > policy. > > My 2 cents.... > > Viqar > > ------------------------------------------------------------------------ > > *From:*DiME [dime-bounces@ietf.org] on behalf of > lionel.morand@orange.com > [lionel.morand@orange.com] > *Sent:* Thursday, October 01, 2015 3:36 AM > *To:* Janet P Gunn; DOLLY, MARTIN C > *Cc:* DiME; dime@ietf.org > *Subject:* Re: [Dime] [dime] #92 (drmp): Range of priority levels > > Hi, > > I think that the case "no Priority indication in request" is the > default situation today. > > So if we agree that it should be possible to explicitly indicate a > request with a lower priority, we should divide the range of priority > values in three sub-ranges: [lower priorities][no priority > indication][higher priorities], e.g. with 17 values: [0-7][8][9-16]. > > If any operator can freely fix the default value, there would be no > way to ensure the sender that a request with a specific priority value > (e.g. 6) will be handled with a lower or higher priority than a > request with no priority indication. > > Therefore, for a deterministic handling mechanism, I think that it is > then more relevant to define a standard value for the default value. > > Regards, > > Lionel > > *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Janet P Gunn > *Envoyé :* mercredi 30 septembre 2015 22:53 > *À :* DOLLY, MARTIN C > *Cc :* DiME; dime@ietf.org > *Objet :* Re: [Dime] [dime] #92 (drmp): Range of priority levels > > Same here. The "default priority" should be a matter of local policy. > > Janet > > This is a PRIVATE message. If you are not the intended recipient, > please delete without copying and kindly advise us by e-mail of the > mistake in delivery. NOTE: Regardless of content, this e-mail shall > not operate to bind CSC to any order or other contract unless pursuant > to explicit written agreement or government initiative expressly > permitting the use of e-mail for such purpose. > > > > From: "DOLLY, MARTIN C" > > To: Steve Donovan >, "dime@ietf.org > " > > Date: 09/30/2015 04:40 PM > Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels > Sent by: "DiME" > > > ------------------------------------------------------------------------ > > > > > Me as well > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan* > Sent:* Wednesday, September 30, 2015 4:38 PM* > To:* dime@ietf.org * > Subject:* Re: [Dime] [dime] #92 (drmp): Range of priority levels > > I'm okay with Jay's proposal on not specifying a default value. > > Steve > On 9/30/15 3:27 PM, Lee, Jay wrote: > Hi Steve and all, > > For the first proposal, as I indicated, I support increasing the > number of priority levels up to 16. > > I am also fine with the second proposal. My question is: do we need to > mandate this feature, as individual operators have different > situations? Perhaps some flexibility should be allowed? Instead of > mandating it, we can include the statement that when there is no DRMP > AVP, this correspond to ‘normal traffic’ without a particular high or > low priority. Then each operator can map this default to a value > (e.g., 8 or something else) that they feel appropriate. > > Thanks, > > Jay > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > This message and its attachments may contain confidential or > privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. > _________________________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > This message and its attachments may contain confidential or > privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------030900020306090705050503 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Jay,

The current text is a SHOULD level requirement:

   When there is a mix of transactions specifying priority in request
   messages and transactions that do not have the priority specified,
   transactions that do not have a specified priority SHOULD be treated
   as having the PRIORITY_14 priority.

As such, operators can choose to either not implement a priority or define a different value for their network.

I propose adding the following note after this paragraph to further explain why it is a SHOULD and not a MUST:

      Note: There are scenarios where operators might want to
      specify a different default value for transactions that do not
      have an explicit priority.  In this case, the operator defined
      local policy would override the use of PRIORITY_14 as
      the default priority.

This leaves the ability for there to be deterministic behavior in Diameter networks that require a default to be defined and are happy with the specified default.  It also gives operators the ability to define a different behavior, most likely with some priority handling/mapping at the edge of the network.

Does this address your concerns?

Regards,

Steve

On 10/14/15 2:59 AM, Lee, Jay wrote:

Regarding the issue of whether we need to specify a default value or not, there are pros and cons.

 

If we specify a value for the default case, we can see the benefits in scenarios between different operator networks, but we take away important options on what operators can do with priority values. On the other hand, if we do not specify the default value, operators may have more options, but there is a question of what to do for this inter-PLMN cases when the networks may use different default values.

 

In practice, this issue can be addressed at the edge of the network, where Diameter edge agent (DEA) can perform some priority mapping based on bilateral roaming agreement (or SLA (service level agreement)) and other means to insure the proper handling. One may argue that this is not as good as the ‘deterministic’ case, but operator should be able handle this in a reasonable way. We are fully aware of the fact that, in case of this ‘non-deterministic’ case, the default value can differ from one operator network to another, and it becomes difficult to guarantee the intended priority handling. Despite this, we still prefer giving options to operators by not specifying the default value.

 

What we are saying here, however, is not anything new. This is the typical way of handling priority levels. If anything, specifying the default value would be something new. As already mentioned in CT discussion, there is a good example of this – Internet QoS, more specifically DiffServ.

 

In order to guarantee end-to-end QoS for a specific service, IETF could have specified a value (DiffServ codepoint) for the specific service to have predetermined handling of the traffic, but IETF did not. Instead, DiffServ simply provided a framework for operators to have its own  classification and differentiated treatment of the services. To guarantee end-to-end QoS across different networks, then, operators need to do packet inspection, (re)classification, QoS mapping, use of SLA and possibly others at the edge of network (edge router). Therefore, in the DiffServ architecture, intelligence was pushed to the edge of the network. While the end results may not be guaranteed as well as in the case of predetermined handling, it was still a preferred way to give flexibility to operators. My point is that we went through all these troubles to give options of priority handling to operators.

 

By the way, if we are thinking of possibility of specifying the default value, are we assuming that all operators are interested in this feature (default value in the middle, and high and low priorities at other ends)? Aren’t there other operators who are not interested in this feature? I know that at least there is one – Verizon. We have no interest in this feature, and no plan for implementing it. We are OK, if other operators are interested in this feature, and the default value is NOT specified. But we are certainly not happy if DIME is trying to impose this on us.

 

Jay

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Tuesday, October 13, 2015 10:55 AM
To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; dime@ietf.org; Pollini, Gregory P
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels

 

Assuming that we define a range of 3 values,

Assuming that 0 is the lowest priority and 2 the highest,

Assuming that an agent receives 4 messages at the same time while being in overload control:

·       1) ULR with Prio-0

·       2) ULR with Prio-1

·       3) ULR with Prio-2

·       4) ULR with no priority AVP

 

Assuming that the default is locally defined as proposed below,

 

How do you know that the ULR with priority 2 will be handled with a higher priority  than the request without priority indication?

And what about ULR message with priority 1 with two levels of highest priority e.g. emergency/Important and government/very important?

 

Sorry if the answer is obvious but I fail to understand.

 

Lionel

 

 

                                          

De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com]
Envoyé : samedi 3 octobre 2015 01:21
À : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; dime@ietf.org; Pollini, Gregory P
Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels

 

Hello all,

 

Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined.

 

Having 15 rather than 16 would be useful from an interworking point of view on Diameter interfaces connecting to the EPS.  

 

Also, my understanding has been that the default value is per local policy. 

 

My 2 cents....

Viqar 

From: DiME [dime-bounces@ietf.org] on behalf of lionel.morand@orange.com [lionel.morand@orange.com]
Sent: Thursday, October 01, 2015 3:36 AM
To: Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels

Hi,

 

I think that the case "no Priority indication in request" is the default situation today.

So if we agree that it should be possible to explicitly indicate a request with a lower priority, we should divide the range of priority values in three sub-ranges: [lower priorities][no priority indication][higher priorities], e.g. with 17 values: [0-7][8][9-16].

If any operator can freely fix the default value, there would be no way to ensure the sender that a request with a specific priority value (e.g. 6) will be handled with a lower or higher priority than a request with no priority indication.

 

Therefore, for a deterministic handling mechanism, I think that it is then more relevant to define a standard value for the default value.

 

Regards,

 

Lionel

 

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn
Envoyé : mercredi 30 septembre 2015 22:53
À : DOLLY, MARTIN C
Cc : DiME; dime@ietf.org
Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels

 

Same here.  The "default priority" should be a matter of local policy.

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.



From:        "DOLLY, MARTIN C" <md3135@att.com>
To:        Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org>
Date:        09/30/2015 04:40 PM
Subject:        Re: [Dime] [dime] #92 (drmp): Range of priority levels
Sent by:        "DiME" <dime-bounces@ietf.org>




Me as well
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Wednesday, September 30, 2015 4:38 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels
 
I'm okay with Jay's proposal on not specifying a default value.

Steve
On 9/30/15 3:27 PM, Lee, Jay wrote:
Hi Steve and all,
 
For the first proposal, as I indicated, I support increasing the number of priority levels up to 16.
 
I am also fine with the second proposal. My question is: do we need to mandate this feature, as individual operators have different situations? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that when there is no DRMP AVP, this correspond to ‘normal traffic’ without a particular high or low priority. Then each operator can map this default to a value (e.g., 8 or something else) that they feel appropriate.
 
Thanks,
 
Jay



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

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.


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

--------------030900020306090705050503-- From nobody Wed Oct 14 08:39:53 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080621ACC8C for ; Wed, 14 Oct 2015 08:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.855 X-Spam-Level: X-Spam-Status: No, score=0.855 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWGFwVas2ai2 for ; Wed, 14 Oct 2015 08:39:46 -0700 (PDT) Received: from portland.eukhosting.net (unknown [92.48.97.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06331ACC8A for ; Wed, 14 Oct 2015 08:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=Qrh70ScnuSqXTdGyhCB2J/fhBD16UApSPN9uGfEnLYs=; b=C48ooKxYuLPBRxd4Xci+BKh2Drq4AKIZKlEm8Mowj1TGlAN4Z6NgymlH/2gR9eZ0suMez3viWxokfhUZQjalUu+V/ruPbFGYeAdI0JmWDIWX4/oNCyA3Mh3rwp4x3VL0JIqc5kRFRodhjy5dZjnsOtxu/raL2DY8LMCd3FzqbqI=; Received: from [65.114.147.218] (port=14034 helo=[192.168.1.140]) by portland.eukhosting.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1ZmO9R-000ZMa-44; Wed, 14 Oct 2015 16:39:42 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_5A5C7D72-E475-43F7-BA7E-301A3A96FD43" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: ken carlberg In-Reply-To: <561E62C9.20500@usdonovans.com> Date: Wed, 14 Oct 2015 11:39:35 -0400 Message-Id: <10775986-661B-4081-8862-BE22028749EE@g11.org.uk> References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> <20151014075941.062E21B2C1F@ietfa.amsl.com> <561E62C9.20500@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.2104) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Get-Message-Sender-Via: portland.eukhosting.net: authenticated_id: carlberg@g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: dime@ietf.org Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2015 15:39:51 -0000 --Apple-Mail=_5A5C7D72-E475-43F7-BA7E-301A3A96FD43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 with respect to the diff-serv example brought up below, some thing to = add to that discussion is that it starts off with separate and distinct = forwarding behavior whose marked packets provide segmentation of other = IP traffic. The availability of only 6 bits to play with (along with = the headaches of transitive trust) also discouraged a line of thought to = define end-to-end priority handling versus a per diff-serv domain = treatment. RFC-4594 did provide configuration guidelines, but that=92s = a different story. So back to a couple of ideas to consider. 1) reserved space. if we go back to the diff-serv model, the diff-serv = working group agreed to set aside a set of values that was reserved for = experimental use that could be re-assigned some time in the future. I=92m= not suggesting that there should be space set side for experiments, but = rather it may be prudent to set aside a reserved set of bits/values so = that one doesn't need to define a new AVP if in the future there was a = need to define added values beyond the 5 (plus some fudge factor) = already mentioned on the list.=20 2) sets of users. previous work (e.g., rfc-4412, rfc-6710) recognized = that there can be several sets of users/services that are distinct from = each other and yet need to prioritize the traffic. I bring this up = because the draft already identifies two sets of users in sections 5.1 = and 5.2 (note: I=92m assuming that the latter is aimed at the general = public and related to 911/112/999 type calls, which should probably be = more specific in the draft). And there is also the potential of = Firstnet users in the US. As a side note, the distinction and separation of general public and = other prioritized users in public phone infrastructures is not exclusive = to the US, so the group should not be concerned that this is a US = centric effort. There has been GTPS in the UK, as well as other systems = in other countries. The RFC is a bit dated, but feel free to go over = rfc-4190 for added background. and just to reiterate. I=92m not making recommendations in the above =97 = just bringing up some food for thought. -ken > On Oct 14, 2015, at 10:12 AM, Steve Donovan = wrote: >=20 > Jay, >=20 > The current text is a SHOULD level requirement: >=20 > When there is a mix of transactions specifying priority in request > messages and transactions that do not have the priority specified, > transactions that do not have a specified priority SHOULD be = treated > as having the PRIORITY_14 priority. >=20 > As such, operators can choose to either not implement a priority or = define a different value for their network. >=20 > I propose adding the following note after this paragraph to further = explain why it is a SHOULD and not a MUST: >=20 > Note: There are scenarios where operators might want to=20 > specify a different default value for transactions that do not > have an explicit priority. In this case, the operator defined > local policy would override the use of PRIORITY_14 as > the default priority. >=20 > This leaves the ability for there to be deterministic behavior in = Diameter networks that require a default to be defined and are happy = with the specified default. It also gives operators the ability to = define a different behavior, most likely with some priority = handling/mapping at the edge of the network. >=20 > Does this address your concerns? >=20 > Regards, >=20 > Steve >=20 > On 10/14/15 2:59 AM, Lee, Jay wrote: >> Regarding the issue of whether we need to specify a default value or = not, there are pros and cons. >> =20 >> If we specify a value for the default case, we can see the benefits = in scenarios between different operator networks, but we take away = important options on what operators can do with priority values. On the = other hand, if we do not specify the default value, operators may have = more options, but there is a question of what to do for this inter-PLMN = cases when the networks may use different default values. >> =20 >> In practice, this issue can be addressed at the edge of the network, = where Diameter edge agent (DEA) can perform some priority mapping based = on bilateral roaming agreement (or SLA (service level agreement)) and = other means to insure the proper handling. One may argue that this is = not as good as the =91deterministic=92 case, but operator should be able = handle this in a reasonable way. We are fully aware of the fact that, in = case of this =91non-deterministic=92 case, the default value can differ = from one operator network to another, and it becomes difficult to = guarantee the intended priority handling. Despite this, we still prefer = giving options to operators by not specifying the default value. >> =20 >> What we are saying here, however, is not anything new. This is the = typical way of handling priority levels. If anything, specifying the = default value would be something new. As already mentioned in CT = discussion, there is a good example of this =96 Internet QoS, more = specifically DiffServ. >> =20 >> In order to guarantee end-to-end QoS for a specific service, IETF = could have specified a value (DiffServ codepoint) for the specific = service to have predetermined handling of the traffic, but IETF did not. = Instead, DiffServ simply provided a framework for operators to have its = own classification and differentiated treatment of the services. To = guarantee end-to-end QoS across different networks, then, operators need = to do packet inspection, (re)classification, QoS mapping, use of SLA and = possibly others at the edge of network (edge router). Therefore, in the = DiffServ architecture, intelligence was pushed to the edge of the = network. While the end results may not be guaranteed as well as in the = case of predetermined handling, it was still a preferred way to give = flexibility to operators. My point is that we went through all these = troubles to give options of priority handling to operators. >> =20 >> By the way, if we are thinking of possibility of specifying the = default value, are we assuming that all operators are interested in this = feature (default value in the middle, and high and low priorities at = other ends)? Aren=92t there other operators who are not interested in = this feature? I know that at least there is one =96 Verizon. We have no = interest in this feature, and no plan for implementing it. We are OK, if = other operators are interested in this feature, and the default value is = NOT specified. But we are certainly not happy if DIME is trying to = impose this on us. >> =20 >> Jay >> =20 >> From: DiME [mailto:dime-bounces@ietf.org = ] On Behalf Of lionel.morand@orange.com = >> Sent: Tuesday, October 13, 2015 10:55 AM >> To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C >> Cc: DiME; dime@ietf.org ; Pollini, Gregory P >> Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels >> =20 >> Assuming that we define a range of 3 values, >> Assuming that 0 is the lowest priority and 2 the highest, >> Assuming that an agent receives 4 messages at the same time while = being in overload control: >> =B7 1) ULR with Prio-0 >> =B7 2) ULR with Prio-1 >> =B7 3) ULR with Prio-2 >> =B7 4) ULR with no priority AVP >> =20 >> Assuming that the default is locally defined as proposed below, >> =20 >> How do you know that the ULR with priority 2 will be handled with a = higher priority than the request without priority indication? >> And what about ULR message with priority 1 with two levels of highest = priority e.g. emergency/Important and government/very important? >> =20 >> Sorry if the answer is obvious but I fail to understand. >> =20 >> Lionel >> =20 >> =20 >> =20 >> De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com = ]=20 >> Envoy=E9 : samedi 3 octobre 2015 01:21 >> =C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C >> Cc : DiME; dime@ietf.org ; Pollini, Gregory P >> Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels >> =20 >> Hello all, >> =20 >> Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS = 29.212 takes 15 values, value 1 the highest, 15 the lowest, and value 0 = not defined. >> =20 >> Having 15 rather than 16 would be useful from an interworking point = of view on Diameter interfaces connecting to the EPS. =20 >> =20 >> Also, my understanding has been that the default value is per local = policy.=20 >> =20 >> My 2 cents.... >> Viqar=20 >> From: DiME [dime-bounces@ietf.org ] on = behalf of lionel.morand@orange.com = [lionel.morand@orange.com = ] >> Sent: Thursday, October 01, 2015 3:36 AM >> To: Janet P Gunn; DOLLY, MARTIN C >> Cc: DiME; dime@ietf.org >> Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels >>=20 >> Hi, >> =20 >> I think that the case "no Priority indication in request" is the = default situation today. >> So if we agree that it should be possible to explicitly indicate a = request with a lower priority, we should divide the range of priority = values in three sub-ranges: [lower priorities][no priority = indication][higher priorities], e.g. with 17 values: [0-7][8][9-16]. >> If any operator can freely fix the default value, there would be no = way to ensure the sender that a request with a specific priority value = (e.g. 6) will be handled with a lower or higher priority than a request = with no priority indication. >> =20 >> Therefore, for a deterministic handling mechanism, I think that it is = then more relevant to define a standard value for the default value. >> =20 >> Regards, >> =20 >> Lionel >> =20 >> =20 >> De : DiME [mailto:dime-bounces@ietf.org = ] De la part de Janet P Gunn >> Envoy=E9 : mercredi 30 septembre 2015 22:53 >> =C0 : DOLLY, MARTIN C >> Cc : DiME; dime@ietf.org >> Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels >> =20 >> Same here. The "default priority" should be a matter of local = policy.=20 >>=20 >> Janet >>=20 >> This is a PRIVATE message. If you are not the intended recipient, = please delete without copying and kindly advise us by e-mail of the = mistake in delivery. NOTE: Regardless of content, this e-mail shall not = operate to bind CSC to any order or other contract unless pursuant to = explicit written agreement or government initiative expressly permitting = the use of e-mail for such purpose.=20 >>=20 >>=20 >>=20 >> From: "DOLLY, MARTIN C" < = md3135@att.com >=20 >> To: Steve Donovan < = srdonovan@usdonovans.com = >, "dime@ietf.org = " >=20 >> Date: 09/30/2015 04:40 PM=20 >> Subject: Re: [Dime] [dime] #92 (drmp): Range of priority = levels=20 >> Sent by: "DiME" > >>=20 >>=20 >>=20 >> Me as well=20 >> =20 >> From: DiME [mailto:dime-bounces@ietf.org = ] On Behalf Of Steve Donovan >> Sent: Wednesday, September 30, 2015 4:38 PM >> To: dime@ietf.org >> Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels=20 >> =20 >> I'm okay with Jay's proposal on not specifying a default value. >>=20 >> Steve=20 >> On 9/30/15 3:27 PM, Lee, Jay wrote:=20 >> Hi Steve and all,=20 >> =20 >> For the first proposal, as I indicated, I support increasing the = number of priority levels up to 16.=20 >> =20 >> I am also fine with the second proposal. My question is: do we need = to mandate this feature, as individual operators have different = situations? Perhaps some flexibility should be allowed? Instead of = mandating it, we can include the statement that when there is no DRMP = AVP, this correspond to =91normal traffic=92 without a particular high = or low priority. Then each operator can map this default to a value = (e.g., 8 or something else) that they feel appropriate.=20 >> =20 >> Thanks,=20 >> =20 >> Jay=20 >>=20 >>=20 >>=20 >> _______________________________________________=20 >> DiME mailing list=20 >> DiME@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/dime = =20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> = https://www.ietf.org/mailman/l= istinfo/dime >> = __________________________________________________________________________= _______________________________________________ >> =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, >> 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, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >> = __________________________________________________________________________= _______________________________________________ >> =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, >> 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, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=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 = --Apple-Mail=_5A5C7D72-E475-43F7-BA7E-301A3A96FD43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
with respect to the diff-serv example brought = up below, some thing to add to that discussion is that it starts off = with separate and distinct forwarding behavior whose marked packets = provide segmentation of other IP traffic.  The availability of only = 6 bits to play with (along with the headaches of transitive trust) also = discouraged a line of thought to define end-to-end priority handling = versus a per diff-serv domain treatment.  RFC-4594 did provide = configuration guidelines, but that=92s a different story.

So back to a couple of = ideas to consider.

1) reserved space.  if we go back to the diff-serv = model, the diff-serv working group agreed to set aside a set of values = that was reserved for experimental use that could be re-assigned some = time in the future.  I=92m not suggesting that there should be = space set side for experiments, but rather it may be prudent to set = aside a reserved set of bits/values so that one doesn't need to define a = new AVP if in the future there was a need to define added values beyond = the 5 (plus some fudge factor) already mentioned on the = list. 

2) = sets of users.  previous work (e.g., rfc-4412, rfc-6710) recognized = that there can be several sets of users/services that are distinct from = each other and yet need to prioritize the traffic.  I bring this up = because the draft already identifies two sets of users in sections 5.1 = and 5.2 (note: I=92m assuming that the latter is aimed at the general = public and related to 911/112/999 type calls, which should probably be = more specific in the draft).  And there is also the potential of = Firstnet users in the US.

As a side note, the distinction and separation of general = public and other prioritized users in public phone infrastructures is = not exclusive to the US, so the group should not be concerned that this = is a US centric effort.  There has been GTPS in the UK, as well as = other systems in other countries.  The RFC is a bit dated, but feel = free to go over rfc-4190 for added background.

and just to reiterate.  I=92m not = making recommendations in the above =97 just bringing up some food for = thought.

-ken


On = Oct 14, 2015, at 10:12 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

Jay,

The current = text is a SHOULD level requirement:

   = When there is a mix of transactions specifying priority in = request
   = messages and transactions that do not have the priority = specified,
   = transactions that do not have a specified priority SHOULD be = treated
   = as having the PRIORITY_14 priority.

As such, = operators can choose to either not implement a priority or define a = different value for their network.

I propose = adding the following note after this paragraph to further explain why it = is a SHOULD and not a MUST:

      Note: There are = scenarios where operators might want to 
      specify a = different default value for transactions that do not
      have an explicit = priority.  In this case, the operator defined
      local policy = would override the use of PRIORITY_14 as
      the default = priority.

This leaves the ability for there to be = deterministic behavior in Diameter networks that require a default to be = defined and are happy with the specified default.  It also gives = operators the ability to define a different behavior, most likely with = some priority handling/mapping at the edge of the network.

Does this = address your concerns?

Regards,

Steve
On 10/14/15 2:59 AM, Lee, Jay = wrote:
Regarding the issue of whether we need to = specify a default value or not, there are pros and cons.
 
If we specify a value = for the default case, we can see the benefits in scenarios between = different operator networks, but we take away important options on what = operators can do with priority values. On the other hand, if we do not = specify the default value, operators may have more options, but there is = a question of what to do for this inter-PLMN cases when the networks may = use different default values.
 
In practice, this issue can be addressed = at the edge of the network, where Diameter edge agent (DEA) can perform = some priority mapping based on bilateral roaming agreement (or SLA = (service level agreement)) and other means to insure the proper = handling. One may argue that this is not as good as the =91deterministic=92= case, but operator should be able handle this in a reasonable way. We = are fully aware of the fact that, in case of this =91non-deterministic=92 = case, the default value can differ from one operator network to another, = and it becomes difficult to guarantee the intended priority handling. = Despite this, we still prefer giving options to operators by not = specifying the default value.
 
What we are saying here, however, is not = anything new. This is the typical way of handling priority levels. If = anything, specifying the default value would be something new. As = already mentioned in CT discussion, there is a good example of this =96 = Internet QoS, more specifically DiffServ.
 
In order to guarantee = end-to-end QoS for a specific service, IETF could have specified a value = (DiffServ codepoint) for the specific service to have predetermined = handling of the traffic, but IETF did not. Instead, DiffServ simply = provided a framework for operators to have its own  classification = and differentiated treatment of the services. To guarantee end-to-end = QoS across different networks, then, operators need to do packet = inspection, (re)classification, QoS mapping, use of SLA and possibly = others at the edge of network (edge router). Therefore, in the DiffServ = architecture, intelligence was pushed to the edge of the network. While = the end results may not be guaranteed as well as in the case of = predetermined handling, it was still a preferred way to give flexibility = to operators. My point is that we went through all these troubles to = give options of priority handling to operators.
 
By the way, if we are = thinking of possibility of specifying the default value, are we assuming = that all operators are interested in this feature (default value in the = middle, and high and low priorities at other ends)? Aren=92t there other = operators who are not interested in this feature? I know that at least = there is one =96 Verizon. We have no interest in this feature, and no = plan for implementing it. We are OK, if other operators are interested = in this feature, and the default value is NOT specified. But we are = certainly not happy if DIME is trying to impose this on us.
 
Jay
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf = Of lionel.morand@orange.com
Sent: Tuesday, October 13, 2015 = 10:55 AM
To: Shaikh, Viqar A; Janet P = Gunn; DOLLY, MARTIN C
Cc: DiME; dime@ietf.org; = Pollini, Gregory P
Subject: Re: [Dime] [dime] #92 = (drmp): Range of priority levels
 
Assuming that we define = a range of 3 values,
Assuming that 0 is the lowest priority and 2 the highest,
Assuming that an agent receives 4 messages = at the same time while being in overload control:
=B7       1) ULR with Prio-0
=B7       2) ULR with Prio-1
=B7       3) ULR with Prio-2
=B7       4) ULR with no priority AVP
 
Assuming that the = default is locally defined as proposed below,
 
How do you know that = the ULR with priority 2 will be handled with a higher priority =  than the request without priority indication?
And what about ULR message with priority 1 = with two levels of highest priority e.g. emergency/Important and = government/very important?
 
Sorry if the answer is obvious but I fail = to understand.
 
Lionel
 
 
          &nb= sp;            = ;            &= nbsp;      
De : Shaikh, = Viqar A [mailto:vshaikh@appcomsci.com] 
Envoy=E9 : samedi 3 octobre 2015 = 01:21
=C0 : MORAND Lionel IMT/OLN; = Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; dime@ietf.org; Pollini, Gregory P
Objet : RE: [Dime] [dime] #92 = (drmp): Range of priority levels
 
Hello all,
 
Note that the 3GPP priority, e.g., = Priority-Level AVP (ARP AVP) in TS 29.212 takes 15 values, value 1 = the highest, 15 the lowest, and value 0 not defined.
 
Having 15 rather than 16 would be useful from an interworking = point of view on Diameter interfaces connecting to the EPS.  
 
Also, my understanding has been that the default value = is per local policy. 
 
My 2 cents....
Viqar 

From: DiME [dime-bounces@ietf.org] on behalf of lionel.morand@orange.com [lionel.morand@orange.com]
Sent: Thursday, October 01, 2015 = 3:36 AM
To: Janet P Gunn; DOLLY, MARTIN = C
Cc: DiME; dime@ietf.org
Subject: Re: [Dime] [dime] #92 = (drmp): Range of priority levels

Hi,
 
I think that the case "no Priority = indication in request" is the default situation today.
So = if we agree that it should be possible to explicitly indicate a request = with a lower priority, we should divide the range of priority values in = three sub-ranges: [lower priorities][no priority indication][higher = priorities], e.g. with 17 values: [0-7][8][9-16].
If = any operator can freely fix the default value, there would be no way to = ensure the sender that a request with a specific priority value (e.g. 6) = will be handled with a lower or higher priority than a request with no = priority indication.
 
Therefore, for a deterministic handling = mechanism, I think that it is then more relevant to define a standard = value for the default value.
 
Regards,
 
Lionel
 
 
De : DiME [mailto:dime-bounces@ietf.org] De la part = de Janet P Gunn
Envoy=E9 : mercredi 30 septembre 2015 = 22:53
=C0 : DOLLY, MARTIN C
Cc : DiME; dime@ietf.org
Objet : Re: [Dime] [dime] #92 = (drmp): Range of priority levels
 
Same here.  The "default priority" should be a matter of = local policy. 

Janet

This is a PRIVATE message. If you are not the intended = recipient, please delete without copying and kindly advise us by e-mail = of the mistake in delivery. NOTE: Regardless of content, this e-mail = shall not operate to bind CSC to any order or other contract unless = pursuant to explicit written agreement or government initiative = expressly permitting the use of e-mail for such purpose. 



From:       =  "DOLLY, MARTIN C" <md3135@att.com> 
To: =        Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org> 
Date:       =  09/30/2015 04:40 PM 
Subject:       =  Re: [Dime] [dime] #92 (drmp): Range of = priority levels 
Sent by:       =  "DiME" <dime-bounces@ietf.org>



Me as well 
  
From: DiME = [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Wednesday, September 30, = 2015 4:38 PM
To: dime@ietf.orgSubject: Re: [Dime] [dime] #92 = (drmp): Range of priority levels 
  
I'm okay with Jay's proposal on not specifying a default = value.

Steve 
On 9/30/15 3:27 PM, Lee, Jay wrote: 
Hi Steve and all, 
  
For the first proposal, as I indicated, I support increasing = the number of priority levels up to 16. 
  
I am also fine with the second proposal. My question is: do = we need to mandate this feature, as individual operators have different = situations? Perhaps some flexibility should be allowed? Instead of = mandating it, we can include the statement that when there is no DRMP = AVP, this correspond to =91normal traffic=92 without a particular high = or low priority. Then each operator can map this default to a value = (e.g., 8 or something else) that they feel appropriate. 
  
Thanks, 
  
Jay 



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

_______________________________________________________________=
__________________________________________________________
 
Ce message et ses pieces jointes =
peuvent contenir des informations confidentielles ou privilegiees et ne =
doivent donc
pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler
a =
l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message =
a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may =
contain confidential or privileged information that may be protected by =
law;
they should not be distributed, used =
or copied without authorisation.
If =
you have received this email in error, please notify the sender and =
delete this message and its attachments.
As emails may be altered, Orange is not liable =
for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________________________=
__________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des =
informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si =
vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. =
Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete =
altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or =
privileged information that may be protected by law;
they should not be distributed, used or copied without =
authorisation.
If you have received this email =
in error, please notify the sender and delete this message and its =
attachments.
As emails may be altered, Orange =
is not liable for messages that have been modified, changed or =
falsified.
Thank you.


_______________________________________________=

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

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

= --Apple-Mail=_5A5C7D72-E475-43F7-BA7E-301A3A96FD43-- From nobody Wed Oct 14 08:54:47 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB451ACCFB; Wed, 14 Oct 2015 08:54:44 -0700 (PDT) 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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzxbGe7I2BFc; Wed, 14 Oct 2015 08:54:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF951ACCDE; Wed, 14 Oct 2015 08:54:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.5.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151014155443.3836.20384.idtracker@ietfa.amsl.com> Date: Wed, 14 Oct 2015 08:54:43 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-agent-overload-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 15:54:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Agent Overload and the Peer Overload Report Author : Steve Donovan Filename : draft-ietf-dime-agent-overload-03.txt Pages : 18 Date : 2015-10-14 Abstract: This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC) base solution. The extension defines the Peer overload report type. The initial use case for the Peer report is the handling of occurrences of overload of a Diameter agent. Requirements The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-agent-overload-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-agent-overload-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 14 09:04:59 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1BE1ACD21; Wed, 14 Oct 2015 09:04:57 -0700 (PDT) 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=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUMM2KkH4C1P; Wed, 14 Oct 2015 09:04:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF1E1ACD1E; Wed, 14 Oct 2015 09:04:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.5.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151014160455.25390.7279.idtracker@ietfa.amsl.com> Date: Wed, 14 Oct 2015 09:04:55 -0700 Archived-At: Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-load-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 16:04:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF. Title : Diameter Load Information Conveyance Authors : Ben Campbell Steve Donovan Jean-Jacques Trottin Filename : draft-ietf-dime-load-01.txt Pages : 20 Date : 2015-10-14 Abstract: This document defines a mechanism for sharing of Diameter load information. RFC 7068 describes requirements for Overload Control in Diameter. This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. The Diameter Overload Information Conveyance (DOIC) solution describes a mechanism meeting most of the requirements, but does not currently include the ability to send load information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-load/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dime-load-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-load-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 14 09:34:45 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1C61A6FAA for ; Wed, 14 Oct 2015 09:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBPudqNwqJJz for ; Wed, 14 Oct 2015 09:34:36 -0700 (PDT) Received: from eris.verizonwireless.com (eris.verizonwireless.com [137.188.99.119]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFE11ACE53 for ; Wed, 14 Oct 2015 09:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizonwireless.com; i=@verizonwireless.com; q=dns/txt; s=prodmail; t=1444840114; x=1476376114; h=from:to:subject:date:references:in-reply-to:mime-version; bh=x0obThnlPiaohag7FPVPKn1ycEs0qSCBAUoAJpO0nLg=; b=kQKizr8vu7uUURmJRcw7yiKoVyos0pBUlAYNrNZSJqOUQO9IO9tIRH4D gqdA3m5kUjVofsNfCXuupFsQcXOIzDeZuSsoFGRyBBcJ1RKSCog1AGwUB DubUcFFhsqeavR+cO33VXg+UiGbdH0Nb0ubm/JDwxswdfEBB2KAiQ+BRg A=; X-Host: mariner.tdc.vzwcorp.com Received: from casac1exh001.uswin.ad.vzwcorp.com ([10.11.218.43]) by eris.verizonwireless.com with ESMTP/TLS/AES128-SHA; 14 Oct 2015 12:28:32 -0400 Received: from CASAC1EXP009.uswin.ad.vzwcorp.com ([fe80::558c:d7cc:1a42:f4d6]) by CASAC1EXH001.uswin.ad.vzwcorp.com ([::1]) with mapi id 14.03.0146.000; Wed, 14 Oct 2015 09:28:31 -0700 From: "Lee, Jay" To: Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] [dime] #92 (drmp): Range of priority levels Thread-Index: AQHQ+7/7gjQt6THBK0qRj4pp4rg/GJ5VZy8AgAADsACAAM9WwIACfqKAgBDpAPCAAXt4FoAAJNmQ Date: Wed, 14 Oct 2015 16:28:30 +0000 References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> <20151014075941.062E21B2C1F@ietfa.amsl.com> <09aed55e-b53b-4da8-a2f4-ca40ef1848cd@CASAC1EXH002.uswin.ad.vzwcorp.com> In-Reply-To: <09aed55e-b53b-4da8-a2f4-ca40ef1848cd@CASAC1EXH002.uswin.ad.vzwcorp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.11.60.250] Content-Type: multipart/alternative; boundary="_000_C026C31E3CD6CA43953D6D95AB48048001ABF5CASAC1EXP009uswin_" MIME-Version: 1.0 Message-Id: <20151014162834.1EFE11ACE53@ietfa.amsl.com> Archived-At: Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2015 16:34:44 -0000 --_000_C026C31E3CD6CA43953D6D95AB48048001ABF5CASAC1EXP009uswin_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Steve, Your suggestion on adding 'Note' is okay with me. It certainly helps and ma= kes things clearer. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, October 14, 2015 7:12 AM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Jay, The current text is a SHOULD level requirement: When there is a mix of transactions specifying priority in request messages and transactions that do not have the priority specified, transactions that do not have a specified priority SHOULD be treated as having the PRIORITY_14 priority. As such, operators can choose to either not implement a priority or define = a different value for their network. I propose adding the following note after this paragraph to further explain= why it is a SHOULD and not a MUST: Note: There are scenarios where operators might want to specify a different default value for transactions that do not have an explicit priority. In this case, the operator defined local policy would override the use of PRIORITY_14 as the default priority. This leaves the ability for there to be deterministic behavior in Diameter = networks that require a default to be defined and are happy with the specif= ied default. It also gives operators the ability to define a different beh= avior, most likely with some priority handling/mapping at the edge of the n= etwork. Does this address your concerns? Regards, Steve On 10/14/15 2:59 AM, Lee, Jay wrote: Regarding the issue of whether we need to specify a default value or not, t= here are pros and cons. If we specify a value for the default case, we can see the benefits in scen= arios between different operator networks, but we take away important optio= ns on what operators can do with priority values. On the other hand, if we = do not specify the default value, operators may have more options, but ther= e is a question of what to do for this inter-PLMN cases when the networks m= ay use different default values. In practice, this issue can be addressed at the edge of the network, where = Diameter edge agent (DEA) can perform some priority mapping based on bilate= ral roaming agreement (or SLA (service level agreement)) and other means to= insure the proper handling. One may argue that this is not as good as the = 'deterministic' case, but operator should be able handle this in a reasonab= le way. We are fully aware of the fact that, in case of this 'non-determini= stic' case, the default value can differ from one operator network to anoth= er, and it becomes difficult to guarantee the intended priority handling. D= espite this, we still prefer giving options to operators by not specifying = the default value. What we are saying here, however, is not anything new. This is the typical = way of handling priority levels. If anything, specifying the default value = would be something new. As already mentioned in CT discussion, there is a g= ood example of this - Internet QoS, more specifically DiffServ. In order to guarantee end-to-end QoS for a specific service, IETF could hav= e specified a value (DiffServ codepoint) for the specific service to have p= redetermined handling of the traffic, but IETF did not. Instead, DiffServ s= imply provided a framework for operators to have its own classification an= d differentiated treatment of the services. To guarantee end-to-end QoS acr= oss different networks, then, operators need to do packet inspection, (re)c= lassification, QoS mapping, use of SLA and possibly others at the edge of n= etwork (edge router). Therefore, in the DiffServ architecture, intelligence= was pushed to the edge of the network. While the end results may not be gu= aranteed as well as in the case of predetermined handling, it was still a p= referred way to give flexibility to operators. My point is that we went thr= ough all these troubles to give options of priority handling to operators. By the way, if we are thinking of possibility of specifying the default val= ue, are we assuming that all operators are interested in this feature (defa= ult value in the middle, and high and low priorities at other ends)? Aren't= there other operators who are not interested in this feature? I know that = at least there is one - Verizon. We have no interest in this feature, and n= o plan for implementing it. We are OK, if other operators are interested in= this feature, and the default value is NOT specified. But we are certainly= not happy if DIME is trying to impose this on us. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, October 13, 2015 10:55 AM To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org; Pollini, Gregory P Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Assuming that we define a range of 3 values, Assuming that 0 is the lowest priority and 2 the highest, Assuming that an agent receives 4 messages at the same time while being in = overload control: =B7 1) ULR with Prio-0 =B7 2) ULR with Prio-1 =B7 3) ULR with Prio-2 =B7 4) ULR with no priority AVP Assuming that the default is locally defined as proposed below, How do you know that the ULR with priority 2 will be handled with a higher = priority than the request without priority indication? And what about ULR message with priority 1 with two levels of highest prior= ity e.g. emergency/Important and government/very important? Sorry if the answer is obvious but I fail to understand. Lionel De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] Envoy=E9 : samedi 3 octobre 2015 01:21 =C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C Cc : DiME; dime@ietf.org; Pollini, Gregory P Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels Hello all, Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.21= 2 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defi= ned. Having 15 rather than 16 would be useful from an interworking point of view= on Diameter interfaces connecting to the EPS. Also, my understanding has been that the default value is per local policy. My 2 cents.... Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf = of lionel.morand@orange.com [lionel.morand= @orange.com] Sent: Thursday, October 01, 2015 3:36 AM To: Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Hi, I think that the case "no Priority indication in request" is the default si= tuation today. So if we agree that it should be possible to explicitly indicate a request = with a lower priority, we should divide the range of priority values in thr= ee sub-ranges: [lower priorities][no priority indication][higher priorities= ], e.g. with 17 values: [0-7][8][9-16]. If any operator can freely fix the default value, there would be no way to = ensure the sender that a request with a specific priority value (e.g. 6) wi= ll be handled with a lower or higher priority than a request with no priori= ty indication. Therefore, for a deterministic handling mechanism, I think that it is then = more relevant to define a standard value for the default value. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn Envoy=E9 : mercredi 30 septembre 2015 22:53 =C0 : DOLLY, MARTIN C Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels Same here. The "default priority" should be a matter of local policy. Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "DOLLY, MARTIN C" > To: Steve Donovan >, "dime@ietf.org" > Date: 09/30/2015 04:40 PM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" = > ________________________________ Me as well From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, September 30, 2015 4:38 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels I'm okay with Jay's proposal on not specifying a default value. Steve On 9/30/15 3:27 PM, Lee, Jay wrote: Hi Steve and all, For the first proposal, as I indicated, I support increasing the number of = priority levels up to 16. I am also fine with the second proposal. My question is: do we need to mand= ate this feature, as individual operators have different situations? Perhap= s some flexibility should be allowed? Instead of mandating it, we can inclu= de the statement that when there is no DRMP AVP, this correspond to 'normal= traffic' without a particular high or low priority. Then each operator can= map this default to a value (e.g., 8 or something else) that they feel app= ropriate. Thanks, Jay _______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_C026C31E3CD6CA43953D6D95AB48048001ABF5CASAC1EXP009uswin_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Steve,<= /p>

 <= /p>

Your suggestion on adding= ‘Note’ is okay with me. It certainly helps and makes things cl= earer.

 <= /p>

Jay

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Wednesday, October 14, 2015 7:12 AM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels=

 

Jay,

The current text is a SHOULD level requirement:

   When there is a mix of transactions specifying priority in req= uest
   messages and transactions that do not have the priority specif= ied,
   transactions that do not have a specified priority SHOULD be t= reated
   as having the PRIORITY_14 priority.

As such, operators can choose to either not implement a priority or define = a different value for their network.

I propose adding the following note after this paragraph to further explain= why it is a SHOULD and not a MUST:

      Note: There are scenarios where operators mi= ght want to
      specify a different default value for transa= ctions that do not
      have an explicit priority.  In this cas= e, the operator defined
      local policy would override the use of PRIOR= ITY_14 as
      the default priority.

This leaves the ability for there to be deterministic behavior in Diameter = networks that require a default to be defined and are happy with the specif= ied default.  It also gives operators the ability to define a differen= t behavior, most likely with some priority handling/mapping at the edge of the network.

Does this address your concerns?

Regards,

Steve

On 10/14/15 2:59 AM, Lee, Jay wrote:

Regarding the issue of wh= ether we need to specify a default value or not, there are pros and cons.

 <= /p>

If we specify a value for= the default case, we can see the benefits in scenarios between different o= perator networks, but we take away important options on what operators can do with priority values. On the other hand, if we do no= t specify the default value, operators may have more options, but there is = a question of what to do for this inter-PLMN cases when the networks may us= e different default values.

 <= /p>

In practice, this issue c= an be addressed at the edge of the network, where Diameter edge agent (DEA)= can perform some priority mapping based on bilateral roaming agreement (or SLA (service level agreement)) and other means to insure the= proper handling. One may argue that this is not as good as the ‘dete= rministic’ case, but operator should be able handle this in a reasona= ble way. We are fully aware of the fact that, in case of this ‘non-deterministic’ case, the default value ca= n differ from one operator network to another, and it becomes difficult to = guarantee the intended priority handling. Despite this, we still prefer giv= ing options to operators by not specifying the default value.

 <= /p>

What we are saying here, = however, is not anything new. This is the typical way of handling priority = levels. If anything, specifying the default value would be something new. As already mentioned in CT discussion, there is a good e= xample of this – Internet QoS, more specifically DiffServ.

 <= /p>

In order to guarantee end= -to-end QoS for a specific service, IETF could have specified a value (Diff= Serv codepoint) for the specific service to have predetermined handling of the traffic, but IETF did not. Instead, DiffServ simply provid= ed a framework for operators to have its own  classification and diffe= rentiated treatment of the services. To guarantee end-to-end QoS across dif= ferent networks, then, operators need to do packet inspection, (re)classification, QoS mapping, use of SLA and p= ossibly others at the edge of network (edge router). Therefore, in the Diff= Serv architecture, intelligence was pushed to the edge of the network. Whil= e the end results may not be guaranteed as well as in the case of predetermined handling, it was still a preferred= way to give flexibility to operators. My point is that we went through all= these troubles to give options of priority handling to operators.

 <= /p>

By the way, if we are thi= nking of possibility of specifying the default value, are we assuming that = all operators are interested in this feature (default value in the middle, and high and low priorities at other ends)? Aren’t th= ere other operators who are not interested in this feature? I know that at = least there is one – Verizon. We have no interest in this feature, an= d no plan for implementing it. We are OK, if other operators are interested in this feature, and the default value is N= OT specified. But we are certainly not happy if DIME is trying to impose th= is on us.

 <= /p>

Jay

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.mora= nd@orange.com
Sent: Tuesday, October 13, 2015 10:55 AM
To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; dime@ietf.org; Pollin= i, Gregory P
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels

 

Assuming that we define a= range of 3 values,

Assuming that 0 is the lo= west priority and 2 the highest,

Assuming that an agent re= ceives 4 messages at the same time while being in overload control:

=B7       1) ULR with Prio-= 0

=B7       2) ULR with Prio-= 1

=B7       3) ULR with Prio-= 2

=B7       4) ULR with no pr= iority AVP

 <= /p>

Assuming that the default= is locally defined as proposed below,

 <= /p>

How do you know that the = ULR with priority 2 will be handled with a higher priority  than the r= equest without priority indication?

And what about ULR messag= e with priority 1 with two levels of highest priority e.g. emergency/Import= ant and government/very important?

 <= /p>

Sorry if the answer is ob= vious but I fail to understand.

 <= /p>

Lionel<= /p>

 <= /p>

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;

De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com]
Envoy=E9 : samedi 3 octobre 2015 01:21
=C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; dime@ietf.org; = Pollini, Gregory P
Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels<= /span>

 

Hello all,

 

Note that the 3GPP prio= rity, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 takes 15 values,= value 1 the highest, 15 the lowest, and value 0 not defined.

 

Having 15 rather than 16 wou= ld be useful from an interworking point of view on Diameter interfaces conn= ecting to the EPS.  

 

Also, my understanding has b= een that the default value is per local policy. 

 

My 2 cents....

Viqar 

From: DiME [dime-bounces@ietf.org] on behalf of lionel.morand@ora= nge.com [lionel.morand@oran= ge.com]
Sent: Thursday, October 01, 2015 3:36 AM
To: Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels

Hi,

 

I think that the case &qu= ot;no Priority indication in request" is the default situation today.<= /span>

So if we agree that it sh= ould be possible to explicitly indicate a request with a lower priority, we= should divide the range of priority values in three sub-ranges: [lower priorities][no priority indication][higher priorities], e.g. with 1= 7 values: [0-7][8][9-16].

If any operator can freel= y fix the default value, there would be no way to ensure the sender that a = request with a specific priority value (e.g. 6) will be handled with a lower or higher priority than a request with no priority in= dication.

 

Therefore, for a determin= istic handling mechanism, I think that it is then more relevant to define a= standard value for the default value.

 

Regards,

 

Lionel<= /p>

 

 

De : DiME [mailto:d= ime-bounces@ietf.org] De la part de Janet P Gunn
Envoy=E9 : mercredi 30 septembre 2015 22:53
=C0 : DOLLY, MARTIN C
Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels<= /span>

 

Same here.  The "de= fault priority" should be a matter of local policy.

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose.



From:        = ;"DOLLY, MARTIN C" <md3135@att.com>
To:        <= /span>Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org= " <dime@ietf.org= >
Date:        = ;09/30/2015 04:40 PM
Subject:       &n= bsp;Re: [Dime] [dime] #92 (drmp): Range of pri= ority levels
Sent by:       &n= bsp;"DiME" <dime-bounces@ietf.org><= span lang=3D"FR">



Me as well
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Wednesday, September 30, 2015 4:38 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels<= span lang=3D"FR">
 
I'm okay with Jay's proposal on not specify= ing a default value.

Steve
On 9/30/15 3:27 PM, Lee, Jay wrote:<= span lang=3D"FR">
Hi Steve and all,
 
For the first proposal, as I indicated, I s= upport increasing the number of priority levels up to 16.
 
I am also fine with the second proposal. My= question is: do we need to mandate this feature, as individual operators h= ave different situations? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that whe= n there is no DRMP AVP, this correspond to ‘normal traffic’ wit= hout a particular high or low priority. Then each operator can map this def= ault to a value (e.g., 8 or something else) that they feel appropriate.
 
Thanks,
 
Jay



_______________________________= ________________
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/d= ime

____________________________________________________=
_____________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
o:p>
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
o:p>
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
o:p>
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
o:p>
Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;
they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.











_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime

 

--_000_C026C31E3CD6CA43953D6D95AB48048001ABF5CASAC1EXP009uswin_-- From nobody Wed Oct 14 14:14:19 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AC51A8974; Wed, 14 Oct 2015 14:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLBMQ6kI05Qs; Wed, 14 Oct 2015 14:14:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 914E61A8958; Wed, 14 Oct 2015 14:14:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 70C45180478; Wed, 14 Oct 2015 14:13:57 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20151014211357.70C45180478@rfc-editor.org> Date: Wed, 14 Oct 2015 14:13:57 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] RFC 7660 on Diameter Congestion and Filter Attributes X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 14 Oct 2015 21:14:15 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7660 Title: Diameter Congestion and Filter Attributes Author: L. Bertz, S. Manning, B. Hirschman Status: Standards Track Stream: IETF Date: October 2015 Mailbox: lyleb551144@gmail.com, sergem913@gmail.com, Brent.Hirschman@gmail.com Pages: 9 Characters: 18830 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dime-congestion-flow-attributes-02.txt URL: https://www.rfc-editor.org/info/rfc7660 DOI: http://dx.doi.org/10.17487/RFC7660 This document defines optional Diameter attributes that can be used to help manage networks that use Explicit Congestion Notification (ECN) or Diameter traffic filters. These new attributes allow for improved data traffic identification, support of ECN, and minimal Diameter filter administration. RFC 5777 defines a Filter-Rule Attribute Value Pair (AVP) that accommodates extensions for classification, conditions, and actions. It, however, does not support traffic identification for packets using Explicit Congestion Notification as defined in RFC 3168 and does not provide specific actions when the flow(s) described by the Filter-Rule are congested. Further, a Filter-Rule can describe multiple flows but not the exact number of flows. Flow count and other associated data (e.g., packets) are not captured by accounting applications, leaving administrators without useful information regarding the effectiveness or appropriateness of the filter definition. The optional attributes defined in this document are forward and backwards compatible with RFC 5777. This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Oct 15 03:16:10 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5DE1ACD7A for ; Thu, 15 Oct 2015 03:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYeHrtwvj7Bc for ; Thu, 15 Oct 2015 03:15:58 -0700 (PDT) Received: from eris.verizonwireless.com (eris.verizonwireless.com [137.188.99.119]) by ietfa.amsl.com (Postfix) with ESMTP id 111761ACD5C for ; Thu, 15 Oct 2015 03:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizonwireless.com; i=@verizonwireless.com; q=dns/txt; s=prodmail; t=1444904158; x=1476440158; h=from:to:cc:subject:date:references:in-reply-to: mime-version; bh=6fnHTQG310AVsl8v2jXFjUUvoA4XsPevLuHv1GSyMXU=; b=BJGKJiw4Mnhgm0uQPCy9FpaFO6QYdMaUcFs9EwjIQ94uqo39K18KNbvv pGyKw6tsKPbtFrXgZkbXb20ZaOWtjx8Euswu6yojzemnXvbEF+nbFR+eP 4CWvdj7IKppye0oPmq39zNyuA/pmCO3jw3L82fMhUboctKIAhA+Qq2GLI E=; X-Host: mariner.tdc.vzwcorp.com Received: from casac1exh001.uswin.ad.vzwcorp.com ([10.11.218.43]) by eris.verizonwireless.com with ESMTP/TLS/AES128-SHA; 15 Oct 2015 06:15:53 -0400 Received: from CASAC1EXP009.uswin.ad.vzwcorp.com ([fe80::558c:d7cc:1a42:f4d6]) by CASAC1EXH001.uswin.ad.vzwcorp.com ([::1]) with mapi id 14.03.0146.000; Thu, 15 Oct 2015 03:15:52 -0700 From: "Lee, Jay" To: ken carlberg , Steve Donovan Thread-Topic: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) Thread-Index: AQHRBpaWvZHMk32YW0eUkHJNgMq6SZ5sUyAA Date: Thu, 15 Oct 2015 10:15:51 +0000 References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> <20151014075941.062E21B2C1F@ietfa.amsl.com> <561E62C9.20500@usdonovans.com> <1431d0b2-5ae7-426e-b5ff-42b23fecbee5@CASAC1EXH002.uswin.ad.vzwcorp.com> In-Reply-To: <1431d0b2-5ae7-426e-b5ff-42b23fecbee5@CASAC1EXH002.uswin.ad.vzwcorp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.11.60.250] Content-Type: multipart/alternative; boundary="_000_C026C31E3CD6CA43953D6D95AB48048001B640CASAC1EXP009uswin_" MIME-Version: 1.0 Message-Id: <20151015101558.111761ACD5C@ietfa.amsl.com> Archived-At: Cc: "dime@ietf.org" Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2015 10:16:09 -0000 --_000_C026C31E3CD6CA43953D6D95AB48048001B640CASAC1EXP009uswin_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >From my side, some more discussion on Steve's mail may be needed. 'Should' vs. 'Must': One can say that 'Should' is not mandatory. But, in practice, this is a fai= rly strong statement, and often taken as required. So in this sense, the pr= oposed Note is certainly helpful. But, since we allow operators to override= the value, I don't see the reason why we use 'Should'. My suggestion is us= ing 'May'. PRIORITY_14 priority: Since operators can overwrite it, I was not too concerned about it. But if = we want to put some value, why '14'? A value lower than 14 is suggested in = order to allow more rooms for lower priorities. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg Sent: Wednesday, October 14, 2015 8:40 AM To: Steve Donovan Cc: dime@ietf.org Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): R= ange of priority levels) with respect to the diff-serv example brought up below, some thing to add t= o that discussion is that it starts off with separate and distinct forwardi= ng behavior whose marked packets provide segmentation of other IP traffic. = The availability of only 6 bits to play with (along with the headaches of = transitive trust) also discouraged a line of thought to define end-to-end p= riority handling versus a per diff-serv domain treatment. RFC-4594 did pro= vide configuration guidelines, but that's a different story. So back to a couple of ideas to consider. 1) reserved space. if we go back to the diff-serv model, the diff-serv wor= king group agreed to set aside a set of values that was reserved for experi= mental use that could be re-assigned some time in the future. I'm not sugg= esting that there should be space set side for experiments, but rather it m= ay be prudent to set aside a reserved set of bits/values so that one doesn'= t need to define a new AVP if in the future there was a need to define adde= d values beyond the 5 (plus some fudge factor) already mentioned on the lis= t. 2) sets of users. previous work (e.g., rfc-4412, rfc-6710) recognized that= there can be several sets of users/services that are distinct from each ot= her and yet need to prioritize the traffic. I bring this up because the dr= aft already identifies two sets of users in sections 5.1 and 5.2 (note: I'm= assuming that the latter is aimed at the general public and related to 911= /112/999 type calls, which should probably be more specific in the draft). = And there is also the potential of Firstnet users in the US. As a side note, the distinction and separation of general public and other = prioritized users in public phone infrastructures is not exclusive to the U= S, so the group should not be concerned that this is a US centric effort. = There has been GTPS in the UK, as well as other systems in other countries.= The RFC is a bit dated, but feel free to go over rfc-4190 for added backg= round. and just to reiterate. I'm not making recommendations in the above - just = bringing up some food for thought. -ken On Oct 14, 2015, at 10:12 AM, Steve Donovan > wrote: Jay, The current text is a SHOULD level requirement: When there is a mix of transactions specifying priority in request messages and transactions that do not have the priority specified, transactions that do not have a specified priority SHOULD be treated as having the PRIORITY_14 priority. As such, operators can choose to either not implement a priority or define = a different value for their network. I propose adding the following note after this paragraph to further explain= why it is a SHOULD and not a MUST: Note: There are scenarios where operators might want to specify a different default value for transactions that do not have an explicit priority. In this case, the operator defined local policy would override the use of PRIORITY_14 as the default priority. This leaves the ability for there to be deterministic behavior in Diameter = networks that require a default to be defined and are happy with the specif= ied default. It also gives operators the ability to define a different beh= avior, most likely with some priority handling/mapping at the edge of the n= etwork. Does this address your concerns? Regards, Steve On 10/14/15 2:59 AM, Lee, Jay wrote: Regarding the issue of whether we need to specify a default value or not, t= here are pros and cons. If we specify a value for the default case, we can see the benefits in scen= arios between different operator networks, but we take away important optio= ns on what operators can do with priority values. On the other hand, if we = do not specify the default value, operators may have more options, but ther= e is a question of what to do for this inter-PLMN cases when the networks m= ay use different default values. In practice, this issue can be addressed at the edge of the network, where = Diameter edge agent (DEA) can perform some priority mapping based on bilate= ral roaming agreement (or SLA (service level agreement)) and other means to= insure the proper handling. One may argue that this is not as good as the = 'deterministic' case, but operator should be able handle this in a reasonab= le way. We are fully aware of the fact that, in case of this 'non-determini= stic' case, the default value can differ from one operator network to anoth= er, and it becomes difficult to guarantee the intended priority handling. D= espite this, we still prefer giving options to operators by not specifying = the default value. What we are saying here, however, is not anything new. This is the typical = way of handling priority levels. If anything, specifying the default value = would be something new. As already mentioned in CT discussion, there is a g= ood example of this - Internet QoS, more specifically DiffServ. In order to guarantee end-to-end QoS for a specific service, IETF could hav= e specified a value (DiffServ codepoint) for the specific service to have p= redetermined handling of the traffic, but IETF did not. Instead, DiffServ s= imply provided a framework for operators to have its own classification an= d differentiated treatment of the services. To guarantee end-to-end QoS acr= oss different networks, then, operators need to do packet inspection, (re)c= lassification, QoS mapping, use of SLA and possibly others at the edge of n= etwork (edge router). Therefore, in the DiffServ architecture, intelligence= was pushed to the edge of the network. While the end results may not be gu= aranteed as well as in the case of predetermined handling, it was still a p= referred way to give flexibility to operators. My point is that we went thr= ough all these troubles to give options of priority handling to operators. By the way, if we are thinking of possibility of specifying the default val= ue, are we assuming that all operators are interested in this feature (defa= ult value in the middle, and high and low priorities at other ends)? Aren't= there other operators who are not interested in this feature? I know that = at least there is one - Verizon. We have no interest in this feature, and n= o plan for implementing it. We are OK, if other operators are interested in= this feature, and the default value is NOT specified. But we are certainly= not happy if DIME is trying to impose this on us. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, October 13, 2015 10:55 AM To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org; Pollini, Gregory P Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Assuming that we define a range of 3 values, Assuming that 0 is the lowest priority and 2 the highest, Assuming that an agent receives 4 messages at the same time while being in = overload control: * 1) ULR with Prio-0 * 2) ULR with Prio-1 * 3) ULR with Prio-2 * 4) ULR with no priority AVP Assuming that the default is locally defined as proposed below, How do you know that the ULR with priority 2 will be handled with a higher = priority than the request without priority indication? And what about ULR message with priority 1 with two levels of highest prior= ity e.g. emergency/Important and government/very important? Sorry if the answer is obvious but I fail to understand. Lionel De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] Envoy=E9 : samedi 3 octobre 2015 01:21 =C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C Cc : DiME; dime@ietf.org; Pollini, Gregory P Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels Hello all, Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.21= 2 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defi= ned. Having 15 rather than 16 would be useful from an interworking point of view= on Diameter interfaces connecting to the EPS. Also, my understanding has been that the default value is per local policy. My 2 cents.... Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf = of lionel.morand@orange.com [lionel.morand= @orange.com] Sent: Thursday, October 01, 2015 3:36 AM To: Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Hi, I think that the case "no Priority indication in request" is the default si= tuation today. So if we agree that it should be possible to explicitly indicate a request = with a lower priority, we should divide the range of priority values in thr= ee sub-ranges: [lower priorities][no priority indication][higher priorities= ], e.g. with 17 values: [0-7][8][9-16]. If any operator can freely fix the default value, there would be no way to = ensure the sender that a request with a specific priority value (e.g. 6) wi= ll be handled with a lower or higher priority than a request with no priori= ty indication. Therefore, for a deterministic handling mechanism, I think that it is then = more relevant to define a standard value for the default value. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn Envoy=E9 : mercredi 30 septembre 2015 22:53 =C0 : DOLLY, MARTIN C Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels Same here. The "default priority" should be a matter of local policy. Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "DOLLY, MARTIN C" > To: Steve Donovan >, "dime@ietf.org" > Date: 09/30/2015 04:40 PM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" = > ________________________________ Me as well From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, September 30, 2015 4:38 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels I'm okay with Jay's proposal on not specifying a default value. Steve On 9/30/15 3:27 PM, Lee, Jay wrote: Hi Steve and all, For the first proposal, as I indicated, I support increasing the number of = priority levels up to 16. I am also fine with the second proposal. My question is: do we need to mand= ate this feature, as individual operators have different situations? Perhap= s some flexibility should be allowed? Instead of mandating it, we can inclu= de the statement that when there is no DRMP AVP, this correspond to 'normal= traffic' without a particular high or low priority. Then each operator can= map this default to a value (e.g., 8 or something else) that they feel app= ropriate. Thanks, Jay _______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_C026C31E3CD6CA43953D6D95AB48048001B640CASAC1EXP009uswin_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

From my side, some more d= iscussion on Steve’s mail may be needed.

 <= /p>

‘Should’ vs. = ‘Must’:

One can say that ‘S= hould’ is not mandatory. But, in practice, this is a fairly strong st= atement, and often taken as required. So in this sense, the proposed Note is certainly helpful. But, since we allow operators to override the v= alue, I don’t see the reason why we use ‘Should’. My sugg= estion is using ‘May’.

 <= /p>

PRIORITY_14 priority:

Since operators can overw= rite it, I was not too concerned about it. But if we want to put some value= , why ‘14’? A value lower than 14 is suggested in order to allow more rooms for lower priorities.

 <= /p>

Jay

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of ken carlberg
Sent: Wednesday, October 14, 2015 8:40 AM
To: Steve Donovan
Cc: dime@ietf.org
Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (d= rmp): Range of priority levels)

 

with respect to the diff-serv example brought up bel= ow, some thing to add to that discussion is that it starts off with separat= e and distinct forwarding behavior whose marked packets provide segmentatio= n of other IP traffic.  The availability of only 6 bits to play with (along with the headaches of transitive trust)= also discouraged a line of thought to define end-to-end priority handling = versus a per diff-serv domain treatment.  RFC-4594 did provide configu= ration guidelines, but that’s a different story.

 

So back to a couple of ideas to consider.=

 

1) reserved space.  if we go back to the diff-s= erv model, the diff-serv working group agreed to set aside a set of values = that was reserved for experimental use that could be re-assigned some time = in the future.  I’m not suggesting that there should be space set side for experiments, but rather it may be prude= nt to set aside a reserved set of bits/values so that one doesn't need to d= efine a new AVP if in the future there was a need to define added values be= yond the 5 (plus some fudge factor) already mentioned on the list. 

 

2) sets of users.  previous work (e.g., rfc-441= 2, rfc-6710) recognized that there can be several sets of users/services th= at are distinct from each other and yet need to prioritize the traffic. &nb= sp;I bring this up because the draft already identifies two sets of users in sections 5.1 and 5.2 (note: I’m assu= ming that the latter is aimed at the general public and related to 911/112/= 999 type calls, which should probably be more specific in the draft).  = ;And there is also the potential of Firstnet users in the US.

 

As a side note, the distinction and separation of ge= neral public and other prioritized users in public phone infrastructures is= not exclusive to the US, so the group should not be concerned that this is= a US centric effort.  There has been GTPS in the UK, as well as other systems in other countries.  The RFC= is a bit dated, but feel free to go over rfc-4190 for added background.

 

and just to reiterate.  I’m not making re= commendations in the above — just bringing up some food for thought.<= o:p>

 

-ken

 

 

On Oct 14, 2015, at 10:12 AM, Steve Donovan <srdonovan@usdonovans.com> wr= ote:

 

Jay,

The current text is a SHOULD level require= ment:

   When there is a mix of transa= ctions specifying priority in request
   messages and transactions tha= t do not have the priority specified,
   transactions that do not have= a specified priority SHOULD be treated
   as having the PRIORITY_14 pri= ority.

As such, operators can choose to either no= t implement a priority or define a different value for their network.

I propose adding the following note after = this paragraph to further explain why it is a SHOULD and not a MUST:=

      Note: There= are scenarios where operators might want to 
      specify a d= ifferent default value for transactions that do not
      have an exp= licit priority.  In this case, the operator defined
      local polic= y would override the use of PRIORITY_14 as
      the default= priority.

This leaves the ability for there to be de= terministic behavior in Diameter networks that require a default to be defi= ned and are happy with the specified default.  It also gives operators= the ability to define a different behavior, most likely with some priority handling/mapping at the edge of the network= .

Does this address your concerns?
Regards,

Steve

On 10/14/15= 2:59 AM, Lee, Jay wrote:

From: DiME [mai= lto:dime-bounces@ietf.org]=  On Behalf Of lionel.morand@orange.com
Sent: Tuesday, Oct= ober 13, 2015 10:55 AM
To: Shaikh, Viqar = A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; = dime@ietf.org; Pollini, Gregory P Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 

=B7     &nbs= p; 1) ULR with Prio-0

=B7     &nbs= p; 2) ULR with Prio-1

=B7     &nbs= p; 3) ULR with Prio-2

=B7     &nbs= p; 4) ULR with no priority AVP

De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] 
Envoy=E9 : sa= medi 3 octobre 2015 01:21
=C0 : MORAND = Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; dime@ietf.org; Pollini, Grego= ry P
Objet : RE: [= Dime] [dime] #92 (drmp): Range of priority levels

 <= /span>

Hello all,

 

Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS= 29.212 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined.

 

Having 15 rather than 16 would be useful from an interworking point of vie= w on Diameter interfaces connecting to the EPS.  

 

Also, my understanding has been that the default value is per local p= olicy. 

 

My 2 cents....

Viqar 

<= span lang=3D"FR" style=3D"font-size:10.0pt;font-family:"Tahoma",&= quot;sans-serif"">From: DiME [dim= e-bounces@ietf.org] on behalf of lionel.morand@orange.com [<= span style=3D"color:purple">lionel.morand@orange.com]
Sent: Thursday, Oc= tober 01, 2015 3:36 AM
To: Janet P Gunn; = DOLLY, MARTIN C
Cc: DiME; = dime@ietf.org
Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

De : DiME [mai= lto:dime-bounces@ietf.org]=  De la part de&nbs= p;Janet P Gunn
Envoy=E9 : me= rcredi 30 septembre 2015 22:53
=C0 : DOLLY, = MARTIN C
Cc : DiME; dime@ietf.org
Objet : Re: [= Dime] [dime] #92 (drmp): Range of priority levels

 <= /span>

= Same here.  The "default priority" should be a matter of loc= al policy.&n= bsp;

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose. 



From:        = ;"DOLLY, MARTIN C" <md3135@att.com= > 
To:        <= /span>Steve Donovan <srdonovan@usdonovans.com= >, "dime@ietf.org" <dime@ietf.org> <= /span>
Date:        = ;09/30/2015 04:40 PM =
Subject:       &n= bsp;Re: [Dime] [dime] #92 (drmp): Range of pri= ority levels=  
Sent by:       &n= bsp;"DiME" <dime-bou= nces@ietf.org>




Me as well 
  
From: DiME [mailto:dime-bounces@ietf.org]&n= bsp;On Behalf Of Steve Dono= van
Sent: Wednesday, Sept= ember 30, 2015 4:38 PM
To: dime@ietf.or= g
Subject: Re: [Dime] [= dime] #92 (drmp): Range of priority levels 
  
I'm okay with Jay's proposal on not specify= ing a default value.

Steve <= /span>
On 9/30/15 3:27 PM, Lee, Jay wrote:<= span class=3D"apple-converted-space"> =
Hi Steve and all, =
  
For the first proposal, as I indicated, I s= upport increasing the number of priority levels up to 16. 
  
I am also fine with the second proposal. My= question is: do we need to mandate this feature, as individual operators h= ave different situations? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that whe= n there is no DRMP AVP, this correspond to ‘normal traffic’ wit= hout a particular high or low priority. Then each operator can map this def= ault to a value (e.g., 8 or something else) that they feel appropriate. 
  
Thanks, 
  
Jay 



_______________________= ________________________ 
DiME mailing list 
DiME@ietf.org 
https://www.ietf.org/mailman/li= stinfo/dime   _____________= __________________________________
DiME mailing list
DiME@ietf.org<= /span>
https://ww= w.ietf.org/mailman/listinfo/dime

_________________________=
___________________________________________________________________________=
_____________________
 <=
/pre>

Ce message et ses pieces =
jointes peuvent contenir des informations confidentielles ou privilegiees e=
t ne doivent donc


pas etre diffuses, exploi=
tes ou copies sans autorisation. Si vous avez recu ce message par erreur, v=
euillez le signaler


a l'expediteur et le detr=
uire ainsi que les pieces jointes. Les messages electroniques etant suscept=
ibles d'alteration,


Orange decline toute resp=
onsabilite si ce message a ete altere, deforme ou falsifie. Merci.


 <=
/pre>

This message and its atta=
chments may contain confidential or privileged information that may be prot=
ected by law;


they should not be distri=
buted, used or copied without authorisation.


If you have received this=
 email in error, please notify the sender and delete this message and its a=
ttachments.


As emails may be altered,=
 Orange is not liable for messages that have been modified, changed or fals=
ified.


Thank you.


_________________________=
___________________________________________________________________________=
_____________________
 <=
/pre>

Ce message et ses pieces =
jointes peuvent contenir des informations confidentielles ou privilegiees e=
t ne doivent donc


pas etre diffuses, exploi=
tes ou copies sans autorisation. Si vous avez recu ce message par erreur, v=
euillez le signaler


a l'expediteur et le detr=
uire ainsi que les pieces jointes. Les messages electroniques etant suscept=
ibles d'alteration,


Orange decline toute resp=
onsabilite si ce message a ete altere, deforme ou falsifie. Merci.


 <=
/pre>

This message and its atta=
chments may contain confidential or privileged information that may be prot=
ected by law;


they should not be distri=
buted, used or copied without authorisation.


If you have received this=
 email in error, please notify the sender and delete this message and its a=
ttachments.


As emails may be altered,=
 Orange is not liable for messages that have been modified, changed or fals=
ified.


Thank you.











___________________________________________=
____


DiME mailing list


DiME@ietf.org


https://www.ietf.org/mailman/listi=
nfo/dime





__________________________________________=
_____

DiME mailing list

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime=

 

--_000_C026C31E3CD6CA43953D6D95AB48048001B640CASAC1EXP009uswin_-- From nobody Thu Oct 15 03:33:31 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DB01ACE34 for ; Thu, 15 Oct 2015 03:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3zZa1lkTDPq for ; Thu, 15 Oct 2015 03:33:19 -0700 (PDT) Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827901ACE28 for ; Thu, 15 Oct 2015 03:33:17 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t9FATGdb013762; Thu, 15 Oct 2015 06:33:07 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 1xfpv2ng54-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Oct 2015 06:33:06 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t9FAX5hp021529; Thu, 15 Oct 2015 06:33:05 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t9FAWwnW021476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 15 Oct 2015 06:33:00 -0400 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 15 Oct 2015 10:32:49 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.54]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0248.002; Thu, 15 Oct 2015 06:32:49 -0400 From: "DOLLY, MARTIN C" To: "Lee, Jay" , ken carlberg , Steve Donovan Thread-Topic: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) Thread-Index: AQHRBzKJW/2/uK1FRUa1+r4tqwEunZ5sWkdA Date: Thu, 15 Oct 2015 10:32:49 +0000 Message-ID: References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> <20151014075941.062E21B2C1F@ietfa.amsl.com> <561E62C9.20500@usdonovans.com> <1431d0b2-5ae7-426e-b5ff-42b23fecbee5@CASAC1EXH002.uswin.ad.vzwcorp.com> <20151015101558.111761ACD5C@ietfa.amsl.com> In-Reply-To: <20151015101558.111761ACD5C@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.226.116] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E8365615C54257MISOUT7MSGUSRDB_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-15_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510150124 Archived-At: Cc: "dime@ietf.org" Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 15 Oct 2015 10:33:29 -0000 --_000_E42CCDDA6722744CB241677169E8365615C54257MISOUT7MSGUSRDB_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A couple thoughts: 1. There needs to be a default value defined by the standard, so that = equipment have the same value leaving the factory 2. This value can be over written based on local policy 3. Should have an extensibility bit in order to and more values in the= future From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay Sent: Thursday, October 15, 2015 6:16 AM To: ken carlberg ; Steve Donovan Cc: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) >From my side, some more discussion on Steve's mail may be needed. 'Should' vs. 'Must': One can say that 'Should' is not mandatory. But, in practice, this is a fai= rly strong statement, and often taken as required. So in this sense, the pr= oposed Note is certainly helpful. But, since we allow operators to override= the value, I don't see the reason why we use 'Should'. My suggestion is us= ing 'May'. PRIORITY_14 priority: Since operators can overwrite it, I was not too concerned about it. But if = we want to put some value, why '14'? A value lower than 14 is suggested in = order to allow more rooms for lower priorities. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg Sent: Wednesday, October 14, 2015 8:40 AM To: Steve Donovan Cc: dime@ietf.org Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): R= ange of priority levels) with respect to the diff-serv example brought up below, some thing to add t= o that discussion is that it starts off with separate and distinct forwardi= ng behavior whose marked packets provide segmentation of other IP traffic. = The availability of only 6 bits to play with (along with the headaches of = transitive trust) also discouraged a line of thought to define end-to-end p= riority handling versus a per diff-serv domain treatment. RFC-4594 did pro= vide configuration guidelines, but that's a different story. So back to a couple of ideas to consider. 1) reserved space. if we go back to the diff-serv model, the diff-serv wor= king group agreed to set aside a set of values that was reserved for experi= mental use that could be re-assigned some time in the future. I'm not sugg= esting that there should be space set side for experiments, but rather it m= ay be prudent to set aside a reserved set of bits/values so that one doesn'= t need to define a new AVP if in the future there was a need to define adde= d values beyond the 5 (plus some fudge factor) already mentioned on the lis= t. 2) sets of users. previous work (e.g., rfc-4412, rfc-6710) recognized that= there can be several sets of users/services that are distinct from each ot= her and yet need to prioritize the traffic. I bring this up because the dr= aft already identifies two sets of users in sections 5.1 and 5.2 (note: I'm= assuming that the latter is aimed at the general public and related to 911= /112/999 type calls, which should probably be more specific in the draft). = And there is also the potential of Firstnet users in the US. As a side note, the distinction and separation of general public and other = prioritized users in public phone infrastructures is not exclusive to the U= S, so the group should not be concerned that this is a US centric effort. = There has been GTPS in the UK, as well as other systems in other countries.= The RFC is a bit dated, but feel free to go over rfc-4190 for added backg= round. and just to reiterate. I'm not making recommendations in the above - just = bringing up some food for thought. -ken On Oct 14, 2015, at 10:12 AM, Steve Donovan > wrote: Jay, The current text is a SHOULD level requirement: When there is a mix of transactions specifying priority in request messages and transactions that do not have the priority specified, transactions that do not have a specified priority SHOULD be treated as having the PRIORITY_14 priority. As such, operators can choose to either not implement a priority or define = a different value for their network. I propose adding the following note after this paragraph to further explain= why it is a SHOULD and not a MUST: Note: There are scenarios where operators might want to specify a different default value for transactions that do not have an explicit priority. In this case, the operator defined local policy would override the use of PRIORITY_14 as the default priority. This leaves the ability for there to be deterministic behavior in Diameter = networks that require a default to be defined and are happy with the specif= ied default. It also gives operators the ability to define a different beh= avior, most likely with some priority handling/mapping at the edge of the n= etwork. Does this address your concerns? Regards, Steve On 10/14/15 2:59 AM, Lee, Jay wrote: Regarding the issue of whether we need to specify a default value or not, t= here are pros and cons. If we specify a value for the default case, we can see the benefits in scen= arios between different operator networks, but we take away important optio= ns on what operators can do with priority values. On the other hand, if we = do not specify the default value, operators may have more options, but ther= e is a question of what to do for this inter-PLMN cases when the networks m= ay use different default values. In practice, this issue can be addressed at the edge of the network, where = Diameter edge agent (DEA) can perform some priority mapping based on bilate= ral roaming agreement (or SLA (service level agreement)) and other means to= insure the proper handling. One may argue that this is not as good as the = 'deterministic' case, but operator should be able handle this in a reasonab= le way. We are fully aware of the fact that, in case of this 'non-determini= stic' case, the default value can differ from one operator network to anoth= er, and it becomes difficult to guarantee the intended priority handling. D= espite this, we still prefer giving options to operators by not specifying = the default value. What we are saying here, however, is not anything new. This is the typical = way of handling priority levels. If anything, specifying the default value = would be something new. As already mentioned in CT discussion, there is a g= ood example of this - Internet QoS, more specifically DiffServ. In order to guarantee end-to-end QoS for a specific service, IETF could hav= e specified a value (DiffServ codepoint) for the specific service to have p= redetermined handling of the traffic, but IETF did not. Instead, DiffServ s= imply provided a framework for operators to have its own classification an= d differentiated treatment of the services. To guarantee end-to-end QoS acr= oss different networks, then, operators need to do packet inspection, (re)c= lassification, QoS mapping, use of SLA and possibly others at the edge of n= etwork (edge router). Therefore, in the DiffServ architecture, intelligence= was pushed to the edge of the network. While the end results may not be gu= aranteed as well as in the case of predetermined handling, it was still a p= referred way to give flexibility to operators. My point is that we went thr= ough all these troubles to give options of priority handling to operators. By the way, if we are thinking of possibility of specifying the default val= ue, are we assuming that all operators are interested in this feature (defa= ult value in the middle, and high and low priorities at other ends)? Aren't= there other operators who are not interested in this feature? I know that = at least there is one - Verizon. We have no interest in this feature, and n= o plan for implementing it. We are OK, if other operators are interested in= this feature, and the default value is NOT specified. But we are certainly= not happy if DIME is trying to impose this on us. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, October 13, 2015 10:55 AM To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org; Pollini, Gregory P Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Assuming that we define a range of 3 values, Assuming that 0 is the lowest priority and 2 the highest, Assuming that an agent receives 4 messages at the same time while being in = overload control: * 1) ULR with Prio-0 * 2) ULR with Prio-1 * 3) ULR with Prio-2 * 4) ULR with no priority AVP Assuming that the default is locally defined as proposed below, How do you know that the ULR with priority 2 will be handled with a higher = priority than the request without priority indication? And what about ULR message with priority 1 with two levels of highest prior= ity e.g. emergency/Important and government/very important? Sorry if the answer is obvious but I fail to understand. Lionel De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] Envoy=E9 : samedi 3 octobre 2015 01:21 =C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C Cc : DiME; dime@ietf.org; Pollini, Gregory P Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels Hello all, Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.21= 2 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defi= ned. Having 15 rather than 16 would be useful from an interworking point of view= on Diameter interfaces connecting to the EPS. Also, my understanding has been that the default value is per local policy. My 2 cents.... Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf = of lionel.morand@orange.com [lionel.morand= @orange.com] Sent: Thursday, October 01, 2015 3:36 AM To: Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Hi, I think that the case "no Priority indication in request" is the default si= tuation today. So if we agree that it should be possible to explicitly indicate a request = with a lower priority, we should divide the range of priority values in thr= ee sub-ranges: [lower priorities][no priority indication][higher priorities= ], e.g. with 17 values: [0-7][8][9-16]. If any operator can freely fix the default value, there would be no way to = ensure the sender that a request with a specific priority value (e.g. 6) wi= ll be handled with a lower or higher priority than a request with no priori= ty indication. Therefore, for a deterministic handling mechanism, I think that it is then = more relevant to define a standard value for the default value. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn Envoy=E9 : mercredi 30 septembre 2015 22:53 =C0 : DOLLY, MARTIN C Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels Same here. The "default priority" should be a matter of local policy. Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "DOLLY, MARTIN C" > To: Steve Donovan >, "dime@ietf.org" > Date: 09/30/2015 04:40 PM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" = > ________________________________ Me as well From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, September 30, 2015 4:38 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels I'm okay with Jay's proposal on not specifying a default value. Steve On 9/30/15 3:27 PM, Lee, Jay wrote: Hi Steve and all, For the first proposal, as I indicated, I support increasing the number of = priority levels up to 16. I am also fine with the second proposal. My question is: do we need to mand= ate this feature, as individual operators have different situations? Perhap= s some flexibility should be allowed? Instead of mandating it, we can inclu= de the statement that when there is no DRMP AVP, this correspond to 'normal= traffic' without a particular high or low priority. Then each operator can= map this default to a value (e.g., 8 or something else) that they feel app= ropriate. Thanks, Jay _______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_E42CCDDA6722744CB241677169E8365615C54257MISOUT7MSGUSRDB_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

A couple thoughts:<= /p>

1.   = ;   There needs to be a default v= alue defined by the standard, so that equipment have the same value leaving= the factory

2.   = ;   This value can be over writte= n based on local policy

3.   = ;   Should have an extensibility = bit in order to and more values in the future

 

 

From: DiME [mailto:dime-bounces@ietf= .org] On Behalf Of Lee, Jay
Sent: Thursday, October 15, 2015 6:16 AM
To: ken carlberg <carlberg@g11.org.uk>; Steve Donovan <srdo= novan@usdonovans.com>
Cc: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

From my side, some more discussion on= Steve’s mail may be needed.

 

‘Should’ vs. ‘Must&= #8217;:

One can say that ‘Should’= is not mandatory. But, in practice, this is a fairly strong statement, and= often taken as required. So in this sense, the proposed Note is certainly helpful. But, since we allow operators to override the value,= I don’t see the reason why we use ‘Should’. My suggestio= n is using ‘May’.

 

PRIORITY_14 priority:

Since operators can overwrite it, I w= as not too concerned about it. But if we want to put some value, why ‘= ;14’? A value lower than 14 is suggested in order to allow more rooms for lower priorities.

 

Jay

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg
Sent: Wednesday, October 14, 2015 8:40 AM
To: Steve Donovan
Cc: dime@ietf.org
Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (d= rmp): Range of priority levels)

 

with respect to the diff-serv example brought up bel= ow, some thing to add to that discussion is that it starts off with separat= e and distinct forwarding behavior whose marked packets provide segmentatio= n of other IP traffic.  The availability of only 6 bits to play with (along with the headaches of transitive trust)= also discouraged a line of thought to define end-to-end priority handling = versus a per diff-serv domain treatment.  RFC-4594 did provide configu= ration guidelines, but that’s a different story.

 

So back to a couple of ideas to consider.=

 

1) reserved space.  if we go back to the diff-s= erv model, the diff-serv working group agreed to set aside a set of values = that was reserved for experimental use that could be re-assigned some time = in the future.  I’m not suggesting that there should be space set side for experiments, but rather it may be prude= nt to set aside a reserved set of bits/values so that one doesn't need to d= efine a new AVP if in the future there was a need to define added values be= yond the 5 (plus some fudge factor) already mentioned on the list. 

 

2) sets of users.  previous work (e.g., rfc-441= 2, rfc-6710) recognized that there can be several sets of users/services th= at are distinct from each other and yet need to prioritize the traffic. &nb= sp;I bring this up because the draft already identifies two sets of users in sections 5.1 and 5.2 (note: I’m assu= ming that the latter is aimed at the general public and related to 911/112/= 999 type calls, which should probably be more specific in the draft).  = ;And there is also the potential of Firstnet users in the US.

 

As a side note, the distinction and separation of ge= neral public and other prioritized users in public phone infrastructures is= not exclusive to the US, so the group should not be concerned that this is= a US centric effort.  There has been GTPS in the UK, as well as other systems in other countries.  The RFC= is a bit dated, but feel free to go over rfc-4190 for added background.

 

and just to reiterate.  I’m not making re= commendations in the above — just bringing up some food for thought.<= o:p>

 

-ken

 

 

On Oct 14, 2015, at 10:12 AM, Steve Donovan <srdonovan@usdonovans.com> wr= ote:

 

Ja= y,

The current text is a SHOULD level require= ment:

   When there is a mix of transa= ctions specifying priority in request
   messages and transactions tha= t do not have the priority specified,
   transactions that do not have= a specified priority SHOULD be treated
   as having the PRIORITY_14 pri= ority.

As such, operators can choose to either no= t implement a priority or define a different value for their network.

I propose adding the following note after = this paragraph to further explain why it is a SHOULD and not a MUST:=

      Note: There= are scenarios where operators might want to 
      specify a d= ifferent default value for transactions that do not
      have an exp= licit priority.  In this case, the operator defined
      local polic= y would override the use of PRIORITY_14 as
      the default= priority.

This leaves the ability for there to be de= terministic behavior in Diameter networks that require a default to be defi= ned and are happy with the specified default.  It also gives operators= the ability to define a different behavior, most likely with some priority handling/mapping at the edge of the network= .

Does this address your concerns?
Regards,

Steve

On 10/14/15 2:59 AM, Le= e, Jay wrote:

Regarding = the issue of whether we need to specify a default value or not, there are p= ros and cons.

 

If we spec= ify a value for the default case, we can see the benefits in scenarios betw= een different operator networks, but we take away important options on what operators can do with priority values. On the ot= her hand, if we do not specify the default value, operators may have more o= ptions, but there is a question of what to do for this inter-PLMN cases whe= n the networks may use different default values.

 

In practic= e, this issue can be addressed at the edge of the network, where Diameter e= dge agent (DEA) can perform some priority mapping based on bilateral roaming agreement (or SLA (service level agreement)) an= d other means to insure the proper handling. One may argue that this is not= as good as the ‘deterministic’ case, but operator should be ab= le handle this in a reasonable way. We are fully aware of the fact that, in case of this ‘non-deterministic’ ca= se, the default value can differ from one operator network to another, and = it becomes difficult to guarantee the intended priority handling. Despite t= his, we still prefer giving options to operators by not specifying the default value.

 

What we ar= e saying here, however, is not anything new. This is the typical way of han= dling priority levels. If anything, specifying the default value would be something new. As already mentioned in CT discussio= n, there is a good example of this – Internet QoS, more specifically = DiffServ.

 

In order t= o guarantee end-to-end QoS for a specific service, IETF could have specifie= d a value (DiffServ codepoint) for the specific service to have predetermined handling of the traffic, but IETF did not. I= nstead, DiffServ simply provided a framework for operators to have its own =  classification and differentiated treatment of the services. To guara= ntee end-to-end QoS across different networks, then, operators need to do packet inspection, (re)classification= , QoS mapping, use of SLA and possibly others at the edge of network (edge = router). Therefore, in the DiffServ architecture, intelligence was pushed t= o the edge of the network. While the end results may not be guaranteed as well as in the case of predetermi= ned handling, it was still a preferred way to give flexibility to operators= . My point is that we went through all these troubles to give options of pr= iority handling to operators.

 

By the way= , if we are thinking of possibility of specifying the default value, are we= assuming that all operators are interested in this feature (default value in the middle, and high and low priorities at other= ends)? Aren’t there other operators who are not interested in this f= eature? I know that at least there is one – Verizon. We have no inter= est in this feature, and no plan for implementing it. We are OK, if other operators are interested in this feature, and the = default value is NOT specified. But we are certainly not happy if DIME is t= rying to impose this on us.

 

Jay=

 

From: DiME [mai= lto:dime-bounces@ietf.org]=  On Behalf Of lionel.morand@orange.com
Sent: Tuesday, Oct= ober 13, 2015 10:55 AM
To: Shaikh, Viqar = A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; = dime@ietf.org; Pollini, Gregory P Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 

Assuming t= hat we define a range of 3 values,

Assuming t= hat 0 is the lowest priority and 2 the highest,

Assuming t= hat an agent receives 4 messages at the same time while being in overload c= ontrol:

=B7     &nbs= p; = 1) ULR with Prio-0

=B7     &nbs= p; = 2) ULR with Prio-1

=B7     &nbs= p; = 3) ULR with Prio-2

=B7     &nbs= p; = 4) ULR with no priority AVP

 

Assuming t= hat the default is locally defined as proposed below,

 

How do you= know that the ULR with priority 2 will be handled with a higher priority &= nbsp;than the request without priority indication?

And what a= bout ULR message with priority 1 with two levels of highest priority e.g. e= mergency/Important and government/very important?

 

Sorry if t= he answer is obvious but I fail to understand.

 

Lionel

 

 

 &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  

De :<= /span> Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] 
Envoy=E9 : sa= medi 3 octobre 2015 01:21
=C0 : MORAND = Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; dime@ietf.org; Pollini, Grego= ry P
Objet : RE: [= Dime] [dime] #92 (drmp): Range of priority levels

 <= /span>

Hello all,<= /span>

 

Note t= hat the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 = ;takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined.

 

Having 15 r= ather than 16 would be useful from an interworking point of view on Diamete= r interfaces connecting to the EPS.  

 

Also, my un= derstanding has been that the default value is per local policy. =

 

My 2 cents.= ...

Viqar =

<= span lang=3D"FR" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">From: DiME [dim= e-bounces@ietf.org] on behalf of lionel.morand@orange.com [<= span style=3D"color:purple">lionel.morand@orange.com]
Sent: Thursday, Oc= tober 01, 2015 3:36 AM
To: Janet P Gunn; = DOLLY, MARTIN C
Cc: DiME; = dime@ietf.org
Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

Hi,=

 <= /span>

I think th= at the case "no Priority indication in request" is the default si= tuation today.

So if we a= gree that it should be possible to explicitly indicate a request with a low= er priority, we should divide the range of priority values in three sub-ranges: [lower priorities][no priority indication][hig= her priorities], e.g. with 17 values: [0-7][8][9-16].

If any ope= rator can freely fix the default value, there would be no way to ensure the= sender that a request with a specific priority value (e.g. 6) will be handled with a lower or higher priority than a requ= est with no priority indication.

 <= /span>

Therefore,= for a deterministic handling mechanism, I think that it is then more relev= ant to define a standard value for the default value.

 <= /span>

Regards,

 <= /span>

Lionel

 <= /span>

 <= /span>

De :<= /span> DiME [mai= lto:dime-bounces@ietf.org]=  De la part de&nbs= p;Janet P Gunn
Envoy=E9 : me= rcredi 30 septembre 2015 22:53
=C0 : DOLLY, = MARTIN C
Cc : DiME; dime@ietf.org
Objet : Re: [= Dime] [dime] #92 (drmp): Range of priority levels

 <= /span>

Same here. &= nbsp;The "default priority" should be a matter of local policy. <= /span>

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose. 



From:        "DOLLY, MARTIN C" <md3135@att.com> 
To:        Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org> <= /span>
Date:        09/30/2015 04:40 PM 
Subject:        <= span lang=3D"FR" style=3D"font-size:7.5pt;font-family:"Arial",san= s-serif">Re: [Dime] [dime] #92 (drmp): Range of priority levels 
Sent by:        <= span lang=3D"FR" style=3D"font-size:7.5pt;font-family:"Arial",san= s-serif">"DiME" <dime-bounces@ietf.org= >




Me as well 
  
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Dono= van
Sent: Wednesday, Sept= ember 30, 2015 4:38 PM
To: dime@ietf.or= g
Subject: Re: [Dime] [= dime] #92 (drmp): Range of priority levels 
  
I'm okay with Jay's proposal on not specifying a defaul= t value.

Steve <= /span>
On 9/30/15 3:27 PM, Lee, Jay wrote: 
Hi Steve and all, 
  
For the first proposal, as I indicated, I support incre= asing the number of priority levels up to 16. 
  
I am also fine with the second proposal. My question is= : do we need to mandate this feature, as individual operators have differen= t situations? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that whe= n there is no DRMP AVP, this correspond to ‘normal traffic’ wit= hout a particular high or low priority. Then each operator can map this def= ault to a value (e.g., 8 or something else) that they feel appropriate. 
  
Thanks, 
  
Jay 



_______________________= ________________________ 
DiME mailing list 
DiME@ietf.org 
https://www.ietf.org/mailman/li= stinfo/dime   _____________= __________________________________
DiME mailing list
DiME@ietf.org<= /span>
https://ww= w.ietf.org/mailman/listinfo/dime

_________________________=
___________________________________________________________________________=
_____________________
 <=
/pre>

Ce message et ses pieces =
jointes peuvent contenir des informations confidentielles ou privilegiees e=
t ne doivent donc


pas etre diffuses, exploi=
tes ou copies sans autorisation. Si vous avez recu ce message par erreur, v=
euillez le signaler


a l'expediteur et le detr=
uire ainsi que les pieces jointes. Les messages electroniques etant suscept=
ibles d'alteration,


Orange decline toute resp=
onsabilite si ce message a ete altere, deforme ou falsifie. Merci.


 <=
/pre>

This message and its atta=
chments may contain confidential or privileged information that may be prot=
ected by law;


they should not be distri=
buted, used or copied without authorisation.


If you have received this=
 email in error, please notify the sender and delete this message and its a=
ttachments.


As emails may be altered,=
 Orange is not liable for messages that have been modified, changed or fals=
ified.


Thank you.


_________________________=
___________________________________________________________________________=
_____________________
 <=
/pre>

Ce message et ses pieces =
jointes peuvent contenir des informations confidentielles ou privilegiees e=
t ne doivent donc


pas etre diffuses, exploi=
tes ou copies sans autorisation. Si vous avez recu ce message par erreur, v=
euillez le signaler


a l'expediteur et le detr=
uire ainsi que les pieces jointes. Les messages electroniques etant suscept=
ibles d'alteration,


Orange decline toute resp=
onsabilite si ce message a ete altere, deforme ou falsifie. Merci.


 <=
/pre>

This message and its atta=
chments may contain confidential or privileged information that may be prot=
ected by law;


they should not be distri=
buted, used or copied without authorisation.


If you have received this=
 email in error, please notify the sender and delete this message and its a=
ttachments.


As emails may be altered,=
 Orange is not liable for messages that have been modified, changed or fals=
ified.


Thank you.








___________________________________________=
____


DiME mailing list


DiME@ietf.org


https://www.ietf.org/mailman/listi=
nfo/dime


__________________________________________= _____
DiME mailing list
DiM= E@ietf.org
https://www.ietf.org/mailman/listinfo/dime<= o:p>

 

--_000_E42CCDDA6722744CB241677169E8365615C54257MISOUT7MSGUSRDB_-- From nobody Sun Oct 18 20:34:26 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DABB1A01F7 for ; Sun, 18 Oct 2015 20:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCC_gdKHvy4H for ; Sun, 18 Oct 2015 20:34:24 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC7B1A0242 for ; Sun, 18 Oct 2015 20:34:23 -0700 (PDT) Received: by pasz6 with SMTP id z6so16157259pas.2 for ; Sun, 18 Oct 2015 20:34:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=RiXlfhtjQMPBAYh3N0KofCjZ5zZIWFIk9+tEXTjJVNE=; b=n4vvig5fh04R1TuWUlNPJTnYUfTf2VwScZ7BLhsuDJmaf/JdtVl+QBojnWNdIBWoc3 te/2YQ360AqvALHclydWVjy1aOCTTtY6+BYvZh1XPzRq8JV6cZ5iGH3VLrLH11jB98sf C82P14xi+2nQ95dn9FJl2M5HeMiPY3Iz1+O6W1HrFq6+BbJu7r41ydpVPgsMa+uHmeKX /SAZlkvF7hdOzmyBKWzKa2n5XYszk9uWmHK55/mHZHEzBZIYkhjeLBQaA3qLfoUYCNJo 5cJnrLU5xA/O9SW+OM72+Y/1zidGyQmTYy+weahox6bUSdv2wTK0VhzqKgAoSZjilZfx wHNA== X-Received: by 10.66.251.232 with SMTP id zn8mr31597929pac.80.1445225663515; Sun, 18 Oct 2015 20:34:23 -0700 (PDT) Received: from ?IPv6:2601:647:4204:228b:a5d5:1fa8:f626:d01? ([2601:647:4204:228b:a5d5:1fa8:f626:d01]) by smtp.googlemail.com with ESMTPSA id ah2sm24722942pad.10.2015.10.18.20.34.21 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Oct 2015 20:34:22 -0700 (PDT) To: dime@ietf.org References: <20151014211357.70C45180478@rfc-editor.org> From: Jouni Korhonen Message-ID: <562464BD.8030402@gmail.com> Date: Sun, 18 Oct 2015 20:34:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151014211357.70C45180478@rfc-editor.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dime] RFC 7660 on Diameter Congestion and Filter Attributes X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2015 03:34:25 -0000 Congratulations to authors and all who contributed. - Jouni & Lionel 10/14/2015, 2:13 PM, rfc-editor@rfc-editor.org kirjoitti: > A new Request for Comments is now available in online RFC libraries. > > > RFC 7660 > > Title: Diameter Congestion and Filter Attributes > Author: L. Bertz, > S. Manning, > B. Hirschman > Status: Standards Track > Stream: IETF > Date: October 2015 > Mailbox: lyleb551144@gmail.com, > sergem913@gmail.com, > Brent.Hirschman@gmail.com > Pages: 9 > Characters: 18830 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-dime-congestion-flow-attributes-02.txt > > URL: https://www.rfc-editor.org/info/rfc7660 > > DOI: http://dx.doi.org/10.17487/RFC7660 > > This document defines optional Diameter attributes that can be used > to help manage networks that use Explicit Congestion Notification > (ECN) or Diameter traffic filters. These new attributes allow for > improved data traffic identification, support of ECN, and minimal > Diameter filter administration. > > RFC 5777 defines a Filter-Rule Attribute Value Pair (AVP) that > accommodates extensions for classification, conditions, and actions. > It, however, does not support traffic identification for packets using > Explicit Congestion Notification as defined in RFC 3168 and does not > provide specific actions when the flow(s) described by the > Filter-Rule are congested. > > Further, a Filter-Rule can describe multiple flows but not the exact > number of flows. Flow count and other associated data (e.g., packets) > are not captured by accounting applications, leaving administrators > without useful information regarding the effectiveness or > appropriateness of the filter definition. > > The optional attributes defined in this document are forward and > backwards compatible with RFC 5777. > > This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for the > standardization state and status of this protocol. Distribution of this > memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/rfc.html > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Mon Oct 19 10:07:42 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D72A1A8BB2 for ; Mon, 19 Oct 2015 10:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWYcFTfUB9cP for ; Mon, 19 Oct 2015 10:07:19 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395C31A8A9B for ; Mon, 19 Oct 2015 10:07:18 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 6E275B38F2BEB for ; Mon, 19 Oct 2015 17:07:13 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t9JH7Frf021193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 19 Oct 2015 19:07:15 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.230]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 19 Oct 2015 19:07:15 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] [dime] #92 (drmp): Range of priority levels Thread-Index: AQHQ+7/7gjQt6THBK0qRj4pp4rg/GJ5VZy8AgAADsACAAM9WwIACfqKAgBDpAPCAAXt4FoAAJNmQgAfTo7A= Date: Mon, 19 Oct 2015 17:07:14 +0000 Message-ID: References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> <20151014075941.062E21B2C1F@ietfa.amsl.com> <09aed55e-b53b-4da8-a2f4-ca40ef1848cd@CASAC1EXH002.uswin.ad.vzwcorp.com> <20151014162834.1EFE11ACE53@ietfa.amsl.com> In-Reply-To: <20151014162834.1EFE11ACE53@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D29D462B77FR712WXCHMBA12z_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2015 17:07:30 -0000 --_000_E194C2E18676714DACA9C3A2516265D29D462B77FR712WXCHMBA12z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all To continue on this default value definition, I am a bit questioning to use= a MAY instead of a SHOULD in . A SHOULD is a strong request to be applied with some exceptions which are= in principal described. Then there is the hereafter proposed Note to give additional information " Note: there are scenarios where operators might want to specify a different default value for transactions that do not have an explicit priority" This Note is OK for me but corresponds more to a MAY in the normative text= than a SHOULD. In practice operators, will define their priority levels within their netwo= rks ; some with a few number of levels, other with a greater number of lev= els plus the corresponding values in the DRMP AVP range. Operators will d= o this mapping in their DAs at the edge of their network, this mapping wil= l include the default priority value they will choose for their network. Th= e fact to have a standardized value for the default priority does not avoid= the overall mapping. Nevertheless , if a standardized default priority value is defined and if = an operator has no particular reason to choose another value, this is bett= er to use this standardized value as a common point. This short comment drives more to a MAY than to a SHOULD in the normative = text. I am a bit keen to know arguments /use cases justifying a SHOULD. Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de Lee, Jay Envoy=E9 : mercredi 14 octobre 2015 18:29 =C0 : Steve Donovan; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels Steve, Your suggestion on adding 'Note' is okay with me. It certainly helps and ma= kes things clearer. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, October 14, 2015 7:12 AM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Jay, The current text is a SHOULD level requirement: a When there is a mix of transactions specifying priority in request messages and transactions that do not have the priority specified, transactions that do not have a specified priority SHOULD be treated as having the PRIORITY_14 priority. As such, operators can choose to either not implement a priority or define = a different value for their network. I propose adding the following note after this paragraph to further explain= why it is a SHOULD and not a MUST: Note: There are scenarios where operators might want to specify a different default value for transactions that do not have an explicit priority. In this case, the operator defined local policy would override the use of PRIORITY_14 as the default priority. This leaves the ability for there to be deterministic behavior in Diameter = networks that require a default to be defined and are happy with the specif= ied default. It also gives operators the ability to define a different beh= avior, most likely with some priority handling/mapping at the edge of the n= etwork. Does this address your concerns? Regards, Steve On 10/14/15 2:59 AM, Lee, Jay wrote: Regarding the issue of whether we need to specify a default value or not, t= here are pros and cons. If we specify a value for the default case, we can see the benefits in scen= arios between different operator networks, but we take away important optio= ns on what operators can do with priority values. On the other hand, if we = do not specify the default value, operators may have more options, but ther= e is a question of what to do for this inter-PLMN cases when the networks m= ay use different default values. In practice, this issue can be addressed at the edge of the network, where = Diameter edge agent (DEA) can perform some priority mapping based on bilate= ral roaming agreement (or SLA (service level agreement)) and other means to= insure the proper handling. One may argue that this is not as good as the = 'deterministic' case, but operator should be able handle this in a reasonab= le way. We are fully aware of the fact that, in case of this 'non-determini= stic' case, the default value can differ from one operator network to anoth= er, and it becomes difficult to guarantee the intended priority handling. D= espite this, we still prefer giving options to operators by not specifying = the default value. What we are saying here, however, is not anything new. This is the typical = way of handling priority levels. If anything, specifying the default value = would be something new. As already mentioned in CT discussion, there is a g= ood example of this - Internet QoS, more specifically DiffServ. In order to guarantee end-to-end QoS for a specific service, IETF could hav= e specified a value (DiffServ codepoint) for the specific service to have p= redetermined handling of the traffic, but IETF did not. Instead, DiffServ s= imply provided a framework for operators to have its own classification an= d differentiated treatment of the services. To guarantee end-to-end QoS acr= oss different networks, then, operators need to do packet inspection, (re)c= lassification, QoS mapping, use of SLA and possibly others at the edge of n= etwork (edge router). Therefore, in the DiffServ architecture, intelligence= was pushed to the edge of the network. While the end results may not be gu= aranteed as well as in the case of predetermined handling, it was still a p= referred way to give flexibility to operators. My point is that we went thr= ough all these troubles to give options of priority handling to operators. By the way, if we are thinking of possibility of specifying the default val= ue, are we assuming that all operators are interested in this feature (defa= ult value in the middle, and high and low priorities at other ends)? Aren't= there other operators who are not interested in this feature? I know that = at least there is one - Verizon. We have no interest in this feature, and n= o plan for implementing it. We are OK, if other operators are interested in= this feature, and the default value is NOT specified. But we are certainly= not happy if DIME is trying to impose this on us. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, October 13, 2015 10:55 AM To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org; Pollini, Gregory P Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Assuming that we define a range of 3 values, Assuming that 0 is the lowest priority and 2 the highest, Assuming that an agent receives 4 messages at the same time while being in = overload control: =B7 1) ULR with Prio-0 =B7 2) ULR with Prio-1 =B7 3) ULR with Prio-2 =B7 4) ULR with no priority AVP Assuming that the default is locally defined as proposed below, How do you know that the ULR with priority 2 will be handled with a higher = priority than the request without priority indication? And what about ULR message with priority 1 with two levels of highest prior= ity e.g. emergency/Important and government/very important? Sorry if the answer is obvious but I fail to understand. Lionel De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] Envoy=E9 : samedi 3 octobre 2015 01:21 =C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C Cc : DiME; dime@ietf.org; Pollini, Gregory P Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels Hello all, Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.21= 2 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defi= ned. Having 15 rather than 16 would be useful from an interworking point of view= on Diameter interfaces connecting to the EPS. Also, my understanding has been that the default value is per local policy. My 2 cents.... Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf = of lionel.morand@orange.com [lionel.morand= @orange.com] Sent: Thursday, October 01, 2015 3:36 AM To: Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Hi, I think that the case "no Priority indication in request" is the default si= tuation today. So if we agree that it should be possible to explicitly indicate a request = with a lower priority, we should divide the range of priority values in thr= ee sub-ranges: [lower priorities][no priority indication][higher priorities= ], e.g. with 17 values: [0-7][8][9-16]. If any operator can freely fix the default value, there would be no way to = ensure the sender that a request with a specific priority value (e.g. 6) wi= ll be handled with a lower or higher priority than a request with no priori= ty indication. Therefore, for a deterministic handling mechanism, I think that it is then = more relevant to define a standard value for the default value. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn Envoy=E9 : mercredi 30 septembre 2015 22:53 =C0 : DOLLY, MARTIN C Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels Same here. The "default priority" should be a matter of local policy. Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "DOLLY, MARTIN C" > To: Steve Donovan >, "dime@ietf.org" > Date: 09/30/2015 04:40 PM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" = > ________________________________ Me as well From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, September 30, 2015 4:38 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels I'm okay with Jay's proposal on not specifying a default value. Steve On 9/30/15 3:27 PM, Lee, Jay wrote: Hi Steve and all, For the first proposal, as I indicated, I support increasing the number of = priority levels up to 16. I am also fine with the second proposal. My question is: do we need to mand= ate this feature, as individual operators have different situations? Perhap= s some flexibility should be allowed? Instead of mandating it, we can inclu= de the statement that when there is no DRMP AVP, this correspond to 'normal= traffic' without a particular high or low priority. Then each operator can= map this default to a value (e.g., 8 or something else) that they feel app= ropriate. Thanks, Jay _______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_E194C2E18676714DACA9C3A2516265D29D462B77FR712WXCHMBA12z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all

 <= /p>

To continue on this defau= lt value definition, I am a bit questioning to use a MAY instead of a SHOUL= D in .

 <= /p>

A SHOULD is a strong requ= est to be applied  with some exceptions  which are in principal d= escribed.

Then there is the hereaft= er  proposed Note to give additional information

  “ Note: there are scenarios where = operators might want to
      specify a different default value for transa= ctions that do not
      have an explicit priority”  

  

This Note  is OK for= me but corresponds more to a MAY in the normative text than a SHOULD.=

 <= /p>

In practice operators, wi= ll define their priority levels within their networks ; some  with a f= ew number of levels, other with a greater number of levels plus the corresponding values in the DRMP AVP range.   Operators will= do this mapping in  their DAs at the edge of their network, this mapp= ing will include the default priority value they will choose for their netw= ork. The fact to have a standardized value for the default priority does not avoid the overall mapping.

Nevertheless , if a stand= ardized  default priority value is defined and if an operator has no p= articular reason to choose another value,  this is better to use this standardized value as a common point.

This  short comment = drives more to a MAY than to a SHOULD in the normative text. I am a bit kee= n to know  arguments /use cases justifying a SHOULD.=

 <= /p>

Best regards

 <= /p>

JJacques

 <= /p>

De = : DiME [mailto:dime-bou= nces@ietf.org] De la part de Lee, Jay
Envoy=E9 : mercredi 14 octobre 2015 18:29
=C0 : Steve Donovan; dime@ietf.org
Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels<= o:p>

 

Steve,<= /p>

 <= /p>

Your suggestion on adding= ‘Note’ is okay with me. It certainly helps and makes things cl= earer.

 <= /p>

Jay

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Wednesday, October 14, 2015 7:12 AM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels=

 

Jay,

The current text is a SHOULD level requirement:
a
   When there is a mix of transactions specifying priority in req= uest
   messages and transactions that do not have the priority specif= ied,
   transactions that do not have a specified priority SHOULD be t= reated
   as having the PRIORITY_14 priority.

As such, operators can choose to either not implement a priority or define = a different value for their network.

I propose adding the following note after this paragraph to further explain= why it is a SHOULD and not a MUST:

      Note: There are scenarios where operators mi= ght want to
      specify a different default value for transa= ctions that do not
      have an explicit priority.  In this cas= e, the operator defined
      local policy would override the use of PRIOR= ITY_14 as
      the default priority.

This leaves the ability for there to be deterministic behavior in Diameter = networks that require a default to be defined and are happy with the specif= ied default.  It also gives operators the ability to define a differen= t behavior, most likely with some priority handling/mapping at the edge of the network.

Does this address your concerns?

Regards,

Steve

On 10/14/15 2:59 AM, Lee, Jay wrote:

Regarding the issue of wh= ether we need to specify a default value or not, there are pros and cons.

 <= /p>

If we specify a value for= the default case, we can see the benefits in scenarios between different o= perator networks, but we take away important options on what operators can do with priority values. On the other hand, if we do no= t specify the default value, operators may have more options, but there is = a question of what to do for this inter-PLMN cases when the networks may us= e different default values.

 <= /p>

In practice, this issue c= an be addressed at the edge of the network, where Diameter edge agent (DEA)= can perform some priority mapping based on bilateral roaming agreement (or SLA (service level agreement)) and other means to insure the= proper handling. One may argue that this is not as good as the ‘dete= rministic’ case, but operator should be able handle this in a reasona= ble way. We are fully aware of the fact that, in case of this ‘non-deterministic’ case, the default value ca= n differ from one operator network to another, and it becomes difficult to = guarantee the intended priority handling. Despite this, we still prefer giv= ing options to operators by not specifying the default value.

 <= /p>

What we are saying here, = however, is not anything new. This is the typical way of handling priority = levels. If anything, specifying the default value would be something new. As already mentioned in CT discussion, there is a good e= xample of this – Internet QoS, more specifically DiffServ.

 <= /p>

In order to guarantee end= -to-end QoS for a specific service, IETF could have specified a value (Diff= Serv codepoint) for the specific service to have predetermined handling of the traffic, but IETF did not. Instead, DiffServ simply provid= ed a framework for operators to have its own  classification and diffe= rentiated treatment of the services. To guarantee end-to-end QoS across dif= ferent networks, then, operators need to do packet inspection, (re)classification, QoS mapping, use of SLA and p= ossibly others at the edge of network (edge router). Therefore, in the Diff= Serv architecture, intelligence was pushed to the edge of the network. Whil= e the end results may not be guaranteed as well as in the case of predetermined handling, it was still a preferred= way to give flexibility to operators. My point is that we went through all= these troubles to give options of priority handling to operators.

 <= /p>

By the way, if we are thi= nking of possibility of specifying the default value, are we assuming that = all operators are interested in this feature (default value in the middle, and high and low priorities at other ends)? Aren’t th= ere other operators who are not interested in this feature? I know that at = least there is one – Verizon. We have no interest in this feature, an= d no plan for implementing it. We are OK, if other operators are interested in this feature, and the default value is N= OT specified. But we are certainly not happy if DIME is trying to impose th= is on us.

 <= /p>

Jay

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.mora= nd@orange.com
Sent: Tuesday, October 13, 2015 10:55 AM
To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; dime@ietf.org; Pollin= i, Gregory P
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels

 

Assuming that we define a= range of 3 values,

Assuming that 0 is the lo= west priority and 2 the highest,

Assuming that an agent re= ceives 4 messages at the same time while being in overload control:

=B7         1) ULR with Prio-= 0

=B7         2) ULR with Prio-= 1

=B7         3) ULR with Prio-= 2

=B7         4) ULR with no pr= iority AVP

 <= /p>

Assuming that the default= is locally defined as proposed below,

 <= /p>

How do you know that the = ULR with priority 2 will be handled with a higher priority  than the r= equest without priority indication?

And what about ULR messag= e with priority 1 with two levels of highest priority e.g. emergency/Import= ant and government/very important?

 <= /p>

Sorry if the answer is ob= vious but I fail to understand.

 <= /p>

Lionel<= /p>

 <= /p>

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;

De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com]
Envoy=E9 : samedi 3 octobre 2015 01:21
=C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; dime@ietf.org; = Pollini, Gregory P
Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels<= /span>

 

Hello all,

 

Note that the 3GPP prio= rity, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 takes 15 values,= value 1 the highest, 15 the lowest, and value 0 not defined.

 

Having 15 rather than 16 wou= ld be useful from an interworking point of view on Diameter interfaces conn= ecting to the EPS.  

 

Also, my understanding has b= een that the default value is per local policy. 

 

My 2 cents....

Viqar 

From: DiME [dime-bounces@ietf.org] on behalf of lionel.morand@ora= nge.com [lionel.morand@oran= ge.com]
Sent: Thursday, October 01, 2015 3:36 AM
To: Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels

Hi,

 

I think that the case &qu= ot;no Priority indication in request" is the default situation today.<= /span>

So if we agree that it sh= ould be possible to explicitly indicate a request with a lower priority, we= should divide the range of priority values in three sub-ranges: [lower priorities][no priority indication][higher priorities], e.g. with 1= 7 values: [0-7][8][9-16].

If any operator can freel= y fix the default value, there would be no way to ensure the sender that a = request with a specific priority value (e.g. 6) will be handled with a lower or higher priority than a request with no priority in= dication.

 

Therefore, for a determin= istic handling mechanism, I think that it is then more relevant to define a= standard value for the default value.

 

Regards,

 

Lionel<= /p>

 

 

De : DiME [mailto:d= ime-bounces@ietf.org] De la part de Janet P Gunn
Envoy=E9 : mercredi 30 septembre 2015 22:53
=C0 : DOLLY, MARTIN C
Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels<= /span>

 

Same here.  The "de= fault priority" should be a matter of local policy.

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose.



From:        = ;"DOLLY, MARTIN C" <md3135@att.com>
To:        <= /span>Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org= " <dime@ietf.org= >
Date:        = ;09/30/2015 04:40 PM
Subject:       &n= bsp;Re: [Dime] [dime] #92 (drmp): Range of pri= ority levels
Sent by:       &n= bsp;"DiME" <dime-bounces@ietf.org><= span lang=3D"FR">



Me as well
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Wednesday, September 30, 2015 4:38 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels<= span lang=3D"FR">
 
I'm okay with Jay's proposal on not specify= ing a default value.

Steve
On 9/30/15 3:27 PM, Lee, Jay wrote:<= span lang=3D"FR">
Hi Steve and all,
 
For the first proposal, as I indicated, I s= upport increasing the number of priority levels up to 16.
 
I am also fine with the second proposal. My= question is: do we need to mandate this feature, as individual operators h= ave different situations? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that whe= n there is no DRMP AVP, this correspond to ‘normal traffic’ wit= hout a particular high or low priority. Then each operator can map this def= ault to a value (e.g., 8 or something else) that they feel appropriate.
 
Thanks,
 
Jay



_______________________________________________=
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/d= ime

________________________________________________________________=
_________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.


 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that=
 have been modified, changed or falsified.


Thank you.


________________________________________________________________=
_________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.


 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that=
 have been modified, changed or falsified.


Thank you.









_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime

 

--_000_E194C2E18676714DACA9C3A2516265D29D462B77FR712WXCHMBA12z_-- From nobody Mon Oct 19 10:49:17 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258DF1AD069 for ; Mon, 19 Oct 2015 10:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McKm8ZVw5LrI for ; Mon, 19 Oct 2015 10:49:12 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566971ACE98 for ; Mon, 19 Oct 2015 10:49:12 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 8EEB740216 for ; Mon, 19 Oct 2015 19:49:10 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 71BEB1A0061 for ; Mon, 19 Oct 2015 19:49:10 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0248.002; Mon, 19 Oct 2015 19:49:10 +0200 From: To: "dime@ietf.org" Thread-Topic: Agenda slot at the IETF94 Thread-Index: AdEKllZY6wCE+tyZSUSpjPwXeizy9g== Date: Mon, 19 Oct 2015 17:49:10 +0000 Message-ID: <7484_1445276950_56252D16_7484_3890_1_6B7134B31289DC4FAF731D844122B36E01D47E2F@OPEXCLILM43.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.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dime] Agenda slot at the IETF94 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 19 Oct 2015 17:49:14 -0000 Folks, For this IETF meeting, DIME and RADEXT WGs will have exceptionally a joint = session on Tuesday afternoon, from 13:00-15:00. For Dime, we will have about one hour. We expect some discussions/progress on the following WG documents: - Expected by 3GPP: *draft-ietf-dime-drmp-01 *draft-ietf-dime-load-01 - Overload control enhancements: *draft-ietf-dime-agent-overload-03 *draft-ietf-dime-doic-rate-control-02 - Status: *draft-ietf-dime-group-signaling-05 Authors, please provide a presentation on the status/next steps for the dra= fts above. Don't forget that a remote participation is possible if you are = not in Yokohama. For any other point outside the current charter that you would like to addr= ess, please send a specific request for an additional slot. regards, 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 authorization. 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 shall not be liable if th= is message was modified, changed or falsified. Thank you. From nobody Thu Oct 22 09:39:06 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E0E1AD079 for ; Thu, 22 Oct 2015 09:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ml6xzSHaNoSQ for ; Thu, 22 Oct 2015 09:38:52 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34D671A9077 for ; Thu, 22 Oct 2015 09:38:51 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 734A839071761 for ; Thu, 22 Oct 2015 16:38:45 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t9MGcm2t012833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 22 Oct 2015 18:38:48 +0200 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.230]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 22 Oct 2015 18:38:48 +0200 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) Thread-Index: AQHRBzKIwn0SbO3rXUW/ebDof+lRcp5sOcGAgAtoZjA= Date: Thu, 22 Oct 2015 16:38:47 +0000 Message-ID: References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> <20151014075941.062E21B2C1F@ietfa.amsl.com> <561E62C9.20500@usdonovans.com> <1431d0b2-5ae7-426e-b5ff-42b23fecbee5@CASAC1EXH002.uswin.ad.vzwcorp.com> <20151015101558.111761ACD5C@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D29D463A7CFR712WXCHMBA12z_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 16:39:04 -0000 --_000_E194C2E18676714DACA9C3A2516265D29D463A7CFR712WXCHMBA12z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi 1. PRIORITY_14 as default priority value only allows one level of low= er priority (PRIORITY_15) than the default one; this seems not enough. As= use cases, we may have some Machine type Communication (LTC) devices that= may have lower priorities that normal communications without priority. Ev= en within a Diameter application, some commands may have a lower priority a= s having a secundary importance. Then which default value ? - it could be PRIORITY_8 in the middle, or if we prefer to have a = larger range for higher priorities than for lower priorities, the defaul= t value could be e.g. PRIORITY_10, giving 9 higher priorities and 5 lower= priorities than the default one. I would have a preference for this value = PRIORITY_10. 2. About extensibility, the current range of 16 values is already lar= ge, but we can have a reserved value to indicate a further extension. With= an enumerated AVP, there is no possibility to add new values. 3. I also had a look to some other IETF RFCs addressing priorities th= at Ken mentioned, so to see if we can benefit from these approaches althoug= h done for different contexts. - in RFC 4412 (Resource-Priority Header in SIP), wps and ets names= paces have a range of 5 values (0 to 4) with 0 as the highest priority . B= ut I have not found some indication (I may have missed it) about the defau= lt priority (I mean a SIP request without Resource-Priority Header compar= ed to a SIP request with the Header). Implicitly, I would assume a SIP req= uest without Resource-Priority Header corresponds to the lowest priority.= DRMP has a similar approach but with a larger range and also lower prior= ities. - RFC 6710 (priority for SMTP), uses another encoding of the pri= ority values with an integer between -9 and +9. Lower priorities are negat= ive an higher priority being positive. When a value increases, it means a h= igher priority, so the opposite to DRMP, wps or ets. But the value 0 is h= ere naturally the default value. So this is an encoding alternative to the= Enumerated type of the DRMP AVP which avoids the question of the default = value. Note: RFC 6710 also defines some Priority Assignment Policies using a subs= et of the range. RFC 6710 has also this guideline : SMTP servers compliant with this specification are not required to support all 19 distinct priority levels (i.e., to treat each priority value as a separate priority), .... That is, an implementation that only supports N priority levels (where N < 19) will internally round up a syntactically valid priority value that isn't supported to the next higher supported number (or to the highest supported priority, if the value is higher than any supported pr= iority). - This raises the question to have this type of guideline if cons= idered useful. So to have your feedback Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C Envoy=E9 : jeudi 15 octobre 2015 12:33 =C0 : Lee, Jay; ken carlberg; Steve Donovan Cc : dime@ietf.org Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp)= : Range of priority levels) A couple thoughts: 1. There needs to be a default value defined by the standard, so that = equipment have the same value leaving the factory 2. This value can be over written based on local policy 3. Should have an extensibility bit in order to and more values in the= future From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay Sent: Thursday, October 15, 2015 6:16 AM To: ken carlberg >; Steve D= onovan > Cc: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) >From my side, some more discussion on Steve's mail may be needed. 'Should' vs. 'Must': One can say that 'Should' is not mandatory. But, in practice, this is a fai= rly strong statement, and often taken as required. So in this sense, the pr= oposed Note is certainly helpful. But, since we allow operators to override= the value, I don't see the reason why we use 'Should'. My suggestion is us= ing 'May'. PRIORITY_14 priority: Since operators can overwrite it, I was not too concerned about it. But if = we want to put some value, why '14'? A value lower than 14 is suggested in = order to allow more rooms for lower priorities. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg Sent: Wednesday, October 14, 2015 8:40 AM To: Steve Donovan Cc: dime@ietf.org Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): R= ange of priority levels) with respect to the diff-serv example brought up below, some thing to add t= o that discussion is that it starts off with separate and distinct forwardi= ng behavior whose marked packets provide segmentation of other IP traffic. = The availability of only 6 bits to play with (along with the headaches of = transitive trust) also discouraged a line of thought to define end-to-end p= riority handling versus a per diff-serv domain treatment. RFC-4594 did pro= vide configuration guidelines, but that's a different story. So back to a couple of ideas to consider. 1) reserved space. if we go back to the diff-serv model, the diff-serv wor= king group agreed to set aside a set of values that was reserved for experi= mental use that could be re-assigned some time in the future. I'm not sugg= esting that there should be space set side for experiments, but rather it m= ay be prudent to set aside a reserved set of bits/values so that one doesn'= t need to define a new AVP if in the future there was a need to define adde= d values beyond the 5 (plus some fudge factor) already mentioned on the lis= t. 2) sets of users. previous work (e.g., rfc-4412, rfc-6710) recognized that= there can be several sets of users/services that are distinct from each ot= her and yet need to prioritize the traffic. I bring this up because the dr= aft already identifies two sets of users in sections 5.1 and 5.2 (note: I'm= assuming that the latter is aimed at the general public and related to 911= /112/999 type calls, which should probably be more specific in the draft). = And there is also the potential of Firstnet users in the US. As a side note, the distinction and separation of general public and other = prioritized users in public phone infrastructures is not exclusive to the U= S, so the group should not be concerned that this is a US centric effort. = There has been GTPS in the UK, as well as other systems in other countries.= The RFC is a bit dated, but feel free to go over rfc-4190 for added backg= round. and just to reiterate. I'm not making recommendations in the above - just = bringing up some food for thought. -ken On Oct 14, 2015, at 10:12 AM, Steve Donovan > wrote: Jay, The current text is a SHOULD level requirement: When there is a mix of transactions specifying priority in request messages and transactions that do not have the priority specified, transactions that do not have a specified priority SHOULD be treated as having the PRIORITY_14 priority. As such, operators can choose to either not implement a priority or define = a different value for their network. I propose adding the following note after this paragraph to further explain= why it is a SHOULD and not a MUST: Note: There are scenarios where operators might want to specify a different default value for transactions that do not have an explicit priority. In this case, the operator defined local policy would override the use of PRIORITY_14 as the default priority. This leaves the ability for there to be deterministic behavior in Diameter = networks that require a default to be defined and are happy with the specif= ied default. It also gives operators the ability to define a different beh= avior, most likely with some priority handling/mapping at the edge of the n= etwork. Does this address your concerns? Regards, Steve On 10/14/15 2:59 AM, Lee, Jay wrote: Regarding the issue of whether we need to specify a default value or not, t= here are pros and cons. If we specify a value for the default case, we can see the benefits in scen= arios between different operator networks, but we take away important optio= ns on what operators can do with priority values. On the other hand, if we = do not specify the default value, operators may have more options, but ther= e is a question of what to do for this inter-PLMN cases when the networks m= ay use different default values. In practice, this issue can be addressed at the edge of the network, where = Diameter edge agent (DEA) can perform some priority mapping based on bilate= ral roaming agreement (or SLA (service level agreement)) and other means to= insure the proper handling. One may argue that this is not as good as the = 'deterministic' case, but operator should be able handle this in a reasonab= le way. We are fully aware of the fact that, in case of this 'non-determini= stic' case, the default value can differ from one operator network to anoth= er, and it becomes difficult to guarantee the intended priority handling. D= espite this, we still prefer giving options to operators by not specifying = the default value. What we are saying here, however, is not anything new. This is the typical = way of handling priority levels. If anything, specifying the default value = would be something new. As already mentioned in CT discussion, there is a g= ood example of this - Internet QoS, more specifically DiffServ. In order to guarantee end-to-end QoS for a specific service, IETF could hav= e specified a value (DiffServ codepoint) for the specific service to have p= redetermined handling of the traffic, but IETF did not. Instead, DiffServ s= imply provided a framework for operators to have its own classification an= d differentiated treatment of the services. To guarantee end-to-end QoS acr= oss different networks, then, operators need to do packet inspection, (re)c= lassification, QoS mapping, use of SLA and possibly others at the edge of n= etwork (edge router). Therefore, in the DiffServ architecture, intelligence= was pushed to the edge of the network. While the end results may not be gu= aranteed as well as in the case of predetermined handling, it was still a p= referred way to give flexibility to operators. My point is that we went thr= ough all these troubles to give options of priority handling to operators. By the way, if we are thinking of possibility of specifying the default val= ue, are we assuming that all operators are interested in this feature (defa= ult value in the middle, and high and low priorities at other ends)? Aren't= there other operators who are not interested in this feature? I know that = at least there is one - Verizon. We have no interest in this feature, and n= o plan for implementing it. We are OK, if other operators are interested in= this feature, and the default value is NOT specified. But we are certainly= not happy if DIME is trying to impose this on us. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, October 13, 2015 10:55 AM To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org; Pollini, Gregory P Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Assuming that we define a range of 3 values, Assuming that 0 is the lowest priority and 2 the highest, Assuming that an agent receives 4 messages at the same time while being in = overload control: * 1) ULR with Prio-0 * 2) ULR with Prio-1 * 3) ULR with Prio-2 * 4) ULR with no priority AVP Assuming that the default is locally defined as proposed below, How do you know that the ULR with priority 2 will be handled with a higher = priority than the request without priority indication? And what about ULR message with priority 1 with two levels of highest prior= ity e.g. emergency/Important and government/very important? Sorry if the answer is obvious but I fail to understand. Lionel De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] Envoy=E9 : samedi 3 octobre 2015 01:21 =C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C Cc : DiME; dime@ietf.org; Pollini, Gregory P Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels Hello all, Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.21= 2 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defi= ned. Having 15 rather than 16 would be useful from an interworking point of view= on Diameter interfaces connecting to the EPS. Also, my understanding has been that the default value is per local policy. My 2 cents.... Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf = of lionel.morand@orange.com [lionel.morand= @orange.com] Sent: Thursday, October 01, 2015 3:36 AM To: Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Hi, I think that the case "no Priority indication in request" is the default si= tuation today. So if we agree that it should be possible to explicitly indicate a request = with a lower priority, we should divide the range of priority values in thr= ee sub-ranges: [lower priorities][no priority indication][higher priorities= ], e.g. with 17 values: [0-7][8][9-16]. If any operator can freely fix the default value, there would be no way to = ensure the sender that a request with a specific priority value (e.g. 6) wi= ll be handled with a lower or higher priority than a request with no priori= ty indication. Therefore, for a deterministic handling mechanism, I think that it is then = more relevant to define a standard value for the default value. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn Envoy=E9 : mercredi 30 septembre 2015 22:53 =C0 : DOLLY, MARTIN C Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels Same here. The "default priority" should be a matter of local policy. Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "DOLLY, MARTIN C" > To: Steve Donovan >, "dime@ietf.org" > Date: 09/30/2015 04:40 PM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" = > ________________________________ Me as well From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, September 30, 2015 4:38 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels I'm okay with Jay's proposal on not specifying a default value. Steve On 9/30/15 3:27 PM, Lee, Jay wrote: Hi Steve and all, For the first proposal, as I indicated, I support increasing the number of = priority levels up to 16. I am also fine with the second proposal. My question is: do we need to mand= ate this feature, as individual operators have different situations? Perhap= s some flexibility should be allowed? Instead of mandating it, we can inclu= de the statement that when there is no DRMP AVP, this correspond to 'normal= traffic' without a particular high or low priority. Then each operator can= map this default to a value (e.g., 8 or something else) that they feel app= ropriate. Thanks, Jay _______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_E194C2E18676714DACA9C3A2516265D29D463A7CFR712WXCHMBA12z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 <= /p>

1.  &= nbsp;    PRIORITY_14 as de= fault priority value only allows one level of lower priority (PRIORITY_15) =  than the default one; this seems not enough.  As use cases, we may have  some Machine type Communication (LTC) devices tha= t may have lower priorities that normal communications without priority. &n= bsp;Even within a Diameter application, some commands may have a lower prio= rity as having a secundary importance.

 

Then which default  value ?

- = ;         it could be PRIOR= ITY_8 in the middle, or if we prefer to have a  larger range for highe= r priorities  than for lower priorities,  the default value could be  e.g. PRIORITY_10,  giving 9 higher priorities and 5 lo= wer priorities than the default one. I would have a preference for this val= ue PRIORITY_10.

 <= /p>

2.  &= nbsp;    About extensibili= ty, the current range of 16 values is already large, but we can have  = a reserved value to indicate a further extension. With  an enumerated AVP, there is no possibility to add new values. 

 <= /p>

3.  &= nbsp;    I also had a look= to some other IETF RFCs addressing priorities that Ken mentioned, so to se= e if we can benefit from these approaches although done for different contexts.

- = ;         in RFC 4412 (Reso= urce-Priority Header in SIP), wps and ets namespaces have a range of 5 valu= es (0 to 4) with 0 as the highest priority  . But I have not found some indication  (I may have missed it) about the default p= riority  (I mean a SIP request without  Resource-Priority Header = compared  to a SIP request with the Header). Implicitly, I would assum= e a SIP request without  Resource-Priority Header corresponds to  the lowest priority.  DRMP has a similar approach but with&n= bsp; a larger range and also lower priorities.

 <= /p>

- = ;         RFC  6710 (p= riority for SMTP),  uses another encoding of the priority values with = an integer between -9 and +9. Lower priorities  are negative an higher priority being positive. When a value increases, it means a higher = priority, so the opposite  to DRMP, wps or ets.  But the value 0 = is here naturally the default value. So this is an encoding alternative &nb= sp;to the  Enumerated type of the DRMP AVP which avoids the question of the default value.

Note: RFC  67= 10 also defines some Priority Assignment Policies using a subset of the ran= ge.

 <= /p>

RFC 6710 has also this guideline :

  = ; SMTP servers compliant with this specification are not

  = ; required to support all 19 distinct priority levels (i.e., to treat<= /o:p>

  = ; each priority value as a separate priority), ….  That is, an

  = ; implementation that only supports N priority levels (where N < 19)

  = ; will internally round up a syntactically valid priority value that

  = ; isn't supported to the next higher supported number (or to the=

  = ; highest supported priority, if the value is higher than any supported pri= ority).

- = ;         This raises the q= uestion to have this type of  guideline if considered useful.

 

So to have your feedback

 <= /p>

Best regards

 <= /p>

JJacques

 <= /p>

De : DiME [mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C
Envoy=E9 : jeudi 15 octobre 2015 12:33
=C0 : Lee, Jay; ken carlberg; Steve Donovan
Cc : dime@ietf.org
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime= ] #92 (drmp): Range of priority levels)

 

A couple thoughts:

1. &n= bsp;    There needs to be a default value defined= by the standard, so that equipment have the same value leaving the factory=

2. &n= bsp;    This value can be over written based on l= ocal policy

3. &n= bsp;    Should have an extensibility bit in order= to and more values in the future

 <= /p>

 <= /p>

From: DiME [= mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay
Sent: Thursday, October 15, 2015 6:16 AM
To: ken carlberg <carlberg= @g11.org.uk>; Steve Donovan <srdonovan@usdonovans.com>
Cc: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

From my side, some more d= iscussion on Steve’s mail may be needed.

 <= /p>

‘Should’ vs. = ‘Must’:

One can say that ‘S= hould’ is not mandatory. But, in practice, this is a fairly strong st= atement, and often taken as required. So in this sense, the proposed Note is certainly helpful. But, since we allow operators to override the v= alue, I don’t see the reason why we use ‘Should’. My sugg= estion is using ‘May’.

 <= /p>

PRIORITY_14 priority:

Since operators can overw= rite it, I was not too concerned about it. But if we want to put some value= , why ‘14’? A value lower than 14 is suggested in order to allow more rooms for lower priorities.

 <= /p>

Jay

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg
Sent: Wednesday, October 14, 2015 8:40 AM
To: Steve Donovan
Cc: dime@ietf.org
Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (d= rmp): Range of priority levels)

 

with respect to the diff-serv example brought up bel= ow, some thing to add to that discussion is that it starts off with separat= e and distinct forwarding behavior whose marked packets provide segmentatio= n of other IP traffic.  The availability of only 6 bits to play with (along with the headaches of transitive trust)= also discouraged a line of thought to define end-to-end priority handling = versus a per diff-serv domain treatment.  RFC-4594 did provide configu= ration guidelines, but that’s a different story.

 

So back to a couple of ideas to consider.=

 

1) reserved space.  if we go back to the diff-s= erv model, the diff-serv working group agreed to set aside a set of values = that was reserved for experimental use that could be re-assigned some time = in the future.  I’m not suggesting that there should be space set side for experiments, but rather it may be prude= nt to set aside a reserved set of bits/values so that one doesn't need to d= efine a new AVP if in the future there was a need to define added values be= yond the 5 (plus some fudge factor) already mentioned on the list. 

 

2) sets of users.  previous work (e.g., rfc-441= 2, rfc-6710) recognized that there can be several sets of users/services th= at are distinct from each other and yet need to prioritize the traffic. &nb= sp;I bring this up because the draft already identifies two sets of users in sections 5.1 and 5.2 (note: I’m assu= ming that the latter is aimed at the general public and related to 911/112/= 999 type calls, which should probably be more specific in the draft).  = ;And there is also the potential of Firstnet users in the US.

 

As a side note, the distinction and separation of ge= neral public and other prioritized users in public phone infrastructures is= not exclusive to the US, so the group should not be concerned that this is= a US centric effort.  There has been GTPS in the UK, as well as other systems in other countries.  The RFC= is a bit dated, but feel free to go over rfc-4190 for added background.

 

and just to reiterate.  I’m not making re= commendations in the above — just bringing up some food for thought.<= o:p>

 

-ken

 

 

On Oct 14, 2015, at 10:12 AM, Steve Donovan <srdonovan@usdonovans.com> wr= ote:

 

Jay,

The current text is a SHOULD level require= ment:

   When there is a mix of transa= ctions specifying priority in request
   messages and transactions tha= t do not have the priority specified,
   transactions that do not have= a specified priority SHOULD be treated
   as having the PRIORITY_14 pri= ority.

As such, operators can choose to either no= t implement a priority or define a different value for their network.

I propose adding the following note after = this paragraph to further explain why it is a SHOULD and not a MUST:=

      Note: There= are scenarios where operators might want to 
      specify a d= ifferent default value for transactions that do not
      have an exp= licit priority.  In this case, the operator defined
      local polic= y would override the use of PRIORITY_14 as
      the default= priority.

This leaves the ability for there to be de= terministic behavior in Diameter networks that require a default to be defi= ned and are happy with the specified default.  It also gives operators= the ability to define a different behavior, most likely with some priority handling/mapping at the edge of the network= .

Does this address your concerns?
Regards,

Steve

On 10/14/15= 2:59 AM, Lee, Jay wrote:

From: DiME [mai= lto:dime-bounces@ietf.org]=  On Behalf Of lionel.morand@orange.com
Sent: Tuesday, Oct= ober 13, 2015 10:55 AM
To: Shaikh, Viqar = A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; = dime@ietf.org; Pollini, Gregory P Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 

=B7     &nb= sp; 1) ULR with Prio-0

=B7     &nb= sp; 2) ULR with Prio-1

=B7     &nb= sp; 3) ULR with Prio-2

=B7     &nb= sp; 4) ULR with no priority AVP

De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] 
Envoy=E9 : sa= medi 3 octobre 2015 01:21
=C0 : MORAND = Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; dime@ietf.org; Pollini, Grego= ry P
Objet : RE: [= Dime] [dime] #92 (drmp): Range of priority levels

 <= /span>

Hello all,

 

Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS= 29.212 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined.

 

Having 15 rather than 16 would be useful from an interworking point of vie= w on Diameter interfaces connecting to the EPS.  

 

Also, my understanding has been that the default value is per local p= olicy. 

 

My 2 cents....

Viqar 

<= span lang=3D"FR" style=3D"font-size:10.0pt;font-family:"Tahoma",&= quot;sans-serif"">From: DiME [dim= e-bounces@ietf.org] on behalf of lionel.morand@orange.com [<= span style=3D"color:purple">lionel.morand@orange.com]
Sent: Thursday, Oc= tober 01, 2015 3:36 AM
To: Janet P Gunn; = DOLLY, MARTIN C
Cc: DiME; = dime@ietf.org
Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

De : DiME [mai= lto:dime-bounces@ietf.org]=  De la part de&nbs= p;Janet P Gunn
Envoy=E9 : me= rcredi 30 septembre 2015 22:53
=C0 : DOLLY, = MARTIN C
Cc : DiME; dime@ietf.org
Objet : Re: [= Dime] [dime] #92 (drmp): Range of priority levels

 <= /span>

= Same here.  The "default priority" should be a matter of loc= al policy.&n= bsp;

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose. 



From:        = ;"DOLLY, MARTIN C" <md3135@att.com= > 
To:        <= /span>Steve Donovan <srdonovan@usdonovans.com= >, "dime@ietf.org" <dime@ietf.org> <= /span>
Date:        = ;09/30/2015 04:40 PM =
Subject:       &n= bsp;Re: [Dime] [dime] #92 (drmp): Range of pri= ority levels=  
Sent by:       &n= bsp;"DiME" <dime-bou= nces@ietf.org>




Me as well 
  
From: DiME [mailto:dime-bounces@ietf.org]&n= bsp;On Behalf Of Steve Dono= van
Sent: Wednesday, Sept= ember 30, 2015 4:38 PM
To: dime@ietf.or= g
Subject: Re: [Dime] [= dime] #92 (drmp): Range of priority levels 
  
I'm okay with Jay's proposal on not specify= ing a default value.

Steve <= /span>
On 9/30/15 3:27 PM, Lee, Jay wrote:<= span class=3D"apple-converted-space"> =
Hi Steve and all, =
  
For the first proposal, as I indicated, I s= upport increasing the number of priority levels up to 16. 
  
I am also fine with the second proposal. My= question is: do we need to mandate this feature, as individual operators h= ave different situations? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that whe= n there is no DRMP AVP, this correspond to ‘normal traffic’ wit= hout a particular high or low priority. Then each operator can map this def= ault to a value (e.g., 8 or something else) that they feel appropriate. 
  
Thanks, 
  
Jay 



_______________________= ________________________ 
DiME mailing list 
DiME@ietf.org 
https://www.ietf.org/mailman/li= stinfo/dime   _____________= __________________________________
DiME mailing list
DiME@ietf.org<= /span>
https://ww= w.ietf.org/mailman/listinfo/dime

_________________________=
___________________________________________________________________________=
_____________________
 <=
/pre>

Ce message et ses pieces =
jointes peuvent contenir des informations confidentielles ou privilegiees e=
t ne doivent donc


pas etre diffuses, exploi=
tes ou copies sans autorisation. Si vous avez recu ce message par erreur, v=
euillez le signaler


a l'expediteur et le detr=
uire ainsi que les pieces jointes. Les messages electroniques etant suscept=
ibles d'alteration,


Orange decline toute resp=
onsabilite si ce message a ete altere, deforme ou falsifie. Merci.


 <=
/pre>

This message and its atta=
chments may contain confidential or privileged information that may be prot=
ected by law;


they should not be distri=
buted, used or copied without authorisation.


If you have received this=
 email in error, please notify the sender and delete this message and its a=
ttachments.


As emails may be altered,=
 Orange is not liable for messages that have been modified, changed or fals=
ified.


Thank you.


_________________________=
___________________________________________________________________________=
_____________________
 <=
/pre>

Ce message et ses pieces =
jointes peuvent contenir des informations confidentielles ou privilegiees e=
t ne doivent donc


pas etre diffuses, exploi=
tes ou copies sans autorisation. Si vous avez recu ce message par erreur, v=
euillez le signaler


a l'expediteur et le detr=
uire ainsi que les pieces jointes. Les messages electroniques etant suscept=
ibles d'alteration,


Orange decline toute resp=
onsabilite si ce message a ete altere, deforme ou falsifie. Merci.


 <=
/pre>

This message and its atta=
chments may contain confidential or privileged information that may be prot=
ected by law;


they should not be distri=
buted, used or copied without authorisation.


If you have received this=
 email in error, please notify the sender and delete this message and its a=
ttachments.


As emails may be altered,=
 Orange is not liable for messages that have been modified, changed or fals=
ified.


Thank you.


 


___________________________________________=
____


DiME mailing list


DiME@ietf.org


https://www.ietf.org/mailman/listi=
nfo/dime





__________________________________________=
_____

DiME mailing list

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime=

 

--_000_E194C2E18676714DACA9C3A2516265D29D463A7CFR712WXCHMBA12z_-- From nobody Thu Oct 22 14:38:05 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E56B1B3051; Thu, 22 Oct 2015 14:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5O_FcYA5fv9C; Thu, 22 Oct 2015 14:37:54 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEE11B42B7; Thu, 22 Oct 2015 14:37:54 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9CE3518046F; Thu, 22 Oct 2015 14:37:16 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20151022213716.9CE3518046F@rfc-editor.org> Date: Thu, 22 Oct 2015 14:37:16 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] RFC 7678 on Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 21:38:01 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7678 Title: Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions Author: C. Zhou, T. Taylor, Q. Sun, M. Boucadair Status: Standards Track Stream: IETF Date: October 2015 Mailbox: cathy.zhou@huawei.com, tom.taylor.stds@gmail.com, sunqiong@ctbri.com.cn, mohamed.boucadair@orange.com Pages: 23 Characters: 49074 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dime-4over6-provisioning-06.txt URL: https://www.rfc-editor.org/info/rfc7678 DOI: http://dx.doi.org/10.17487/RFC7678 During the transition from IPv4 to IPv6, customer equipment may have to support one of the various transition methods that have been defined for carrying IPv4 packets over IPv6. This document enumerates the information that needs to be provisioned on a customer edge router to support a list of transition techniques based on tunneling IPv4 in IPv6, with a view to defining reusable components for a reasonable transition path between these techniques. To the extent that the provisioning is done dynamically, Authentication, Authorization, and Accounting (AAA) support is needed to provide the information to the network server responsible for passing the information to the customer equipment. This document specifies Diameter (RFC 6733) Attribute-Value Pairs (AVPs) to be used for that purpose. This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Oct 22 22:59:42 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77941B3299 for ; Thu, 22 Oct 2015 22:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8YDJOFrPwHb for ; Thu, 22 Oct 2015 22:59:28 -0700 (PDT) Received: from eris.verizonwireless.com (eris.verizonwireless.com [137.188.99.119]) by ietfa.amsl.com (Postfix) with ESMTP id 9223C1B3292 for ; Thu, 22 Oct 2015 22:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizonwireless.com; i=@verizonwireless.com; q=dns/txt; s=prodmail; t=1445579967; x=1477115967; h=from:to:subject:date:references:in-reply-to:mime-version; bh=aX9X460T23LIuoOovxS8twWFGRUWkYA9jJYK/3RfR1c=; b=GQe2iM7qpmpTON7RXg1GHJgd7vuGASfeOr4dooamg+BEbUAc0AYtucL7 no5ccKxYweJQIkuHH30ap3rNO2VzM698lSO5AVZTgaq/p3wrO3cT6Gr3A p2YvgB5nKZcICHHUySnD2SmJZcAmSvbGzOe/7U/via7vfL29cbQScc2Uq M=; X-Host: endeavour.tdc.vzwcorp.com Received: from casac1exh001.uswin.ad.vzwcorp.com ([10.11.218.43]) by eris.verizonwireless.com with ESMTP/TLS/AES128-SHA; 23 Oct 2015 01:59:25 -0400 Received: from CASAC1EXP009.uswin.ad.vzwcorp.com ([fe80::558c:d7cc:1a42:f4d6]) by CASAC1EXH001.uswin.ad.vzwcorp.com ([::1]) with mapi id 14.03.0146.000; Thu, 22 Oct 2015 22:59:24 -0700 From: "Lee, Jay" To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" Thread-Topic: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) Thread-Index: AQHRBzKIwn0SbO3rXUW/ebDof+lRcp5sOcGAgAtoZjCAAPy+AA== Date: Fri, 23 Oct 2015 05:59:23 +0000 References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> <20151014075941.062E21B2C1F@ietfa.amsl.com> <561E62C9.20500@usdonovans.com> <1431d0b2-5ae7-426e-b5ff-42b23fecbee5@CASAC1EXH002.uswin.ad.vzwcorp.com> <20151015101558.111761ACD5C@ietfa.amsl.com> <3e7a25c8-5eea-49a5-9905-3009c4dc45b8@NYORA1HUB001.uswin.ad.vzwcorp.com> In-Reply-To: <3e7a25c8-5eea-49a5-9905-3009c4dc45b8@NYORA1HUB001.uswin.ad.vzwcorp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.11.60.250] Content-Type: multipart/alternative; boundary="_000_C026C31E3CD6CA43953D6D95AB480480039FFBCASAC1EXP009uswin_" MIME-Version: 1.0 Message-Id: <20151023055927.9223C1B3292@ietfa.amsl.com> Archived-At: Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2015 05:59:41 -0000 --_000_C026C31E3CD6CA43953D6D95AB480480039FFBCASAC1EXP009uswin_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Some further comments from my side: */ If we need to assign (but not specify) a value to the default case, we n= eed to make it clear that this value can be overwritten by operators, and t= he value is for some use cases like e.g., equipment having the same value w= hen leaving the factory, so that there would be no misunderstanding. */ Since we agree that the default value is per local policy, 'May' is pref= erred to 'Should' in order not to cause confusion. */ For assignment of the default value, I am quite open. But any value betw= een 9 - 12 seems reasonable to me. */ Current proposal of 16 values may be enough now, but I am fine with hav= ing an extensibility bit to be future proof. */ I am not sure of alternative encoding method (say, +9 to -9 per JJacques= ' proposal) compared to the current enumerated type of DRMP. It offers a lo= gical way of assigning a value 0 to the default case. But it offers less fl= exibility to operators, since the default value may not be easily moved to = have more higher/lower priority values. Also, we are used to the enumerated= type of DRMP and just want to have extension from 5 to 16, but this may r= equire more deviation from the current design and thinking. For this, I wou= ld like to see more on qualitative pros/cons, but, given its little benefit= , I am reluctant to accept this alternative. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: Thursday, October 22, 2015 9:39 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Hi 1. PRIORITY_14 as default priority value only allows one level of low= er priority (PRIORITY_15) than the default one; this seems not enough. As= use cases, we may have some Machine type Communication (LTC) devices that= may have lower priorities that normal communications without priority. Ev= en within a Diameter application, some commands may have a lower priority a= s having a secundary importance. Then which default value ? - it could be PRIORITY_8 in the middle, or if we prefer to have a = larger range for higher priorities than for lower priorities, the defaul= t value could be e.g. PRIORITY_10, giving 9 higher priorities and 5 lower= priorities than the default one. I would have a preference for this value = PRIORITY_10. 2. About extensibility, the current range of 16 values is already lar= ge, but we can have a reserved value to indicate a further extension. With= an enumerated AVP, there is no possibility to add new values. 3. I also had a look to some other IETF RFCs addressing priorities th= at Ken mentioned, so to see if we can benefit from these approaches althoug= h done for different contexts. - in RFC 4412 (Resource-Priority Header in SIP), wps and ets names= paces have a range of 5 values (0 to 4) with 0 as the highest priority . B= ut I have not found some indication (I may have missed it) about the defau= lt priority (I mean a SIP request without Resource-Priority Header compar= ed to a SIP request with the Header). Implicitly, I would assume a SIP req= uest without Resource-Priority Header corresponds to the lowest priority.= DRMP has a similar approach but with a larger range and also lower prior= ities. - RFC 6710 (priority for SMTP), uses another encoding of the pri= ority values with an integer between -9 and +9. Lower priorities are negat= ive an higher priority being positive. When a value increases, it means a h= igher priority, so the opposite to DRMP, wps or ets. But the value 0 is h= ere naturally the default value. So this is an encoding alternative to the= Enumerated type of the DRMP AVP which avoids the question of the default = value. Note: RFC 6710 also defines some Priority Assignment Policies using a subs= et of the range. RFC 6710 has also this guideline : SMTP servers compliant with this specification are not required to support all 19 distinct priority levels (i.e., to treat each priority value as a separate priority), .... That is, an implementation that only supports N priority levels (where N < 19) will internally round up a syntactically valid priority value that isn't supported to the next higher supported number (or to the highest supported priority, if the value is higher than any supported pr= iority). - This raises the question to have this type of guideline if cons= idered useful. So to have your feedback Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C Envoy=E9 : jeudi 15 octobre 2015 12:33 =C0 : Lee, Jay; ken carlberg; Steve Donovan Cc : dime@ietf.org Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp)= : Range of priority levels) A couple thoughts: 1. There needs to be a default value defined by the standard, so that = equipment have the same value leaving the factory 2. This value can be over written based on local policy 3. Should have an extensibility bit in order to and more values in the= future From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay Sent: Thursday, October 15, 2015 6:16 AM To: ken carlberg >; Steve D= onovan > Cc: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) >From my side, some more discussion on Steve's mail may be needed. 'Should' vs. 'Must': One can say that 'Should' is not mandatory. But, in practice, this is a fai= rly strong statement, and often taken as required. So in this sense, the pr= oposed Note is certainly helpful. But, since we allow operators to override= the value, I don't see the reason why we use 'Should'. My suggestion is us= ing 'May'. PRIORITY_14 priority: Since operators can overwrite it, I was not too concerned about it. But if = we want to put some value, why '14'? A value lower than 14 is suggested in = order to allow more rooms for lower priorities. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg Sent: Wednesday, October 14, 2015 8:40 AM To: Steve Donovan Cc: dime@ietf.org Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): R= ange of priority levels) with respect to the diff-serv example brought up below, some thing to add t= o that discussion is that it starts off with separate and distinct forwardi= ng behavior whose marked packets provide segmentation of other IP traffic. = The availability of only 6 bits to play with (along with the headaches of = transitive trust) also discouraged a line of thought to define end-to-end p= riority handling versus a per diff-serv domain treatment. RFC-4594 did pro= vide configuration guidelines, but that's a different story. So back to a couple of ideas to consider. 1) reserved space. if we go back to the diff-serv model, the diff-serv wor= king group agreed to set aside a set of values that was reserved for experi= mental use that could be re-assigned some time in the future. I'm not sugg= esting that there should be space set side for experiments, but rather it m= ay be prudent to set aside a reserved set of bits/values so that one doesn'= t need to define a new AVP if in the future there was a need to define adde= d values beyond the 5 (plus some fudge factor) already mentioned on the lis= t. 2) sets of users. previous work (e.g., rfc-4412, rfc-6710) recognized that= there can be several sets of users/services that are distinct from each ot= her and yet need to prioritize the traffic. I bring this up because the dr= aft already identifies two sets of users in sections 5.1 and 5.2 (note: I'm= assuming that the latter is aimed at the general public and related to 911= /112/999 type calls, which should probably be more specific in the draft). = And there is also the potential of Firstnet users in the US. As a side note, the distinction and separation of general public and other = prioritized users in public phone infrastructures is not exclusive to the U= S, so the group should not be concerned that this is a US centric effort. = There has been GTPS in the UK, as well as other systems in other countries.= The RFC is a bit dated, but feel free to go over rfc-4190 for added backg= round. and just to reiterate. I'm not making recommendations in the above - just = bringing up some food for thought. -ken On Oct 14, 2015, at 10:12 AM, Steve Donovan > wrote: Jay, The current text is a SHOULD level requirement: When there is a mix of transactions specifying priority in request messages and transactions that do not have the priority specified, transactions that do not have a specified priority SHOULD be treated as having the PRIORITY_14 priority. As such, operators can choose to either not implement a priority or define = a different value for their network. I propose adding the following note after this paragraph to further explain= why it is a SHOULD and not a MUST: Note: There are scenarios where operators might want to specify a different default value for transactions that do not have an explicit priority. In this case, the operator defined local policy would override the use of PRIORITY_14 as the default priority. This leaves the ability for there to be deterministic behavior in Diameter = networks that require a default to be defined and are happy with the specif= ied default. It also gives operators the ability to define a different beh= avior, most likely with some priority handling/mapping at the edge of the n= etwork. Does this address your concerns? Regards, Steve On 10/14/15 2:59 AM, Lee, Jay wrote: Regarding the issue of whether we need to specify a default value or not, t= here are pros and cons. If we specify a value for the default case, we can see the benefits in scen= arios between different operator networks, but we take away important optio= ns on what operators can do with priority values. On the other hand, if we = do not specify the default value, operators may have more options, but ther= e is a question of what to do for this inter-PLMN cases when the networks m= ay use different default values. In practice, this issue can be addressed at the edge of the network, where = Diameter edge agent (DEA) can perform some priority mapping based on bilate= ral roaming agreement (or SLA (service level agreement)) and other means to= insure the proper handling. One may argue that this is not as good as the = 'deterministic' case, but operator should be able handle this in a reasonab= le way. We are fully aware of the fact that, in case of this 'non-determini= stic' case, the default value can differ from one operator network to anoth= er, and it becomes difficult to guarantee the intended priority handling. D= espite this, we still prefer giving options to operators by not specifying = the default value. What we are saying here, however, is not anything new. This is the typical = way of handling priority levels. If anything, specifying the default value = would be something new. As already mentioned in CT discussion, there is a g= ood example of this - Internet QoS, more specifically DiffServ. In order to guarantee end-to-end QoS for a specific service, IETF could hav= e specified a value (DiffServ codepoint) for the specific service to have p= redetermined handling of the traffic, but IETF did not. Instead, DiffServ s= imply provided a framework for operators to have its own classification an= d differentiated treatment of the services. To guarantee end-to-end QoS acr= oss different networks, then, operators need to do packet inspection, (re)c= lassification, QoS mapping, use of SLA and possibly others at the edge of n= etwork (edge router). Therefore, in the DiffServ architecture, intelligence= was pushed to the edge of the network. While the end results may not be gu= aranteed as well as in the case of predetermined handling, it was still a p= referred way to give flexibility to operators. My point is that we went thr= ough all these troubles to give options of priority handling to operators. By the way, if we are thinking of possibility of specifying the default val= ue, are we assuming that all operators are interested in this feature (defa= ult value in the middle, and high and low priorities at other ends)? Aren't= there other operators who are not interested in this feature? I know that = at least there is one - Verizon. We have no interest in this feature, and n= o plan for implementing it. We are OK, if other operators are interested in= this feature, and the default value is NOT specified. But we are certainly= not happy if DIME is trying to impose this on us. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, October 13, 2015 10:55 AM To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org; Pollini, Gregory P Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Assuming that we define a range of 3 values, Assuming that 0 is the lowest priority and 2 the highest, Assuming that an agent receives 4 messages at the same time while being in = overload control: * 1) ULR with Prio-0 * 2) ULR with Prio-1 * 3) ULR with Prio-2 * 4) ULR with no priority AVP Assuming that the default is locally defined as proposed below, How do you know that the ULR with priority 2 will be handled with a higher = priority than the request without priority indication? And what about ULR message with priority 1 with two levels of highest prior= ity e.g. emergency/Important and government/very important? Sorry if the answer is obvious but I fail to understand. Lionel De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] Envoy=E9 : samedi 3 octobre 2015 01:21 =C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C Cc : DiME; dime@ietf.org; Pollini, Gregory P Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels Hello all, Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.21= 2 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defi= ned. Having 15 rather than 16 would be useful from an interworking point of view= on Diameter interfaces connecting to the EPS. Also, my understanding has been that the default value is per local policy. My 2 cents.... Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf = of lionel.morand@orange.com [lionel.morand= @orange.com] Sent: Thursday, October 01, 2015 3:36 AM To: Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Hi, I think that the case "no Priority indication in request" is the default si= tuation today. So if we agree that it should be possible to explicitly indicate a request = with a lower priority, we should divide the range of priority values in thr= ee sub-ranges: [lower priorities][no priority indication][higher priorities= ], e.g. with 17 values: [0-7][8][9-16]. If any operator can freely fix the default value, there would be no way to = ensure the sender that a request with a specific priority value (e.g. 6) wi= ll be handled with a lower or higher priority than a request with no priori= ty indication. Therefore, for a deterministic handling mechanism, I think that it is then = more relevant to define a standard value for the default value. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn Envoy=E9 : mercredi 30 septembre 2015 22:53 =C0 : DOLLY, MARTIN C Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels Same here. The "default priority" should be a matter of local policy. Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "DOLLY, MARTIN C" > To: Steve Donovan >, "dime@ietf.org" > Date: 09/30/2015 04:40 PM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" = > ________________________________ Me as well From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, September 30, 2015 4:38 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels I'm okay with Jay's proposal on not specifying a default value. Steve On 9/30/15 3:27 PM, Lee, Jay wrote: Hi Steve and all, For the first proposal, as I indicated, I support increasing the number of = priority levels up to 16. I am also fine with the second proposal. My question is: do we need to mand= ate this feature, as individual operators have different situations? Perhap= s some flexibility should be allowed? Instead of mandating it, we can inclu= de the statement that when there is no DRMP AVP, this correspond to 'normal= traffic' without a particular high or low priority. Then each operator can= map this default to a value (e.g., 8 or something else) that they feel app= ropriate. Thanks, Jay _______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_C026C31E3CD6CA43953D6D95AB480480039FFBCASAC1EXP009uswin_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Some further comments fro= m my side:

 <= /p>

*/ If we need to assign (= but not specify) a value to the default case, we need to make it clear that= this value can be overwritten by operators, and the value is for some use cases like e.g., equipment having the same value when leav= ing the factory, so that there would be no misunderstanding.

 <= /p>

*/ Since we agree that th= e default value is per local policy, ‘May’ is preferred to R= 16;Should’ in order not to cause confusion.

 <= /p>

*/ For assignment of the = default value, I am quite open. But any value between 9 – 12 seems re= asonable to me.

 <= /p>

*/  Current proposal= of 16 values may be enough now, but I am fine with having an extensibility= bit to be future proof.

 <= /p>

*/ I am not sure of alter= native encoding method (say, +9 to -9 per JJacques’ proposal) com= pared to the current enumerated type of DRMP. It offers a logical way of assigning a value 0 to the default case. But it offers less flexibi= lity to operators, since the default value may not be easily moved to have = more higher/lower priority values. Also, we are used to the enumerated type= of DRMP and just want to have extension from 5 to 16,  but this may require more deviation from the current d= esign and thinking. For this, I would like to see more on qualitative pros/= cons, but, given its little benefit, I am reluctant to accept this alternat= ive.

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Thursday, October 22, 2015 9:39 AM
To: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Hi

 <= /p>

1.  &= nbsp;    PRIORITY_14 as de= fault priority value only allows one level of lower priority (PRIORITY_15) =  than the default one; this seems not enough.  As use cases, we may have  some Machine type Communication (LTC) devices tha= t may have lower priorities that normal communications without priority. &n= bsp;Even within a Diameter application, some commands may have a lower prio= rity as having a secundary importance.

 

Then which default  value ?

- =          it could be PRIOR= ITY_8 in the middle, or if we prefer to have a  larger range for highe= r priorities  than for lower priorities,  the default value could be  e.g. PRIORITY_10,  giving 9 higher priorities and 5 lo= wer priorities than the default one. I would have a preference for this val= ue PRIORITY_10.

 <= /p>

2.  &= nbsp;    About extensibili= ty, the current range of 16 values is already large, but we can have  = a reserved value to indicate a further extension. With  an enumerated AVP, there is no possibility to add new values. 

 <= /p>

3.  &= nbsp;    I also had a look= to some other IETF RFCs addressing priorities that Ken mentioned, so to se= e if we can benefit from these approaches although done for different contexts.

- =          in RFC 4412 (Reso= urce-Priority Header in SIP), wps and ets namespaces have a range of 5 valu= es (0 to 4) with 0 as the highest priority  . But I have not found some indication  (I may have missed it) about the default p= riority  (I mean a SIP request without  Resource-Priority Header = compared  to a SIP request with the Header). Implicitly, I would assum= e a SIP request without  Resource-Priority Header corresponds to  the lowest priority.  DRMP has a similar approach but with&n= bsp; a larger range and also lower priorities.

 <= /p>

- =          RFC  6710 (p= riority for SMTP),  uses another encoding of the priority values with = an integer between -9 and +9. Lower priorities  are negative an higher priority being positive. When a value increases, it means a higher = priority, so the opposite  to DRMP, wps or ets.  But the value 0 = is here naturally the default value. So this is an encoding alternative &nb= sp;to the  Enumerated type of the DRMP AVP which avoids the question of the default value.

Note: RFC  67= 10 also defines some Priority Assignment Policies using a subset of the ran= ge.

 <= /p>

   SMTP server= s compliant with this specification are not

   required to supp= ort all 19 distinct priority levels (i.e., to treat

   each priority va= lue as a separate priority), ….  That is, an

   implementation t= hat only supports N priority levels (where N < 19)

   will internally = round up a syntactically valid priority value that

   isn't supported = to the next higher supported number (or to the

   highest supporte= d priority, if the value is higher than any supported priority).=

- =          This raises the q= uestion to have this type of  guideline if considered useful.

So to have your feedback

 <= /p>

Best regards

 <= /p>

JJacques

 <= /p>

De : DiME [mailto:d= ime-bounces@ietf.org] De la part de DOLLY, MARTIN C
Envoy=E9 : jeudi 15 octobre 2015 12:33
=C0 : Lee, Jay; ken carlberg; Steve Donovan
Cc : dime@ietf.org
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime= ] #92 (drmp): Range of priority levels)

 

A couple thoughts:

1. &nb= sp;    There needs to be a default value defined= by the standard, so that equipment have the same value leaving the factory=

2. &nb= sp;    This value can be over written based on l= ocal policy

3. &nb= sp;    Should have an extensibility bit in order= to and more values in the future

 <= /p>

 <= /p>

From: DiME [= mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay
Sent: Thursday, October 15, 2015 6:16 AM
To: ken carlberg <carlberg= @g11.org.uk>; Steve Donovan <srdonovan@usdonovans.com>
Cc: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

From my side, some more d= iscussion on Steve’s mail may be needed.

 <= /p>

‘Should’ vs. = ‘Must’:

One can say that ‘S= hould’ is not mandatory. But, in practice, this is a fairly strong st= atement, and often taken as required. So in this sense, the proposed Note is certainly helpful. But, since we allow operators to override the v= alue, I don’t see the reason why we use ‘Should’. My sugg= estion is using ‘May’.

 <= /p>

PRIORITY_14 priority:

Since operators can overw= rite it, I was not too concerned about it. But if we want to put some value= , why ‘14’? A value lower than 14 is suggested in order to allow more rooms for lower priorities.

 <= /p>

Jay

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg
Sent: Wednesday, October 14, 2015 8:40 AM
To: Steve Donovan
Cc: dime@ietf.org
Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (d= rmp): Range of priority levels)

 

with respect to the diff-serv example brought up bel= ow, some thing to add to that discussion is that it starts off with separat= e and distinct forwarding behavior whose marked packets provide segmentatio= n of other IP traffic.  The availability of only 6 bits to play with (along with the headaches of transitive trust)= also discouraged a line of thought to define end-to-end priority handling = versus a per diff-serv domain treatment.  RFC-4594 did provide configu= ration guidelines, but that’s a different story.

 

So back to a couple of ideas to consider.=

 

1) reserved space.  if we go back to the diff-s= erv model, the diff-serv working group agreed to set aside a set of values = that was reserved for experimental use that could be re-assigned some time = in the future.  I’m not suggesting that there should be space set side for experiments, but rather it may be prude= nt to set aside a reserved set of bits/values so that one doesn't need to d= efine a new AVP if in the future there was a need to define added values be= yond the 5 (plus some fudge factor) already mentioned on the list. 

 

2) sets of users.  previous work (e.g., rfc-441= 2, rfc-6710) recognized that there can be several sets of users/services th= at are distinct from each other and yet need to prioritize the traffic. &nb= sp;I bring this up because the draft already identifies two sets of users in sections 5.1 and 5.2 (note: I’m assu= ming that the latter is aimed at the general public and related to 911/112/= 999 type calls, which should probably be more specific in the draft).  = ;And there is also the potential of Firstnet users in the US.

 

As a side note, the distinction and separation of ge= neral public and other prioritized users in public phone infrastructures is= not exclusive to the US, so the group should not be concerned that this is= a US centric effort.  There has been GTPS in the UK, as well as other systems in other countries.  The RFC= is a bit dated, but feel free to go over rfc-4190 for added background.

 

and just to reiterate.  I’m not making re= commendations in the above — just bringing up some food for thought.<= o:p>

 

-ken

 

 

On Oct 14, 2015, at 10:12 AM, Steve Donovan <srdonovan@usdonovans.com> wr= ote:

 

Jay,

The current text is a SHOULD level require= ment:

   When there is a mix of transa= ctions specifying priority in request
   messages and transactions tha= t do not have the priority specified,
   transactions that do not have= a specified priority SHOULD be treated
   as having the PRIORITY_14 pri= ority.

As such, operators can choose to either no= t implement a priority or define a different value for their network.

I propose adding the following note after = this paragraph to further explain why it is a SHOULD and not a MUST:=

      Note: There= are scenarios where operators might want to 
      specify a d= ifferent default value for transactions that do not
      have an exp= licit priority.  In this case, the operator defined
      local polic= y would override the use of PRIORITY_14 as
      the default= priority.

This leaves the ability for there to be de= terministic behavior in Diameter networks that require a default to be defi= ned and are happy with the specified default.  It also gives operators= the ability to define a different behavior, most likely with some priority handling/mapping at the edge of the network= .

Does this address your concerns?
Regards,

Steve

On 10/14/15= 2:59 AM, Lee, Jay wrote:

From: DiME [mai= lto:dime-bounces@ietf.org]=  On Behalf Of lionel.morand@orange.com
Sent: Tuesday, Oct= ober 13, 2015 10:55 AM
To: Shaikh, Viqar = A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; = dime@ietf.org; Pollini, Gregory P Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 

=B7     &nbs= p; 1) ULR with Prio-0

=B7     &nbs= p; 2) ULR with Prio-1

=B7     &nbs= p; 3) ULR with Prio-2

=B7     &nbs= p; 4) ULR with no priority AVP

De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] 
Envoy=E9 : sa= medi 3 octobre 2015 01:21
=C0 : MORAND = Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; dime@ietf.org; Pollini, Grego= ry P
Objet : RE: [= Dime] [dime] #92 (drmp): Range of priority levels

 <= /span>

Hello all,

 

Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS= 29.212 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined.

 

Having 15 rather than 16 would be useful from an interworking point of vie= w on Diameter interfaces connecting to the EPS.  

 

Also, my understanding has been that the default value is per local p= olicy. 

 

My 2 cents....

Viqar 

<= span lang=3D"FR" style=3D"font-size:10.0pt;font-family:"Tahoma",&= quot;sans-serif"">From: DiME [dim= e-bounces@ietf.org] on behalf of lionel.morand@orange.com [<= span style=3D"color:purple">lionel.morand@orange.com]
Sent: Thursday, Oc= tober 01, 2015 3:36 AM
To: Janet P Gunn; = DOLLY, MARTIN C
Cc: DiME; = dime@ietf.org
Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

De : DiME [mai= lto:dime-bounces@ietf.org]=  De la part de&nbs= p;Janet P Gunn
Envoy=E9 : me= rcredi 30 septembre 2015 22:53
=C0 : DOLLY, = MARTIN C
Cc : DiME; dime@ietf.org
Objet : Re: [= Dime] [dime] #92 (drmp): Range of priority levels

 <= /span>

= Same here.  The "default priority" should be a matter of loc= al policy.&n= bsp;

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose. 



From:        = ;"DOLLY, MARTIN C" <md3135@att.com= > 
To:        <= /span>Steve Donovan <srdonovan@usdonovans.com= >, "dime@ietf.org" <dime@ietf.org> <= /span>
Date:        = ;09/30/2015 04:40 PM =
Subject:       &n= bsp;Re: [Dime] [dime] #92 (drmp): Range of pri= ority levels=  
Sent by:       &n= bsp;"DiME" <dime-bou= nces@ietf.org>




Me as well 
  
From: DiME [mailto:dime-bounces@ietf.org]&n= bsp;On Behalf Of Steve Dono= van
Sent: Wednesday, Sept= ember 30, 2015 4:38 PM
To: dime@ietf.or= g
Subject: Re: [Dime] [= dime] #92 (drmp): Range of priority levels 
  
I'm okay with Jay's proposal on not specify= ing a default value.

Steve <= /span>
On 9/30/15 3:27 PM, Lee, Jay wrote:<= span class=3D"apple-converted-space"> =
Hi Steve and all, =
  
For the first proposal, as I indicated, I s= upport increasing the number of priority levels up to 16. 
  
I am also fine with the second proposal. My= question is: do we need to mandate this feature, as individual operators h= ave different situations? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that whe= n there is no DRMP AVP, this correspond to ‘normal traffic’ wit= hout a particular high or low priority. Then each operator can map this def= ault to a value (e.g., 8 or something else) that they feel appropriate. 
  
Thanks, 
  
Jay 



_______________________= ________________________ 
DiME mailing list 
DiME@ietf.org 
https://www.ietf.org/mailman/li= stinfo/dime   _____________= __________________________________
DiME mailing list
DiME@ietf.org<= /span>
https://ww= w.ietf.org/mailman/listinfo/dime

_____________________________________=
___________________________________________________________________________=
_________
 
Ce message et ses pieces jointes peuv=
ent contenir des informations confidentielles ou privilegiees et ne doivent=
 donc
pas etre diffuses, exploites ou copie=
s sans autorisation. Si vous avez recu ce message par erreur, veuillez le s=
ignaler
a l'expediteur et le detruire ainsi q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration,
Orange decline toute responsabilite s=
i ce message a ete altere, deforme ou falsifie. Merci.

 


This message and its attachments may =
contain confidential or privileged information that may be protected by law=
;they should not be distributed, used =
or copied without authorisation.


If you have received this email in er=
ror, please notify the sender and delete this message and its attachments.<=
/span>=



As emails may be altered, Orange is n=
ot liable for messages that have been modified, changed or falsified.=



Thank you.


_____________________________________=
___________________________________________________________________________=
_________
 
Ce message et ses pieces jointes peuv=
ent contenir des informations confidentielles ou privilegiees et ne doivent=
 donc
pas etre diffuses, exploites ou copie=
s sans autorisation. Si vous avez recu ce message par erreur, veuillez le s=
ignaler
a l'expediteur et le detruire ainsi q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration,
Orange decline toute responsabilite s=
i ce message a ete altere, deforme ou falsifie. Merci.

 


This message and its attachments may =
contain confidential or privileged information that may be protected by law=
;they should not be distributed, used =
or copied without authorisation.


If you have received this email in er=
ror, please notify the sender and delete this message and its attachments.<=
/span>=



As emails may be altered, Orange is n=
ot liable for messages that have been modified, changed or falsified.=



Thank you.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.ietf.org/mailman/listinfo/di=
me





__________________________________________=
_____

DiME mailing list

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime=

 

--_000_C026C31E3CD6CA43953D6D95AB480480039FFBCASAC1EXP009uswin_-- From nobody Fri Oct 23 02:01:50 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDE81B3363 for ; Fri, 23 Oct 2015 02:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psuOeqE7gMvX for ; Fri, 23 Oct 2015 02:01:34 -0700 (PDT) Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3341B3362 for ; Fri, 23 Oct 2015 02:01:33 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t9N8shH8021984; Fri, 23 Oct 2015 05:01:31 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 1xqg72gm4y-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Oct 2015 05:01:29 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t9N91Sif018898; Fri, 23 Oct 2015 05:01:29 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t9N91GTb018697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 23 Oct 2015 05:01:25 -0400 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 23 Oct 2015 09:00:59 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.54]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0248.002; Fri, 23 Oct 2015 05:00:59 -0400 From: "DOLLY, MARTIN C" To: "Lee, Jay" , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" Thread-Topic: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) Thread-Index: AQHRBzKJW/2/uK1FRUa1+r4tqwEunZ5sOcGAgAtoZjCAAPy+AIAANLWw Date: Fri, 23 Oct 2015 09:00:58 +0000 Message-ID: References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> <20151014075941.062E21B2C1F@ietfa.amsl.com> <561E62C9.20500@usdonovans.com> <1431d0b2-5ae7-426e-b5ff-42b23fecbee5@CASAC1EXH002.uswin.ad.vzwcorp.com> <20151015101558.111761ACD5C@ietfa.amsl.com> <3e7a25c8-5eea-49a5-9905-3009c4dc45b8@NYORA1HUB001.uswin.ad.vzwcorp.com> <20151023055927.9223C1B3292@ietfa.amsl.com> In-Reply-To: <20151023055927.9223C1B3292@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.107.171] Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E8365615C7B9EAMISOUT7MSGUSRDB_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-10-23_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1510230147 Archived-At: Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2015 09:01:48 -0000 --_000_E42CCDDA6722744CB241677169E8365615C7B9EAMISOUT7MSGUSRDB_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable See inline From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay Sent: Friday, October 23, 2015 1:59 AM To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) ; dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Some further comments from my side: */ If we need to assign (but not specify) a value to the default case, we n= eed to make it clear that this value can be overwritten by operators, and t= he value is for some use cases like e.g., equipment having the same value w= hen leaving the factory, so that there would be no misunderstanding. mcd- ok */ Since we agree that the default value is per local policy, 'May' is pref= erred to 'Should' in order not to cause confusion. mcd-ok */ For assignment of the default value, I am quite open. But any value betw= een 9 - 12 seems reasonable to me. mcd- value should allow for assigning lower values, though a carrier can as= sign what they want in their network, there needs to be a common meaning at= the interconnection point */ Current proposal of 16 values may be enough now, but I am fine with hav= ing an extensibility bit to be future proof. mcd-ok */ I am not sure of alternative encoding method (say, +9 to -9 per JJacques= ' proposal) compared to the current enumerated type of DRMP. It offers a lo= gical way of assigning a value 0 to the default case. But it offers less fl= exibility to operators, since the default value may not be easily moved to = have more higher/lower priority values. Also, we are used to the enumerated= type of DRMP and just want to have extension from 5 to 16, but this may r= equire more deviation from the current design and thinking. For this, I wou= ld like to see more on qualitative pros/cons, but, given its little benefit= , I am reluctant to accept this alternative. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: Thursday, October 22, 2015 9:39 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Hi 1. PRIORITY_14 as default priority value only allows one level of lowe= r priority (PRIORITY_15) than the default one; this seems not enough. As = use cases, we may have some Machine type Communication (LTC) devices that = may have lower priorities that normal communications without priority. Eve= n within a Diameter application, some commands may have a lower priority as= having a secundary importance. Then which default value ? - it could be PRIORITY_8 in the middle, or if we prefer to have a l= arger range for higher priorities than for lower priorities, the default = value could be e.g. PRIORITY_10, giving 9 higher priorities and 5 lower p= riorities than the default one. I would have a preference for this value PR= IORITY_10. 2. About extensibility, the current range of 16 values is already larg= e, but we can have a reserved value to indicate a further extension. With = an enumerated AVP, there is no possibility to add new values. 3. I also had a look to some other IETF RFCs addressing priorities tha= t Ken mentioned, so to see if we can benefit from these approaches although= done for different contexts. - in RFC 4412 (Resource-Priority Header in SIP), wps and ets namespa= ces have a range of 5 values (0 to 4) with 0 as the highest priority . But= I have not found some indication (I may have missed it) about the default= priority (I mean a SIP request without Resource-Priority Header compared= to a SIP request with the Header). Implicitly, I would assume a SIP reque= st without Resource-Priority Header corresponds to the lowest priority. = DRMP has a similar approach but with a larger range and also lower priorit= ies. - RFC 6710 (priority for SMTP), uses another encoding of the prior= ity values with an integer between -9 and +9. Lower priorities are negativ= e an higher priority being positive. When a value increases, it means a hig= her priority, so the opposite to DRMP, wps or ets. But the value 0 is her= e naturally the default value. So this is an encoding alternative to the = Enumerated type of the DRMP AVP which avoids the question of the default va= lue. Note: RFC 6710 also defines some Priority Assignment Policies using a subs= et of the range. RFC 6710 has also this guideline : SMTP servers compliant with this specification are not required to support all 19 distinct priority levels (i.e., to treat each priority value as a separate priority), .... That is, an implementation that only supports N priority levels (where N < 19) will internally round up a syntactically valid priority value that isn't supported to the next higher supported number (or to the highest supported priority, if the value is higher than any supported pr= iority). - This raises the question to have this type of guideline if consid= ered useful. So to have your feedback Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C Envoy=E9 : jeudi 15 octobre 2015 12:33 =C0 : Lee, Jay; ken carlberg; Steve Donovan Cc : dime@ietf.org Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp)= : Range of priority levels) A couple thoughts: 1. There needs to be a default value defined by the standard, so that = equipment have the same value leaving the factory 2. This value can be over written based on local policy 3. Should have an extensibility bit in order to and more values in the= future From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay Sent: Thursday, October 15, 2015 6:16 AM To: ken carlberg >; Steve D= onovan > Cc: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) >From my side, some more discussion on Steve's mail may be needed. 'Should' vs. 'Must': One can say that 'Should' is not mandatory. But, in practice, this is a fai= rly strong statement, and often taken as required. So in this sense, the pr= oposed Note is certainly helpful. But, since we allow operators to override= the value, I don't see the reason why we use 'Should'. My suggestion is us= ing 'May'. PRIORITY_14 priority: Since operators can overwrite it, I was not too concerned about it. But if = we want to put some value, why '14'? A value lower than 14 is suggested in = order to allow more rooms for lower priorities. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg Sent: Wednesday, October 14, 2015 8:40 AM To: Steve Donovan Cc: dime@ietf.org Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): R= ange of priority levels) with respect to the diff-serv example brought up below, some thing to add t= o that discussion is that it starts off with separate and distinct forwardi= ng behavior whose marked packets provide segmentation of other IP traffic. = The availability of only 6 bits to play with (along with the headaches of = transitive trust) also discouraged a line of thought to define end-to-end p= riority handling versus a per diff-serv domain treatment. RFC-4594 did pro= vide configuration guidelines, but that's a different story. So back to a couple of ideas to consider. 1) reserved space. if we go back to the diff-serv model, the diff-serv wor= king group agreed to set aside a set of values that was reserved for experi= mental use that could be re-assigned some time in the future. I'm not sugg= esting that there should be space set side for experiments, but rather it m= ay be prudent to set aside a reserved set of bits/values so that one doesn'= t need to define a new AVP if in the future there was a need to define adde= d values beyond the 5 (plus some fudge factor) already mentioned on the lis= t. 2) sets of users. previous work (e.g., rfc-4412, rfc-6710) recognized that= there can be several sets of users/services that are distinct from each ot= her and yet need to prioritize the traffic. I bring this up because the dr= aft already identifies two sets of users in sections 5.1 and 5.2 (note: I'm= assuming that the latter is aimed at the general public and related to 911= /112/999 type calls, which should probably be more specific in the draft). = And there is also the potential of Firstnet users in the US. As a side note, the distinction and separation of general public and other = prioritized users in public phone infrastructures is not exclusive to the U= S, so the group should not be concerned that this is a US centric effort. = There has been GTPS in the UK, as well as other systems in other countries.= The RFC is a bit dated, but feel free to go over rfc-4190 for added backg= round. and just to reiterate. I'm not making recommendations in the above - just = bringing up some food for thought. -ken On Oct 14, 2015, at 10:12 AM, Steve Donovan > wrote: Jay, The current text is a SHOULD level requirement: When there is a mix of transactions specifying priority in request messages and transactions that do not have the priority specified, transactions that do not have a specified priority SHOULD be treated as having the PRIORITY_14 priority. As such, operators can choose to either not implement a priority or define = a different value for their network. I propose adding the following note after this paragraph to further explain= why it is a SHOULD and not a MUST: Note: There are scenarios where operators might want to specify a different default value for transactions that do not have an explicit priority. In this case, the operator defined local policy would override the use of PRIORITY_14 as the default priority. This leaves the ability for there to be deterministic behavior in Diameter = networks that require a default to be defined and are happy with the specif= ied default. It also gives operators the ability to define a different beh= avior, most likely with some priority handling/mapping at the edge of the n= etwork. Does this address your concerns? Regards, Steve On 10/14/15 2:59 AM, Lee, Jay wrote: Regarding the issue of whether we need to specify a default value or not, t= here are pros and cons. If we specify a value for the default case, we can see the benefits in scen= arios between different operator networks, but we take away important optio= ns on what operators can do with priority values. On the other hand, if we = do not specify the default value, operators may have more options, but ther= e is a question of what to do for this inter-PLMN cases when the networks m= ay use different default values. In practice, this issue can be addressed at the edge of the network, where = Diameter edge agent (DEA) can perform some priority mapping based on bilate= ral roaming agreement (or SLA (service level agreement)) and other means to= insure the proper handling. One may argue that this is not as good as the = 'deterministic' case, but operator should be able handle this in a reasonab= le way. We are fully aware of the fact that, in case of this 'non-determini= stic' case, the default value can differ from one operator network to anoth= er, and it becomes difficult to guarantee the intended priority handling. D= espite this, we still prefer giving options to operators by not specifying = the default value. What we are saying here, however, is not anything new. This is the typical = way of handling priority levels. If anything, specifying the default value = would be something new. As already mentioned in CT discussion, there is a g= ood example of this - Internet QoS, more specifically DiffServ. In order to guarantee end-to-end QoS for a specific service, IETF could hav= e specified a value (DiffServ codepoint) for the specific service to have p= redetermined handling of the traffic, but IETF did not. Instead, DiffServ s= imply provided a framework for operators to have its own classification an= d differentiated treatment of the services. To guarantee end-to-end QoS acr= oss different networks, then, operators need to do packet inspection, (re)c= lassification, QoS mapping, use of SLA and possibly others at the edge of n= etwork (edge router). Therefore, in the DiffServ architecture, intelligence= was pushed to the edge of the network. While the end results may not be gu= aranteed as well as in the case of predetermined handling, it was still a p= referred way to give flexibility to operators. My point is that we went thr= ough all these troubles to give options of priority handling to operators. By the way, if we are thinking of possibility of specifying the default val= ue, are we assuming that all operators are interested in this feature (defa= ult value in the middle, and high and low priorities at other ends)? Aren't= there other operators who are not interested in this feature? I know that = at least there is one - Verizon. We have no interest in this feature, and n= o plan for implementing it. We are OK, if other operators are interested in= this feature, and the default value is NOT specified. But we are certainly= not happy if DIME is trying to impose this on us. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, October 13, 2015 10:55 AM To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org; Pollini, Gregory P Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Assuming that we define a range of 3 values, Assuming that 0 is the lowest priority and 2 the highest, Assuming that an agent receives 4 messages at the same time while being in = overload control: * 1) ULR with Prio-0 * 2) ULR with Prio-1 * 3) ULR with Prio-2 * 4) ULR with no priority AVP Assuming that the default is locally defined as proposed below, How do you know that the ULR with priority 2 will be handled with a higher = priority than the request without priority indication? And what about ULR message with priority 1 with two levels of highest prior= ity e.g. emergency/Important and government/very important? Sorry if the answer is obvious but I fail to understand. Lionel De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] Envoy=E9 : samedi 3 octobre 2015 01:21 =C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C Cc : DiME; dime@ietf.org; Pollini, Gregory P Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels Hello all, Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.21= 2 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defi= ned. Having 15 rather than 16 would be useful from an interworking point of view= on Diameter interfaces connecting to the EPS. Also, my understanding has been that the default value is per local policy. My 2 cents.... Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf = of lionel.morand@orange.com [lionel.morand= @orange.com] Sent: Thursday, October 01, 2015 3:36 AM To: Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Hi, I think that the case "no Priority indication in request" is the default si= tuation today. So if we agree that it should be possible to explicitly indicate a request = with a lower priority, we should divide the range of priority values in thr= ee sub-ranges: [lower priorities][no priority indication][higher priorities= ], e.g. with 17 values: [0-7][8][9-16]. If any operator can freely fix the default value, there would be no way to = ensure the sender that a request with a specific priority value (e.g. 6) wi= ll be handled with a lower or higher priority than a request with no priori= ty indication. Therefore, for a deterministic handling mechanism, I think that it is then = more relevant to define a standard value for the default value. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn Envoy=E9 : mercredi 30 septembre 2015 22:53 =C0 : DOLLY, MARTIN C Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels Same here. The "default priority" should be a matter of local policy. Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "DOLLY, MARTIN C" > To: Steve Donovan >, "dime@ietf.org" > Date: 09/30/2015 04:40 PM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" = > ________________________________ Me as well From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, September 30, 2015 4:38 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels I'm okay with Jay's proposal on not specifying a default value. Steve On 9/30/15 3:27 PM, Lee, Jay wrote: Hi Steve and all, For the first proposal, as I indicated, I support increasing the number of = priority levels up to 16. I am also fine with the second proposal. My question is: do we need to mand= ate this feature, as individual operators have different situations? Perhap= s some flexibility should be allowed? Instead of mandating it, we can inclu= de the statement that when there is no DRMP AVP, this correspond to 'normal= traffic' without a particular high or low priority. Then each operator can= map this default to a value (e.g., 8 or something else) that they feel app= ropriate. Thanks, Jay _______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_E42CCDDA6722744CB241677169E8365615C7B9EAMISOUT7MSGUSRDB_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

See inline

 

From: DiME [mailto:dime-bounces@ietf= .org] On Behalf Of Lee, Jay
Sent: Friday, October 23, 2015 1:59 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) <jean-jacques.trottin@al= catel-lucent.com>; dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Some further comments from my side:

 

*/ If we need to assign (but not spec= ify) a value to the default case, we need to make it clear that this value = can be overwritten by operators, and the value is for some use cases like e.g., equipment having the same value when leav= ing the factory, so that there would be no misunderstanding.

mcd- ok

 

*/ Since we agree that the default va= lue is per local policy, ‘May’ is preferred to ‘Should= 217; in order not to cause confusion.

mcd-ok

 

*/ For assignment of the default valu= e, I am quite open. But any value between 9 – 12 seems reasonable to = me.

mcd- value should allow for assigning= lower values, though a carrier can assign what they want in their network,= there needs to be a common meaning at the interconnection point

 

*/  Current proposal of 16 value= s may be enough now, but I am fine with having an extensibility bit to be f= uture proof.

mcd-ok

 

*/ I am not sure of alternative encod= ing method (say, +9 to -9 per JJacques’ proposal) compared to the= current enumerated type of DRMP. It offers a logical way of assigning a value 0 to the default case. But it offers less flexibility= to operators, since the default value may not be easily moved to have more= higher/lower priority values. Also, we are used to the enumerated type of = DRMP and just want to have extension from 5 to 16,  but this may require more deviation from the current d= esign and thinking. For this, I would like to see more on qualitative pros/= cons, but, given its little benefit, I am reluctant to accept this alternat= ive.

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Thursday, October 22, 2015 9:39 AM
To: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Hi

 

1.    &= nbsp; PRIORITY_14 as default priori= ty value only allows one level of lower priority (PRIORITY_15)  than t= he default one; this seems not enough.  As use cases, we may have  some Machine type Communication (LTC) devices that may h= ave lower priorities that normal communications without priority.  Eve= n within a Diameter application, some commands may have a lower priority as= having a secundary importance.

 

Then whic= h default  value ?

-   =      it could be PRIORITY_8 in the= middle, or if we prefer to have a  larger range for higher priorities=  than for lower priorities,  the default value could be  e.g. PRIORITY_10,  giving 9 higher priorities and 5 lower pr= iorities than the default one. I would have a preference for this value PRI= ORITY_10.

 

2.    &= nbsp; About extensibility, the curr= ent range of 16 values is already large, but we can have  a reserved v= alue to indicate a further extension. With  an enumerated AVP, there is no possibility to add new values. 

 

3.    &= nbsp; I also had a look to some oth= er IETF RFCs addressing priorities that Ken mentioned, so to see if we can = benefit from these approaches although done for different contexts.

-   =      in RFC 4412 (Resource-Priorit= y Header in SIP), wps and ets namespaces have a range of 5 values (0 to 4) = with 0 as the highest priority  . But I have not found some indication  (I may have missed it) about the default p= riority  (I mean a SIP request without  Resource-Priority Header = compared  to a SIP request with the Header). Implicitly, I would assum= e a SIP request without  Resource-Priority Header corresponds to  the lowest priority.  DRMP has a similar approach but with&n= bsp; a larger range and also lower priorities.

 

-   =      RFC  6710 (priority for = SMTP),  uses another encoding of the priority values with an integer b= etween -9 and +9. Lower priorities  are negative an higher priority being positive. When a value increases, it means a higher priorit= y, so the opposite  to DRMP, wps or ets.  But the value 0 is here= naturally the default value. So this is an encoding alternative  to t= he  Enumerated type of the DRMP AVP which avoids the question of the default value.

Note: RFC  6710 also defi= nes some Priority Assignment Policies using a subset of the range.

 

RFC 6710 h= as also this guideline :

   SMTP server= s compliant with this specification are not

   required to supp= ort all 19 distinct priority levels (i.e., to treat

   each priority va= lue as a separate priority), ….  That is, an

   implementation t= hat only supports N priority levels (where N < 19)

   will internally = round up a syntactically valid priority value that

   isn't supported = to the next higher supported number (or to the

   highest supporte= d priority, if the value is higher than any supported priority).=

-   =      This raises the question to h= ave this type of  guideline if considered useful.

 = ;

So to have your feedback

 

Best regards

 

JJacques

 

De : DiME= [mailto:dime-bounces@ietf.org= ] De la part de DOLLY, MARTIN C
Envoy=E9 : jeudi 15 octobre 2015 12:33
=C0 : Lee, Jay; ken carlberg; Steve Donovan
Cc : dime@ietf.org
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime= ] #92 (drmp): Range of priority levels)

 

A couple thoughts:<= /p>

1= .   &nb= sp;  There needs to be a default value defined by the stan= dard, so that equipment have the same value leaving the factory<= /span>

2= .   &nb= sp;  This value can be over written based on local policy<= o:p>

3= .   &nb= sp;  Should have an extensibility bit in order to and more= values in the future

 

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay
Sent: Thursday, October 15, 2015 6:16 AM
To: ken carlberg <carlberg= @g11.org.uk>; Steve Donovan <srdonovan@usdonovans.com>
Cc: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

From my side, some more discussion on= Steve’s mail may be needed.

 

‘Should’ vs. ‘Must&= #8217;:

One can say that ‘Should’= is not mandatory. But, in practice, this is a fairly strong statement, and= often taken as required. So in this sense, the proposed Note is certainly helpful. But, since we allow operators to override the value,= I don’t see the reason why we use ‘Should’. My suggestio= n is using ‘May’.

 

PRIORITY_14 priority:

Since operators can overwrite it, I w= as not too concerned about it. But if we want to put some value, why ‘= ;14’? A value lower than 14 is suggested in order to allow more rooms for lower priorities.

 

Jay

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg
Sent: Wednesday, October 14, 2015 8:40 AM
To: Steve Donovan
Cc: dime@ietf.org
Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (d= rmp): Range of priority levels)

 

with respect to the diff-serv example brought up bel= ow, some thing to add to that discussion is that it starts off with separat= e and distinct forwarding behavior whose marked packets provide segmentatio= n of other IP traffic.  The availability of only 6 bits to play with (along with the headaches of transitive trust)= also discouraged a line of thought to define end-to-end priority handling = versus a per diff-serv domain treatment.  RFC-4594 did provide configu= ration guidelines, but that’s a different story.

 

So back to a couple of ideas to consider.=

 

1) reserved space.  if we go back to the diff-s= erv model, the diff-serv working group agreed to set aside a set of values = that was reserved for experimental use that could be re-assigned some time = in the future.  I’m not suggesting that there should be space set side for experiments, but rather it may be prude= nt to set aside a reserved set of bits/values so that one doesn't need to d= efine a new AVP if in the future there was a need to define added values be= yond the 5 (plus some fudge factor) already mentioned on the list. 

 

2) sets of users.  previous work (e.g., rfc-441= 2, rfc-6710) recognized that there can be several sets of users/services th= at are distinct from each other and yet need to prioritize the traffic. &nb= sp;I bring this up because the draft already identifies two sets of users in sections 5.1 and 5.2 (note: I’m assu= ming that the latter is aimed at the general public and related to 911/112/= 999 type calls, which should probably be more specific in the draft).  = ;And there is also the potential of Firstnet users in the US.

 

As a side note, the distinction and separation of ge= neral public and other prioritized users in public phone infrastructures is= not exclusive to the US, so the group should not be concerned that this is= a US centric effort.  There has been GTPS in the UK, as well as other systems in other countries.  The RFC= is a bit dated, but feel free to go over rfc-4190 for added background.

 

and just to reiterate.  I’m not making re= commendations in the above — just bringing up some food for thought.<= o:p>

 

-ken

 

 

On Oct 14, 2015, at 10:12 AM, Steve Donovan <srdonovan@usdonovans.com> wr= ote:

 

Ja= y,

The current text is a SHOULD level require= ment:

   When there is a mix of transa= ctions specifying priority in request
   messages and transactions tha= t do not have the priority specified,
   transactions that do not have= a specified priority SHOULD be treated
   as having the PRIORITY_14 pri= ority.

As such, operators can choose to either no= t implement a priority or define a different value for their network.

I propose adding the following note after = this paragraph to further explain why it is a SHOULD and not a MUST:=

      Note: There= are scenarios where operators might want to 
      specify a d= ifferent default value for transactions that do not
      have an exp= licit priority.  In this case, the operator defined
      local polic= y would override the use of PRIORITY_14 as
      the default= priority.

This leaves the ability for there to be de= terministic behavior in Diameter networks that require a default to be defi= ned and are happy with the specified default.  It also gives operators= the ability to define a different behavior, most likely with some priority handling/mapping at the edge of the network= .

Does this address your concerns?
Regards,

Steve

On 10/14/15 2:59 AM, Le= e, Jay wrote:

Regarding = the issue of whether we need to specify a default value or not, there are p= ros and cons.

 

If we spec= ify a value for the default case, we can see the benefits in scenarios betw= een different operator networks, but we take away important options on what operators can do with priority values. On the ot= her hand, if we do not specify the default value, operators may have more o= ptions, but there is a question of what to do for this inter-PLMN cases whe= n the networks may use different default values.

 

In practic= e, this issue can be addressed at the edge of the network, where Diameter e= dge agent (DEA) can perform some priority mapping based on bilateral roaming agreement (or SLA (service level agreement)) an= d other means to insure the proper handling. One may argue that this is not= as good as the ‘deterministic’ case, but operator should be ab= le handle this in a reasonable way. We are fully aware of the fact that, in case of this ‘non-deterministic’ ca= se, the default value can differ from one operator network to another, and = it becomes difficult to guarantee the intended priority handling. Despite t= his, we still prefer giving options to operators by not specifying the default value.

 

What we ar= e saying here, however, is not anything new. This is the typical way of han= dling priority levels. If anything, specifying the default value would be something new. As already mentioned in CT discussio= n, there is a good example of this – Internet QoS, more specifically = DiffServ.

 

In order t= o guarantee end-to-end QoS for a specific service, IETF could have specifie= d a value (DiffServ codepoint) for the specific service to have predetermined handling of the traffic, but IETF did not. I= nstead, DiffServ simply provided a framework for operators to have its own =  classification and differentiated treatment of the services. To guara= ntee end-to-end QoS across different networks, then, operators need to do packet inspection, (re)classification= , QoS mapping, use of SLA and possibly others at the edge of network (edge = router). Therefore, in the DiffServ architecture, intelligence was pushed t= o the edge of the network. While the end results may not be guaranteed as well as in the case of predetermi= ned handling, it was still a preferred way to give flexibility to operators= . My point is that we went through all these troubles to give options of pr= iority handling to operators.

 

By the way= , if we are thinking of possibility of specifying the default value, are we= assuming that all operators are interested in this feature (default value in the middle, and high and low priorities at other= ends)? Aren’t there other operators who are not interested in this f= eature? I know that at least there is one – Verizon. We have no inter= est in this feature, and no plan for implementing it. We are OK, if other operators are interested in this feature, and the = default value is NOT specified. But we are certainly not happy if DIME is t= rying to impose this on us.

 

Jay=

 

From: DiME [mai= lto:dime-bounces@ietf.org]=  On Behalf Of lionel.morand@orange.com
Sent: Tuesday, Oct= ober 13, 2015 10:55 AM
To: Shaikh, Viqar = A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; = dime@ietf.org; Pollini, Gregory P Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 

Assuming t= hat we define a range of 3 values,

Assuming t= hat 0 is the lowest priority and 2 the highest,

Assuming t= hat an agent receives 4 messages at the same time while being in overload c= ontrol:

=B7     &nbs= p; = 1) ULR with Prio-0

=B7     &nbs= p; = 2) ULR with Prio-1

=B7     &nbs= p; = 3) ULR with Prio-2

=B7     &nbs= p; = 4) ULR with no priority AVP

 

Assuming t= hat the default is locally defined as proposed below,

 

How do you= know that the ULR with priority 2 will be handled with a higher priority &= nbsp;than the request without priority indication?

And what a= bout ULR message with priority 1 with two levels of highest priority e.g. e= mergency/Important and government/very important?

 

Sorry if t= he answer is obvious but I fail to understand.

 

Lionel

 

 

 &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  

De :<= /span> Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] 
Envoy=E9 : sa= medi 3 octobre 2015 01:21
=C0 : MORAND = Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; dime@ietf.org; Pollini, Grego= ry P
Objet : RE: [= Dime] [dime] #92 (drmp): Range of priority levels

 <= /span>

Hello all,<= /span>

 

Note t= hat the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 = ;takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined.

 

Having 15 r= ather than 16 would be useful from an interworking point of view on Diamete= r interfaces connecting to the EPS.  

 

Also, my un= derstanding has been that the default value is per local policy. =

 

My 2 cents.= ...

Viqar =

<= span lang=3D"FR" style=3D"font-size:10.0pt;font-family:"Tahoma",s= ans-serif">From: DiME [dim= e-bounces@ietf.org] on behalf of lionel.morand@orange.com [<= span style=3D"color:purple">lionel.morand@orange.com]
Sent: Thursday, Oc= tober 01, 2015 3:36 AM
To: Janet P Gunn; = DOLLY, MARTIN C
Cc: DiME; = dime@ietf.org
Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

Hi,=

 <= /span>

I think th= at the case "no Priority indication in request" is the default si= tuation today.

So if we a= gree that it should be possible to explicitly indicate a request with a low= er priority, we should divide the range of priority values in three sub-ranges: [lower priorities][no priority indication][hig= her priorities], e.g. with 17 values: [0-7][8][9-16].

If any ope= rator can freely fix the default value, there would be no way to ensure the= sender that a request with a specific priority value (e.g. 6) will be handled with a lower or higher priority than a requ= est with no priority indication.

 <= /span>

Therefore,= for a deterministic handling mechanism, I think that it is then more relev= ant to define a standard value for the default value.

 <= /span>

Regards,

 <= /span>

Lionel

 <= /span>

 <= /span>

De :<= /span> DiME [mai= lto:dime-bounces@ietf.org]=  De la part de&nbs= p;Janet P Gunn
Envoy=E9 : me= rcredi 30 septembre 2015 22:53
=C0 : DOLLY, = MARTIN C
Cc : DiME; dime@ietf.org
Objet : Re: [= Dime] [dime] #92 (drmp): Range of priority levels

 <= /span>

Same here. &= nbsp;The "default priority" should be a matter of local policy. <= /span>

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose. 



From:        "DOLLY, MARTIN C" <md3135@att.com> 
To:        Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org> <= /span>
Date:        09/30/2015 04:40 PM 
Subject:        <= span lang=3D"FR" style=3D"font-size:7.5pt;font-family:"Arial",san= s-serif">Re: [Dime] [dime] #92 (drmp): Range of priority levels 
Sent by:        <= span lang=3D"FR" style=3D"font-size:7.5pt;font-family:"Arial",san= s-serif">"DiME" <dime-bounces@ietf.org= >




Me as well 
  
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Dono= van
Sent: Wednesday, Sept= ember 30, 2015 4:38 PM
To: dime@ietf.or= g
Subject: Re: [Dime] [= dime] #92 (drmp): Range of priority levels 
  
I'm okay with Jay's proposal on not specifying a defaul= t value.

Steve <= /span>
On 9/30/15 3:27 PM, Lee, Jay wrote: 
Hi Steve and all, 
  
For the first proposal, as I indicated, I support incre= asing the number of priority levels up to 16. 
  
I am also fine with the second proposal. My question is= : do we need to mandate this feature, as individual operators have differen= t situations? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that whe= n there is no DRMP AVP, this correspond to ‘normal traffic’ wit= hout a particular high or low priority. Then each operator can map this def= ault to a value (e.g., 8 or something else) that they feel appropriate. 
  
Thanks, 
  
Jay 



_______________________= ________________________ 
DiME mailing list 
DiME@ietf.org 
https://www.ietf.org/mailman/li= stinfo/dime   _____________= __________________________________
DiME mailing list
DiME@ietf.org<= /span>
https://ww= w.ietf.org/mailman/listinfo/dime

_____________________________________=
___________________________________________________________________________=
_________
 
Ce message et ses pieces jointes peuv=
ent contenir des informations confidentielles ou privilegiees et ne doivent=
 donc
pas etre diffuses, exploites ou copie=
s sans autorisation. Si vous avez recu ce message par erreur, veuillez le s=
ignaler
a l'expediteur et le detruire ainsi q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration,
Orange decline toute responsabilite s=
i ce message a ete altere, deforme ou falsifie. Merci.

 


This message and its attachments may =
contain confidential or privileged information that may be protected by law=
;they should not be distributed, used =
or copied without authorisation.


If you have received this email in er=
ror, please notify the sender and delete this message and its attachments.<=
/span>=



As emails may be altered, Orange is n=
ot liable for messages that have been modified, changed or falsified.=



Thank you.


_____________________________________=
___________________________________________________________________________=
_________
 
Ce message et ses pieces jointes peuv=
ent contenir des informations confidentielles ou privilegiees et ne doivent=
 donc
pas etre diffuses, exploites ou copie=
s sans autorisation. Si vous avez recu ce message par erreur, veuillez le s=
ignaler
a l'expediteur et le detruire ainsi q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration,
Orange decline toute responsabilite s=
i ce message a ete altere, deforme ou falsifie. Merci.

 


This message and its attachments may =
contain confidential or privileged information that may be protected by law=
;they should not be distributed, used =
or copied without authorisation.


If you have received this email in er=
ror, please notify the sender and delete this message and its attachments.<=
/span>=



As emails may be altered, Orange is n=
ot liable for messages that have been modified, changed or falsified.=



Thank you.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.ietf.org/mailman/listinfo/di=
me


__________________________________________= _____
DiME mailing list
DiM= E@ietf.org
https://www.ietf.org/mailman/listinfo/dime<= o:p>

 

--_000_E42CCDDA6722744CB241677169E8365615C7B9EAMISOUT7MSGUSRDB_-- From nobody Fri Oct 23 08:02:13 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8161A1DE1 for ; Fri, 23 Oct 2015 08:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.52 X-Spam-Level: X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rclCBFDi2hZW for ; Fri, 23 Oct 2015 08:02:05 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C761A1DBC for ; Fri, 23 Oct 2015 08:02:02 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:51181 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from ) id 1Zpdqs-001knP-JC for dime@ietf.org; Fri, 23 Oct 2015 08:02:02 -0700 To: dime@ietf.org References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> <20151014075941.062E21B2C1F@ietfa.amsl.com> <561E62C9.20500@usdonovans.com> <1431d0b2-5ae7-426e-b5ff-42b23fecbee5@CASAC1EXH002.uswin.ad.vzwcorp.com> <20151015101558.111761ACD5C@ietfa.amsl.com> <3e7a25c8-5eea-49a5-9905-3009c4dc45b8@NYORA1HUB001.uswin.ad.vzwcorp.com> <20151023055927.9223C1B3292@ietfa.amsl.com> From: Steve Donovan Message-ID: <562A4BE1.3080901@usdonovans.com> Date: Fri, 23 Oct 2015 10:01:53 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040600090908010804080702" X-OutGoing-Spam-Status: No, score=0.6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2015 15:02:12 -0000 This is a multi-part message in MIME format. --------------040600090908010804080702 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Please see my comments inline. Steve On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote: > > See inline > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Lee, Jay > *Sent:* Friday, October 23, 2015 1:59 AM > *To:* TROTTIN, JEAN-JACQUES (JEAN-JACQUES) > ; dime@ietf.org > *Subject:* Re: [Dime] diff-serb and two other ideas (was Re: [dime] > #92 (drmp): Range of priority levels) > > Some further comments from my side: > > */ If we need to assign (but not specify) a value to the default case, > we need to make it clear that this value can be overwritten by > operators, and the value is for some use cases like e.g., equipment > having the same value when leaving the factory, so that there would be > no misunderstanding. > > mcd- ok > SRD> I think the current proposed text makes this clear. > > */ Since we agree that the default value is per local policy, ‘May’ is > preferred to ‘Should’ in order not to cause confusion. > > mcd-ok > SRD> I'm okay with making this a MAY. > > */ For assignment of the default value, I am quite open. But any value > between 9 – 12 seems reasonable to me. > > mcd- value should allow for assigning lower values, though a carrier > can assign what they want in their network, there needs to be a common > meaning at the interconnection point > SRD> I'm open to any value we decide on. If there are real use cases that require pushing the default value more to the middle then we should do so. At this point I've heard one use case for the default being something other then the lowest value, thus the proposal to use priority_14 as the default. > > */ Current proposal of 16 values may be enough now, but I am fine > with having an extensibility bit to be future proof. > > mcd-ok > SRD> I don't see a compelling argument to move beyond 16. In addition, it isn't clear to me that there is value in defining an extensibility mechanism beyond what is already supported by Diameter. Doing so would add significant complexity to the DRMP mechanism for something that, in my view, has a low probability of being used. I propose that we not allow extending the DRMP AVP. Rather we require that any extension require a new AVP. We can then leave it to the document that proposes the extension to deal with determining whether send the DRMP AVP or the newly defined DRMPv2 AVP. > > */ I am not sure of alternative encoding method (say, +9 to -9 per > JJacques’ proposal) compared to the current enumerated type of DRMP. > It offers a logical way of assigning a value 0 to the default case. > But it offers less flexibility to operators, since the default value > may not be easily moved to have more higher/lower priority values. > Also, we are used to the enumerated type of DRMP and just want to have > extension from 5 to 16, but this may require more deviation from the > current design and thinking. For this, I would like to see more on > qualitative pros/cons, but, given its little benefit, I am reluctant > to accept this alternative. > SRD> I agree that I don't see value in the +9 to -9 proposal. > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *TROTTIN, > JEAN-JACQUES (JEAN-JACQUES) > *Sent:* Thursday, October 22, 2015 9:39 AM > *To:* dime@ietf.org > *Subject:* Re: [Dime] diff-serb and two other ideas (was Re: [dime] > #92 (drmp): Range of priority levels) > > Hi > > 1.PRIORITY_14 as default priority value only allows one level of lower > priority (PRIORITY_15) than the default one; this seems not enough. > As use cases, we may have some Machine type Communication (LTC) > devices that may have lower priorities that normal communications > without priority. Even within a Diameter application, some commands > may have a lower priority as having a secundary importance. > > Then which default value ? > > -it could be PRIORITY_8 in the middle, or if we prefer to have a > larger range for higher priorities than for lower priorities, the > default value could be e.g. PRIORITY_10, giving 9 higher priorities > and 5 lower priorities than the default one. I would have a preference > for this value PRIORITY_10. > > 2.About extensibility, the current range of 16 values is already > large, but we can have a reserved value to indicate a further > extension. With an enumerated AVP, there is no possibility to add new > values. > > 3.I also had a look to some other IETF RFCs addressing priorities that > Ken mentioned, so to see if we can benefit from these approaches > although done for different contexts. > > -in RFC 4412 (Resource-Priority Header in SIP), wps and ets namespaces > have a range of 5 values (0 to 4) with 0 as the highest priority . > But I have not found some indication (I may have missed it) about the > default priority (I mean a SIP request without Resource-Priority > Header compared to a SIP request with the Header). Implicitly, I > would assume a SIP request without Resource-Priority Header > corresponds to the lowest priority. DRMP has a similar approach but > with a larger range and also lower priorities. > > -RFC 6710 (priority for SMTP), uses another encoding of the priority > values with an integer between -9 and +9. Lower priorities are > negative an higher priority being positive. When a value increases, it > means a higher priority, so the opposite to DRMP, wps or ets. But > the value 0 is here naturally the default value. So this is an > encoding alternative to the Enumerated type of the DRMP AVP which > avoids the question of the default value. > > Note: RFC 6710 also defines some Priority Assignment Policies using a > subset of the range. > > RFC 6710 has also this guideline : > > SMTP servers compliant with this specification are not > > required to support all 19 distinct priority levels (i.e., to treat > > each priority value as a separate priority), …. That is, an > > implementation that only supports N priority levels (where N < 19) > > will internally round up a syntactically valid priority value that > > isn't supported to the next higher supported number (or to the > > highest supported priority, if the value is higher than any supported > priority). > > -This raises the question to have this type of guideline if > considered useful. > > So to have your feedback > > Best regards > > JJacques > > *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* DOLLY, MARTIN C > *Envoyé :* jeudi 15 octobre 2015 12:33 > *À :* Lee, Jay; ken carlberg; Steve Donovan > *Cc :* dime@ietf.org > *Objet :* Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 > (drmp): Range of priority levels) > > A couple thoughts: > > 1.There needs to be a default value defined by the standard, so that > equipment have the same value leaving the factory > > 2.This value can be over written based on local policy > > 3.Should have an extensibility bit in order to and more values in the > future > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Lee, Jay > *Sent:* Thursday, October 15, 2015 6:16 AM > *To:* ken carlberg >; > Steve Donovan > > *Cc:* dime@ietf.org > *Subject:* Re: [Dime] diff-serb and two other ideas (was Re: [dime] > #92 (drmp): Range of priority levels) > > From my side, some more discussion on Steve’s mail may be needed. > > ‘Should’ vs. ‘Must’: > > One can say that ‘Should’ is not mandatory. But, in practice, this is > a fairly strong statement, and often taken as required. So in this > sense, the proposed Note is certainly helpful. But, since we allow > operators to override the value, I don’t see the reason why we use > ‘Should’. My suggestion is using ‘May’. > > PRIORITY_14 priority: > > Since operators can overwrite it, I was not too concerned about it. > But if we want to put some value, why ‘14’? A value lower than 14 is > suggested in order to allow more rooms for lower priorities. > > Jay > > *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ken carlberg > *Sent:* Wednesday, October 14, 2015 8:40 AM > *To:* Steve Donovan > *Cc:* dime@ietf.org > *Subject:* [Dime] diff-serb and two other ideas (was Re: [dime] #92 > (drmp): Range of priority levels) > > with respect to the diff-serv example brought up below, some thing to > add to that discussion is that it starts off with separate and > distinct forwarding behavior whose marked packets provide segmentation > of other IP traffic. The availability of only 6 bits to play with > (along with the headaches of transitive trust) also discouraged a line > of thought to define end-to-end priority handling versus a per > diff-serv domain treatment. RFC-4594 did provide configuration > guidelines, but that’s a different story. > > So back to a couple of ideas to consider. > > 1) reserved space. if we go back to the diff-serv model, the > diff-serv working group agreed to set aside a set of values that was > reserved for experimental use that could be re-assigned some time in > the future. I’m not suggesting that there should be space set side > for experiments, but rather it may be prudent to set aside a reserved > set of bits/values so that one doesn't need to define a new AVP if in > the future there was a need to define added values beyond the 5 (plus > some fudge factor) already mentioned on the list. > > 2) sets of users. previous work (e.g., rfc-4412, rfc-6710) recognized > that there can be several sets of users/services that are distinct > from each other and yet need to prioritize the traffic. I bring this > up because the draft already identifies two sets of users in sections > 5.1 and 5.2 (note: I’m assuming that the latter is aimed at the > general public and related to 911/112/999 type calls, which should > probably be more specific in the draft). And there is also the > potential of Firstnet users in the US. > > As a side note, the distinction and separation of general public and > other prioritized users in public phone infrastructures is not > exclusive to the US, so the group should not be concerned that this is > a US centric effort. There has been GTPS in the UK, as well as other > systems in other countries. The RFC is a bit dated, but feel free to > go over rfc-4190 for added background. > > and just to reiterate. I’m not making recommendations in the above — > just bringing up some food for thought. > > -ken > > On Oct 14, 2015, at 10:12 AM, Steve Donovan > > wrote: > > Jay, > > The current text is a SHOULD level requirement: > > When there is a mix of transactions specifying priority in request > messages and transactions that do not have the priority specified, > transactions that do not have a specified priority SHOULD be > treated > as having the PRIORITY_14 priority. > > As such, operators can choose to either not implement a priority > or define a different value for their network. > > I propose adding the following note after this paragraph to > further explain why it is a SHOULD and not a MUST: > > Note: There are scenarios where operators might want to > specify a different default value for transactions that do not > have an explicit priority. In this case, the operator defined > local policy would override the use of PRIORITY_14 as > the default priority. > > This leaves the ability for there to be deterministic behavior in > Diameter networks that require a default to be defined and are > happy with the specified default. It also gives operators the > ability to define a different behavior, most likely with some > priority handling/mapping at the edge of the network. > > Does this address your concerns? > > Regards, > > Steve > > On 10/14/15 2:59 AM, Lee, Jay wrote: > > Regarding the issue of whether we need to specify a default > value or not, there are pros and cons. > > If we specify a value for the default case, we can see the > benefits in scenarios between different operator networks, but > we take away important options on what operators can do with > priority values. On the other hand, if we do not specify the > default value, operators may have more options, but there is a > question of what to do for this inter-PLMN cases when the > networks may use different default values. > > In practice, this issue can be addressed at the edge of the > network, where Diameter edge agent (DEA) can perform some > priority mapping based on bilateral roaming agreement (or SLA > (service level agreement)) and other means to insure the > proper handling. One may argue that this is not as good as the > ‘deterministic’ case, but operator should be able handle this > in a reasonable way. We are fully aware of the fact that, in > case of this ‘non-deterministic’ case, the default value can > differ from one operator network to another, and it becomes > difficult to guarantee the intended priority handling. Despite > this, we still prefer giving options to operators by not > specifying the default value. > > What we are saying here, however, is not anything new. This is > the typical way of handling priority levels. If anything, > specifying the default value would be something new. As > already mentioned in CT discussion, there is a good example of > this – Internet QoS, more specifically DiffServ. > > In order to guarantee end-to-end QoS for a specific service, > IETF could have specified a value (DiffServ codepoint) for the > specific service to have predetermined handling of the > traffic, but IETF did not. Instead, DiffServ simply provided a > framework for operators to have its own classification and > differentiated treatment of the services. To guarantee > end-to-end QoS across different networks, then, operators need > to do packet inspection, (re)classification, QoS mapping, use > of SLA and possibly others at the edge of network (edge > router). Therefore, in the DiffServ architecture, intelligence > was pushed to the edge of the network. While the end results > may not be guaranteed as well as in the case of predetermined > handling, it was still a preferred way to give flexibility to > operators. My point is that we went through all these troubles > to give options of priority handling to operators. > > By the way, if we are thinking of possibility of specifying > the default value, are we assuming that all operators are > interested in this feature (default value in the middle, and > high and low priorities at other ends)? Aren’t there other > operators who are not interested in this feature? I know that > at least there is one – Verizon. We have no interest in this > feature, and no plan for implementing it. We are OK, if other > operators are interested in this feature, and the default > value is NOT specified. But we are certainly not happy if DIME > is trying to impose this on us. > > Jay > > *From:*DiME [mailto:dime-bounces@ietf.org]*On Behalf > Of*lionel.morand@orange.com > *Sent:*Tuesday, October 13, 2015 10:55 AM > *To:*Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C > *Cc:*DiME;dime@ietf.org ; Pollini, Gregory P > *Subject:*Re: [Dime] [dime] #92 (drmp): Range of priority levels > > Assuming that we define a range of 3 values, > > Assuming that 0 is the lowest priority and 2 the highest, > > Assuming that an agent receives 4 messages at the same time > while being in overload control: > > ·1) ULR with Prio-0 > > ·2) ULR with Prio-1 > > ·3) ULR with Prio-2 > > ·4) ULR with no priority AVP > > Assuming that the default is locally defined as proposed below, > > How do you know that the ULR with priority 2 will be handled > with a higher priority than the request without priority > indication? > > And what about ULR message with priority 1 with two levels of > highest priority e.g. emergency/Important and government/very > important? > > Sorry if the answer is obvious but I fail to understand. > > Lionel > > *De :*Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] > *Envoyé :*samedi 3 octobre 2015 01:21 > *À :*MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C > *Cc :*DiME;dime@ietf.org ; Pollini, > Gregory P > *Objet :*RE: [Dime] [dime] #92 (drmp): Range of priority levels > > Hello all, > > Note that the 3GPP priority, e.g., Priority-Level AVP (ARP > AVP) in TS 29.212 takes 15 values, value 1 the highest, 15 the > lowest, and value 0 not defined. > > Having 15 rather than 16 would be useful from an interworking > point of view on Diameter interfaces connecting to the EPS. > > Also, my understanding has been that the default value is per > local policy. > > My 2 cents.... > > Viqar > > ------------------------------------------------------------------------ > > *From:*DiME [dime-bounces@ietf.org > ] on behalf > oflionel.morand@orange.com > [lionel.morand@orange.com > ] > *Sent:*Thursday, October 01, 2015 3:36 AM > *To:*Janet P Gunn; DOLLY, MARTIN C > *Cc:*DiME;dime@ietf.org > *Subject:*Re: [Dime] [dime] #92 (drmp): Range of priority levels > > Hi, > > I think that the case "no Priority indication in request" is > the default situation today. > > So if we agree that it should be possible to explicitly > indicate a request with a lower priority, we should divide the > range of priority values in three sub-ranges: [lower > priorities][no priority indication][higher priorities], e.g. > with 17 values: [0-7][8][9-16]. > > If any operator can freely fix the default value, there would > be no way to ensure the sender that a request with a specific > priority value (e.g. 6) will be handled with a lower or higher > priority than a request with no priority indication. > > Therefore, for a deterministic handling mechanism, I think > that it is then more relevant to define a standard value for > the default value. > > Regards, > > Lionel > > *De :*DiME [mailto:dime-bounces@ietf.org]*De la part de*Janet > P Gunn > *Envoyé :*mercredi 30 septembre 2015 22:53 > *À :*DOLLY, MARTIN C > *Cc :*DiME;dime@ietf.org > *Objet :*Re: [Dime] [dime] #92 (drmp): Range of priority levels > > Same here. The "default priority" should be a matter of local > policy. > > Janet > > This is a PRIVATE message. If you are not the intended > recipient, please delete without copying and kindly advise us > by e-mail of the mistake in delivery. NOTE: Regardless of > content, this e-mail shall not operate to bind CSC to any > order or other contract unless pursuant to explicit written > agreement or government initiative expressly permitting the > use of e-mail for such purpose. > > > > From: "DOLLY, MARTIN C" > > To: Steve Donovan >, "dime@ietf.org > " > > Date: 09/30/2015 04:40 PM > Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels > Sent by: "DiME" > > > ------------------------------------------------------------------------ > > > > > Me as well > > *From:*DiME [mailto:dime-bounces@ietf.org]*On Behalf Of*Steve > Donovan* > Sent:*Wednesday, September 30, 2015 4:38 PM* > To:*dime@ietf.org * > Subject:*Re: [Dime] [dime] #92 (drmp): Range of priority levels > > I'm okay with Jay's proposal on not specifying a default value. > > Steve > On 9/30/15 3:27 PM, Lee, Jay wrote: > Hi Steve and all, > > For the first proposal, as I indicated, I support increasing > the number of priority levels up to 16. > > I am also fine with the second proposal. My question is: do we > need to mandate this feature, as individual operators have > different situations? Perhaps some flexibility should be > allowed? Instead of mandating it, we can include the statement > that when there is no DRMP AVP, this correspond to ‘normal > traffic’ without a particular high or low priority. Then each > operator can map this default to a value (e.g., 8 or something > else) that they feel appropriate. > > Thanks, > > Jay > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des > informations confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si > vous avez recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. > Les messages electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; > > they should not be distributed, used or copied without > authorisation. > > If you have received this email in error, please notify the > sender and delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages > that have been modified, changed or falsified. > > Thank you. > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des > informations confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si > vous avez recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. > Les messages electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; > > they should not be distributed, used or copied without > authorisation. > > If you have received this email in error, please notify the > sender and delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages > that have been modified, changed or falsified. > > Thank you. > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------040600090908010804080702 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Please see my comments inline.

Steve

On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote:

See inline

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay
Sent: Friday, October 23, 2015 1:59 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) <jean-jacques.trottin@alcatel-lucent.com>; dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

 

Some further comments from my side:

 

*/ If we need to assign (but not specify) a value to the default case, we need to make it clear that this value can be overwritten by operators, and the value is for some use cases like e.g., equipment having the same value when leaving the factory, so that there would be no misunderstanding.

mcd- ok

SRD> I think the current proposed text makes this clear.

 

*/ Since we agree that the default value is per local policy, ‘May’ is preferred to ‘Should’ in order not to cause confusion.

mcd-ok

SRD> I'm okay with making this a MAY.

 

*/ For assignment of the default value, I am quite open. But any value between 9 – 12 seems reasonable to me.

mcd- value should allow for assigning lower values, though a carrier can assign what they want in their network, there needs to be a common meaning at the interconnection point

SRD> I'm open to any value we decide on.  If there are real use cases that require pushing the default value more to the middle then we should do so.  At this point I've heard one use case for the default being something other then the lowest value, thus the proposal to use priority_14 as the default. 

 

*/  Current proposal of 16 values may be enough now, but I am fine with having an extensibility bit to be future proof.

mcd-ok

SRD> I don't see a compelling argument to move beyond 16. 

In addition, it isn't clear to me that there is value in defining an extensibility mechanism beyond what is already supported by Diameter.  Doing so would add significant complexity to the DRMP mechanism for something that, in my view, has a low probability of being used.

I propose that we not allow extending the DRMP AVP.  Rather we require that any extension require a new AVP.  We can then leave it to the document that proposes the extension to deal with determining whether send the DRMP AVP or the newly defined DRMPv2 AVP. 

 

*/ I am not sure of alternative encoding method (say, +9 to -9 per JJacques’ proposal) compared to the current enumerated type of DRMP. It offers a logical way of assigning a value 0 to the default case. But it offers less flexibility to operators, since the default value may not be easily moved to have more higher/lower priority values. Also, we are used to the enumerated type of DRMP and just want to have extension from 5 to 16,  but this may require more deviation from the current design and thinking. For this, I would like to see more on qualitative pros/cons, but, given its little benefit, I am reluctant to accept this alternative.

SRD> I agree that I don't see value in the +9 to -9 proposal.

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Thursday, October 22, 2015 9:39 AM
To: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

 

Hi

 

1.      PRIORITY_14 as default priority value only allows one level of lower priority (PRIORITY_15)  than the default one; this seems not enough.  As use cases, we may have  some Machine type Communication (LTC) devices that may have lower priorities that normal communications without priority.  Even within a Diameter application, some commands may have a lower priority as having a secundary importance.

 

Then which default  value ?

-        it could be PRIORITY_8 in the middle, or if we prefer to have a  larger range for higher priorities  than for lower priorities,  the default value could be  e.g. PRIORITY_10,  giving 9 higher priorities and 5 lower priorities than the default one. I would have a preference for this value PRIORITY_10.

 

2.      About extensibility, the current range of 16 values is already large, but we can have  a reserved value to indicate a further extension. With  an enumerated AVP, there is no possibility to add new values. 

 

3.      I also had a look to some other IETF RFCs addressing priorities that Ken mentioned, so to see if we can benefit from these approaches although done for different contexts.

-        in RFC 4412 (Resource-Priority Header in SIP), wps and ets namespaces have a range of 5 values (0 to 4) with 0 as the highest priority  . But I have not found some indication  (I may have missed it) about the default priority  (I mean a SIP request without  Resource-Priority Header compared  to a SIP request with the Header). Implicitly, I would assume a SIP request without  Resource-Priority Header corresponds to  the lowest priority.  DRMP has a similar approach but with  a larger range and also lower priorities.

 

-        RFC  6710 (priority for SMTP),  uses another encoding of the priority values with an integer between -9 and +9. Lower priorities  are negative an higher priority being positive. When a value increases, it means a higher priority, so the opposite  to DRMP, wps or ets.  But the value 0 is here naturally the default value. So this is an encoding alternative  to the  Enumerated type of the DRMP AVP which avoids the question of the default value.

Note: RFC  6710 also defines some Priority Assignment Policies using a subset of the range.

 

RFC 6710 has also this guideline :

   SMTP servers compliant with this specification are not

   required to support all 19 distinct priority levels (i.e., to treat

   each priority value as a separate priority), ….  That is, an

   implementation that only supports N priority levels (where N < 19)

   will internally round up a syntactically valid priority value that

   isn't supported to the next higher supported number (or to the

   highest supported priority, if the value is higher than any supported priority).

-        This raises the question to have this type of  guideline if considered useful.

 

So to have your feedback

 

Best regards

 

JJacques

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C
Envoyé : jeudi 15 octobre 2015 12:33
À : Lee, Jay; ken carlberg; Steve Donovan
Cc : dime@ietf.org
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

 

A couple thoughts:

1.      There needs to be a default value defined by the standard, so that equipment have the same value leaving the factory

2.      This value can be over written based on local policy

3.      Should have an extensibility bit in order to and more values in the future

 

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay
Sent: Thursday, October 15, 2015 6:16 AM
To: ken carlberg <carlberg@g11.org.uk>; Steve Donovan <srdonovan@usdonovans.com>
Cc: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

 

From my side, some more discussion on Steve’s mail may be needed.

 

‘Should’ vs. ‘Must’:

One can say that ‘Should’ is not mandatory. But, in practice, this is a fairly strong statement, and often taken as required. So in this sense, the proposed Note is certainly helpful. But, since we allow operators to override the value, I don’t see the reason why we use ‘Should’. My suggestion is using ‘May’.

 

PRIORITY_14 priority:

Since operators can overwrite it, I was not too concerned about it. But if we want to put some value, why ‘14’? A value lower than 14 is suggested in order to allow more rooms for lower priorities.

 

Jay

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg
Sent: Wednesday, October 14, 2015 8:40 AM
To: Steve Donovan
Cc: dime@ietf.org
Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

 

with respect to the diff-serv example brought up below, some thing to add to that discussion is that it starts off with separate and distinct forwarding behavior whose marked packets provide segmentation of other IP traffic.  The availability of only 6 bits to play with (along with the headaches of transitive trust) also discouraged a line of thought to define end-to-end priority handling versus a per diff-serv domain treatment.  RFC-4594 did provide configuration guidelines, but that’s a different story.

 

So back to a couple of ideas to consider.

 

1) reserved space.  if we go back to the diff-serv model, the diff-serv working group agreed to set aside a set of values that was reserved for experimental use that could be re-assigned some time in the future.  I’m not suggesting that there should be space set side for experiments, but rather it may be prudent to set aside a reserved set of bits/values so that one doesn't need to define a new AVP if in the future there was a need to define added values beyond the 5 (plus some fudge factor) already mentioned on the list. 

 

2) sets of users.  previous work (e.g., rfc-4412, rfc-6710) recognized that there can be several sets of users/services that are distinct from each other and yet need to prioritize the traffic.  I bring this up because the draft already identifies two sets of users in sections 5.1 and 5.2 (note: I’m assuming that the latter is aimed at the general public and related to 911/112/999 type calls, which should probably be more specific in the draft).  And there is also the potential of Firstnet users in the US.

 

As a side note, the distinction and separation of general public and other prioritized users in public phone infrastructures is not exclusive to the US, so the group should not be concerned that this is a US centric effort.  There has been GTPS in the UK, as well as other systems in other countries.  The RFC is a bit dated, but feel free to go over rfc-4190 for added background.

 

and just to reiterate.  I’m not making recommendations in the above — just bringing up some food for thought.

 

-ken

 

 

On Oct 14, 2015, at 10:12 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 

Jay,

The current text is a SHOULD level requirement:

   When there is a mix of transactions specifying priority in request
   messages and transactions that do not have the priority specified,
   transactions that do not have a specified priority SHOULD be treated
   as having the PRIORITY_14 priority.

As such, operators can choose to either not implement a priority or define a different value for their network.

I propose adding the following note after this paragraph to further explain why it is a SHOULD and not a MUST:

      Note: There are scenarios where operators might want to 
      specify a different default value for transactions that do not
      have an explicit priority.  In this case, the operator defined
      local policy would override the use of PRIORITY_14 as
      the default priority.

This leaves the ability for there to be deterministic behavior in Diameter networks that require a default to be defined and are happy with the specified default.  It also gives operators the ability to define a different behavior, most likely with some priority handling/mapping at the edge of the network.

Does this address your concerns?

Regards,

Steve

On 10/14/15 2:59 AM, Lee, Jay wrote:

Regarding the issue of whether we need to specify a default value or not, there are pros and cons.

 

If we specify a value for the default case, we can see the benefits in scenarios between different operator networks, but we take away important options on what operators can do with priority values. On the other hand, if we do not specify the default value, operators may have more options, but there is a question of what to do for this inter-PLMN cases when the networks may use different default values.

 

In practice, this issue can be addressed at the edge of the network, where Diameter edge agent (DEA) can perform some priority mapping based on bilateral roaming agreement (or SLA (service level agreement)) and other means to insure the proper handling. One may argue that this is not as good as the ‘deterministic’ case, but operator should be able handle this in a reasonable way. We are fully aware of the fact that, in case of this ‘non-deterministic’ case, the default value can differ from one operator network to another, and it becomes difficult to guarantee the intended priority handling. Despite this, we still prefer giving options to operators by not specifying the default value.

 

What we are saying here, however, is not anything new. This is the typical way of handling priority levels. If anything, specifying the default value would be something new. As already mentioned in CT discussion, there is a good example of this – Internet QoS, more specifically DiffServ.

 

In order to guarantee end-to-end QoS for a specific service, IETF could have specified a value (DiffServ codepoint) for the specific service to have predetermined handling of the traffic, but IETF did not. Instead, DiffServ simply provided a framework for operators to have its own  classification and differentiated treatment of the services. To guarantee end-to-end QoS across different networks, then, operators need to do packet inspection, (re)classification, QoS mapping, use of SLA and possibly others at the edge of network (edge router). Therefore, in the DiffServ architecture, intelligence was pushed to the edge of the network. While the end results may not be guaranteed as well as in the case of predetermined handling, it was still a preferred way to give flexibility to operators. My point is that we went through all these troubles to give options of priority handling to operators.

 

By the way, if we are thinking of possibility of specifying the default value, are we assuming that all operators are interested in this feature (default value in the middle, and high and low priorities at other ends)? Aren’t there other operators who are not interested in this feature? I know that at least there is one – Verizon. We have no interest in this feature, and no plan for implementing it. We are OK, if other operators are interested in this feature, and the default value is NOT specified. But we are certainly not happy if DIME is trying to impose this on us.

 

Jay

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Tuesday, October 13, 2015 10:55 AM
To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; dime@ietf.org; Pollini, Gregory P
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels

 

Assuming that we define a range of 3 values,

Assuming that 0 is the lowest priority and 2 the highest,

Assuming that an agent receives 4 messages at the same time while being in overload control:

·       1) ULR with Prio-0

·       2) ULR with Prio-1

·       3) ULR with Prio-2

·       4) ULR with no priority AVP

 

Assuming that the default is locally defined as proposed below,

 

How do you know that the ULR with priority 2 will be handled with a higher priority  than the request without priority indication?

And what about ULR message with priority 1 with two levels of highest priority e.g. emergency/Important and government/very important?

 

Sorry if the answer is obvious but I fail to understand.

 

Lionel

 

 

                                          

De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] 
Envoyé : samedi 3 octobre 2015 01:21
À : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; dime@ietf.org; Pollini, Gregory P
Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels

 

Hello all,

 

Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined.

 

Having 15 rather than 16 would be useful from an interworking point of view on Diameter interfaces connecting to the EPS.  

 

Also, my understanding has been that the default value is per local policy. 

 

My 2 cents....

Viqar 

From: DiME [dime-bounces@ietf.org] on behalf of lionel.morand@orange.com [lionel.morand@orange.com]
Sent: Thursday, October 01, 2015 3:36 AM
To: Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels

Hi,

 

I think that the case "no Priority indication in request" is the default situation today.

So if we agree that it should be possible to explicitly indicate a request with a lower priority, we should divide the range of priority values in three sub-ranges: [lower priorities][no priority indication][higher priorities], e.g. with 17 values: [0-7][8][9-16].

If any operator can freely fix the default value, there would be no way to ensure the sender that a request with a specific priority value (e.g. 6) will be handled with a lower or higher priority than a request with no priority indication.

 

Therefore, for a deterministic handling mechanism, I think that it is then more relevant to define a standard value for the default value.

 

Regards,

 

Lionel

 

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn
Envoyé : mercredi 30 septembre 2015 22:53
À : DOLLY, MARTIN C
Cc : DiME; dime@ietf.org
Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels

 

Same here.  The "default priority" should be a matter of local policy. 

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. 



From:        "DOLLY, MARTIN C" <md3135@att.com> 
To:        Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org> 
Date:        09/30/2015 04:40 PM 
Subject:        Re: [Dime] [dime] #92 (drmp): Range of priority levels 
Sent by:        "DiME" <dime-bounces@ietf.org>




Me as well 
  
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Wednesday, September 30, 2015 4:38 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels 
  
I'm okay with Jay's proposal on not specifying a default value.

Steve 
On 9/30/15 3:27 PM, Lee, Jay wrote: 
Hi Steve and all, 
  
For the first proposal, as I indicated, I support increasing the number of priority levels up to 16. 
  
I am also fine with the second proposal. My question is: do we need to mandate this feature, as individual operators have different situations? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that when there is no DRMP AVP, this correspond to ‘normal traffic’ without a particular high or low priority. Then each operator can map this default to a value (e.g., 8 or something else) that they feel appropriate. 
  
Thanks, 
  
Jay 



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

_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

 

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


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

 



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

--------------040600090908010804080702-- From nobody Fri Oct 23 09:57:44 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866861A870C for ; Fri, 23 Oct 2015 09:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rxMkSzB0nha for ; Fri, 23 Oct 2015 09:57:29 -0700 (PDT) Received: from eris.verizonwireless.com (eris.verizonwireless.com [137.188.99.119]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0E01A874F for ; Fri, 23 Oct 2015 09:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizonwireless.com; i=@verizonwireless.com; q=dns/txt; s=prodmail; t=1445619448; x=1477155448; h=from:to:subject:date:references:in-reply-to:mime-version; bh=XN9jvywCQTLd5aH0O5mAko27gOPNgYm/+h3DUgY5QMM=; b=oYuvYrCWOZSx17f9N0on2/yDLxLK7TMyWy7OzLllVi56n8YZ7qr5e/ZX eH3x61qY7Ix698tYNNtVSWigoQWyZh2ICOXLB0Dh01G0oOxnY1SjH0RQ/ smpeIAisWIKE+A063+FAoXnmbAzgsRxCMcskFTDcMrwKz92GeOrC52cdx 4=; X-Host: surveyor.tdc.vzwcorp.com Received: from casac1exh001.uswin.ad.vzwcorp.com ([10.11.218.43]) by eris.verizonwireless.com with ESMTP/TLS/AES128-SHA; 23 Oct 2015 12:57:26 -0400 Received: from CASAC1EXP009.uswin.ad.vzwcorp.com ([fe80::558c:d7cc:1a42:f4d6]) by CASAC1EXH001.uswin.ad.vzwcorp.com ([::1]) with mapi id 14.03.0146.000; Fri, 23 Oct 2015 09:57:16 -0700 From: "Lee, Jay" To: "dime@ietf.org" Thread-Topic: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) Thread-Index: AQHRBzKIwn0SbO3rXUW/ebDof+lRcp5sOcGAgAtoZjCAAZc3ZYAAEqiA Date: Fri, 23 Oct 2015 16:57:16 +0000 References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> <20151014075941.062E21B2C1F@ietfa.amsl.com> <561E62C9.20500@usdonovans.com> <1431d0b2-5ae7-426e-b5ff-42b23fecbee5@CASAC1EXH002.uswin.ad.vzwcorp.com> <20151015101558.111761ACD5C@ietfa.amsl.com> <3e7a25c8-5eea-49a5-9905-3009c4dc45b8@NYORA1HUB001.uswin.ad.vzwcorp.com> <20151023055927.9223C1B3292@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.11.60.250] Content-Type: multipart/alternative; boundary="_000_C026C31E3CD6CA43953D6D95AB48048003A903CASAC1EXP009uswin_" MIME-Version: 1.0 Message-Id: <20151023165728.7D0E01A874F@ietfa.amsl.com> Archived-At: Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2015 16:57:43 -0000 --_000_C026C31E3CD6CA43953D6D95AB48048003A903CASAC1EXP009uswin_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please see my comments inline. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Friday, October 23, 2015 8:02 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Please see my comments inline. Steve On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote: See inline From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay Sent: Friday, October 23, 2015 1:59 AM To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) ; dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Some further comments from my side: */ If we need to assign (but not specify) a value to the default case, we n= eed to make it clear that this value can be overwritten by operators, and t= he value is for some use cases like e.g., equipment having the same value w= hen leaving the factory, so that there would be no misunderstanding. mcd- ok SRD> I think the current proposed text makes this clear. [JL] Agree that the current text is OK especially when we use 'May' in plac= e of 'Should'. */ Since we agree that the default value is per local policy, 'May' is pref= erred to 'Should' in order not to cause confusion. mcd-ok SRD> I'm okay with making this a MAY. [JL] Agreed */ For assignment of the default value, I am quite open. But any value betw= een 9 - 12 seems reasonable to me. mcd- value should allow for assigning lower values, though a carrier can as= sign what they want in their network, there needs to be a common meaning at= the interconnection point SRD> I'm open to any value we decide on. If there are real use cases that = require pushing the default value more to the middle then we should do so. = At this point I've heard one use case for the default being something othe= r then the lowest value, thus the proposal to use priority_14 as the defaul= t. */ Current proposal of 16 values may be enough now, but I am fine with hav= ing an extensibility bit to be future proof. mcd-ok SRD> I don't see a compelling argument to move beyond 16. In addition, it isn't clear to me that there is value in defining an extens= ibility mechanism beyond what is already supported by Diameter. Doing so w= ould add significant complexity to the DRMP mechanism for something that, i= n my view, has a low probability of being used. I propose that we not allow extending the DRMP AVP. Rather we require that= any extension require a new AVP. We can then leave it to the document tha= t proposes the extension to deal with determining whether send the DRMP AVP= or the newly defined DRMPv2 AVP. [JL] When we proposed that the range be extended to 16, we thought that '16= ' was large enough and future proof. I am okay with having an extensibility bit, if other companies want it. Tha= t said, I agree that it has a low probability of being used and added compl= exity. */ I am not sure of alternative encoding method (say, +9 to -9 per JJacques= ' proposal) compared to the current enumerated type of DRMP. It offers a lo= gical way of assigning a value 0 to the default case. But it offers less fl= exibility to operators, since the default value may not be easily moved to = have more higher/lower priority values. Also, we are used to the enumerated= type of DRMP and just want to have extension from 5 to 16, but this may r= equire more deviation from the current design and thinking. For this, I wou= ld like to see more on qualitative pros/cons, but, given its little benefit= , I am reluctant to accept this alternative. SRD> I agree that I don't see value in the +9 to -9 proposal. [JL] Agreed From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: Thursday, October 22, 2015 9:39 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Hi 1. PRIORITY_14 as default priority value only allows one level of lowe= r priority (PRIORITY_15) than the default one; this seems not enough. As = use cases, we may have some Machine type Communication (LTC) devices that = may have lower priorities that normal communications without priority. Eve= n within a Diameter application, some commands may have a lower priority as= having a secundary importance. Then which default value ? - it could be PRIORITY_8 in the middle, or if we prefer to have a l= arger range for higher priorities than for lower priorities, the default = value could be e.g. PRIORITY_10, giving 9 higher priorities and 5 lower p= riorities than the default one. I would have a preference for this value PR= IORITY_10. 2. About extensibility, the current range of 16 values is already larg= e, but we can have a reserved value to indicate a further extension. With = an enumerated AVP, there is no possibility to add new values. 3. I also had a look to some other IETF RFCs addressing priorities tha= t Ken mentioned, so to see if we can benefit from these approaches although= done for different contexts. - in RFC 4412 (Resource-Priority Header in SIP), wps and ets namespa= ces have a range of 5 values (0 to 4) with 0 as the highest priority . But= I have not found some indication (I may have missed it) about the default= priority (I mean a SIP request without Resource-Priority Header compared= to a SIP request with the Header). Implicitly, I would assume a SIP reque= st without Resource-Priority Header corresponds to the lowest priority. = DRMP has a similar approach but with a larger range and also lower priorit= ies. - RFC 6710 (priority for SMTP), uses another encoding of the prior= ity values with an integer between -9 and +9. Lower priorities are negativ= e an higher priority being positive. When a value increases, it means a hig= her priority, so the opposite to DRMP, wps or ets. But the value 0 is her= e naturally the default value. So this is an encoding alternative to the = Enumerated type of the DRMP AVP which avoids the question of the default va= lue. Note: RFC 6710 also defines some Priority Assignment Policies using a subs= et of the range. RFC 6710 has also this guideline : SMTP servers compliant with this specification are not required to support all 19 distinct priority levels (i.e., to treat each priority value as a separate priority), .... That is, an implementation that only supports N priority levels (where N < 19) will internally round up a syntactically valid priority value that isn't supported to the next higher supported number (or to the highest supported priority, if the value is higher than any supported pr= iority). - This raises the question to have this type of guideline if consid= ered useful. So to have your feedback Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C Envoy=E9 : jeudi 15 octobre 2015 12:33 =C0 : Lee, Jay; ken carlberg; Steve Donovan Cc : dime@ietf.org Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp)= : Range of priority levels) A couple thoughts: 1. There needs to be a default value defined by the standard, so that = equipment have the same value leaving the factory 2. This value can be over written based on local policy 3. Should have an extensibility bit in order to and more values in the= future From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay Sent: Thursday, October 15, 2015 6:16 AM To: ken carlberg >; Steve D= onovan > Cc: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) >From my side, some more discussion on Steve's mail may be needed. 'Should' vs. 'Must': One can say that 'Should' is not mandatory. But, in practice, this is a fai= rly strong statement, and often taken as required. So in this sense, the pr= oposed Note is certainly helpful. But, since we allow operators to override= the value, I don't see the reason why we use 'Should'. My suggestion is us= ing 'May'. PRIORITY_14 priority: Since operators can overwrite it, I was not too concerned about it. But if = we want to put some value, why '14'? A value lower than 14 is suggested in = order to allow more rooms for lower priorities. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg Sent: Wednesday, October 14, 2015 8:40 AM To: Steve Donovan Cc: dime@ietf.org Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): R= ange of priority levels) with respect to the diff-serv example brought up below, some thing to add t= o that discussion is that it starts off with separate and distinct forwardi= ng behavior whose marked packets provide segmentation of other IP traffic. = The availability of only 6 bits to play with (along with the headaches of = transitive trust) also discouraged a line of thought to define end-to-end p= riority handling versus a per diff-serv domain treatment. RFC-4594 did pro= vide configuration guidelines, but that's a different story. So back to a couple of ideas to consider. 1) reserved space. if we go back to the diff-serv model, the diff-serv wor= king group agreed to set aside a set of values that was reserved for experi= mental use that could be re-assigned some time in the future. I'm not sugg= esting that there should be space set side for experiments, but rather it m= ay be prudent to set aside a reserved set of bits/values so that one doesn'= t need to define a new AVP if in the future there was a need to define adde= d values beyond the 5 (plus some fudge factor) already mentioned on the lis= t. 2) sets of users. previous work (e.g., rfc-4412, rfc-6710) recognized that= there can be several sets of users/services that are distinct from each ot= her and yet need to prioritize the traffic. I bring this up because the dr= aft already identifies two sets of users in sections 5.1 and 5.2 (note: I'm= assuming that the latter is aimed at the general public and related to 911= /112/999 type calls, which should probably be more specific in the draft). = And there is also the potential of Firstnet users in the US. As a side note, the distinction and separation of general public and other = prioritized users in public phone infrastructures is not exclusive to the U= S, so the group should not be concerned that this is a US centric effort. = There has been GTPS in the UK, as well as other systems in other countries.= The RFC is a bit dated, but feel free to go over rfc-4190 for added backg= round. and just to reiterate. I'm not making recommendations in the above - just = bringing up some food for thought. -ken On Oct 14, 2015, at 10:12 AM, Steve Donovan > wrote: Jay, The current text is a SHOULD level requirement: When there is a mix of transactions specifying priority in request messages and transactions that do not have the priority specified, transactions that do not have a specified priority SHOULD be treated as having the PRIORITY_14 priority. As such, operators can choose to either not implement a priority or define = a different value for their network. I propose adding the following note after this paragraph to further explain= why it is a SHOULD and not a MUST: Note: There are scenarios where operators might want to specify a different default value for transactions that do not have an explicit priority. In this case, the operator defined local policy would override the use of PRIORITY_14 as the default priority. This leaves the ability for there to be deterministic behavior in Diameter = networks that require a default to be defined and are happy with the specif= ied default. It also gives operators the ability to define a different beh= avior, most likely with some priority handling/mapping at the edge of the n= etwork. Does this address your concerns? Regards, Steve On 10/14/15 2:59 AM, Lee, Jay wrote: Regarding the issue of whether we need to specify a default value or not, t= here are pros and cons. If we specify a value for the default case, we can see the benefits in scen= arios between different operator networks, but we take away important optio= ns on what operators can do with priority values. On the other hand, if we = do not specify the default value, operators may have more options, but ther= e is a question of what to do for this inter-PLMN cases when the networks m= ay use different default values. In practice, this issue can be addressed at the edge of the network, where = Diameter edge agent (DEA) can perform some priority mapping based on bilate= ral roaming agreement (or SLA (service level agreement)) and other means to= insure the proper handling. One may argue that this is not as good as the = 'deterministic' case, but operator should be able handle this in a reasonab= le way. We are fully aware of the fact that, in case of this 'non-determini= stic' case, the default value can differ from one operator network to anoth= er, and it becomes difficult to guarantee the intended priority handling. D= espite this, we still prefer giving options to operators by not specifying = the default value. What we are saying here, however, is not anything new. This is the typical = way of handling priority levels. If anything, specifying the default value = would be something new. As already mentioned in CT discussion, there is a g= ood example of this - Internet QoS, more specifically DiffServ. In order to guarantee end-to-end QoS for a specific service, IETF could hav= e specified a value (DiffServ codepoint) for the specific service to have p= redetermined handling of the traffic, but IETF did not. Instead, DiffServ s= imply provided a framework for operators to have its own classification an= d differentiated treatment of the services. To guarantee end-to-end QoS acr= oss different networks, then, operators need to do packet inspection, (re)c= lassification, QoS mapping, use of SLA and possibly others at the edge of n= etwork (edge router). Therefore, in the DiffServ architecture, intelligence= was pushed to the edge of the network. While the end results may not be gu= aranteed as well as in the case of predetermined handling, it was still a p= referred way to give flexibility to operators. My point is that we went thr= ough all these troubles to give options of priority handling to operators. By the way, if we are thinking of possibility of specifying the default val= ue, are we assuming that all operators are interested in this feature (defa= ult value in the middle, and high and low priorities at other ends)? Aren't= there other operators who are not interested in this feature? I know that = at least there is one - Verizon. We have no interest in this feature, and n= o plan for implementing it. We are OK, if other operators are interested in= this feature, and the default value is NOT specified. But we are certainly= not happy if DIME is trying to impose this on us. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, October 13, 2015 10:55 AM To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org; Pollini, Gregory P Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Assuming that we define a range of 3 values, Assuming that 0 is the lowest priority and 2 the highest, Assuming that an agent receives 4 messages at the same time while being in = overload control: * 1) ULR with Prio-0 * 2) ULR with Prio-1 * 3) ULR with Prio-2 * 4) ULR with no priority AVP Assuming that the default is locally defined as proposed below, How do you know that the ULR with priority 2 will be handled with a higher = priority than the request without priority indication? And what about ULR message with priority 1 with two levels of highest prior= ity e.g. emergency/Important and government/very important? Sorry if the answer is obvious but I fail to understand. Lionel De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] Envoy=E9 : samedi 3 octobre 2015 01:21 =C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C Cc : DiME; dime@ietf.org; Pollini, Gregory P Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels Hello all, Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.21= 2 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defi= ned. Having 15 rather than 16 would be useful from an interworking point of view= on Diameter interfaces connecting to the EPS. Also, my understanding has been that the default value is per local policy. My 2 cents.... Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf = of lionel.morand@orange.com [lionel.morand= @orange.com] Sent: Thursday, October 01, 2015 3:36 AM To: Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Hi, I think that the case "no Priority indication in request" is the default si= tuation today. So if we agree that it should be possible to explicitly indicate a request = with a lower priority, we should divide the range of priority values in thr= ee sub-ranges: [lower priorities][no priority indication][higher priorities= ], e.g. with 17 values: [0-7][8][9-16]. If any operator can freely fix the default value, there would be no way to = ensure the sender that a request with a specific priority value (e.g. 6) wi= ll be handled with a lower or higher priority than a request with no priori= ty indication. Therefore, for a deterministic handling mechanism, I think that it is then = more relevant to define a standard value for the default value. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn Envoy=E9 : mercredi 30 septembre 2015 22:53 =C0 : DOLLY, MARTIN C Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels Same here. The "default priority" should be a matter of local policy. Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "DOLLY, MARTIN C" > To: Steve Donovan >, "dime@ietf.org" > Date: 09/30/2015 04:40 PM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" = > ________________________________ Me as well From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, September 30, 2015 4:38 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels I'm okay with Jay's proposal on not specifying a default value. Steve On 9/30/15 3:27 PM, Lee, Jay wrote: Hi Steve and all, For the first proposal, as I indicated, I support increasing the number of = priority levels up to 16. I am also fine with the second proposal. My question is: do we need to mand= ate this feature, as individual operators have different situations? Perhap= s some flexibility should be allowed? Instead of mandating it, we can inclu= de the statement that when there is no DRMP AVP, this correspond to 'normal= traffic' without a particular high or low priority. Then each operator can= map this default to a value (e.g., 8 or something else) that they feel app= ropriate. Thanks, Jay _______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_C026C31E3CD6CA43953D6D95AB48048003A903CASAC1EXP009uswin_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please see my comments in= line.

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Friday, October 23, 2015 8:02 AM
To: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Please see my comment= s inline.

Steve

On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote:

See inline

 <= /p>

From: DiME [= mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay
Sent: Friday, October 23, 2015 1:59 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) <jean-jacques.trottin@alcatel-lucent.com>; dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Some further comments fro= m my side:

 <= /p>

*/ If we need to assign (= but not specify) a value to the default case, we need to make it clear that= this value can be overwritten by operators, and the value is for some use cases like e.g., equipment having the same value when leav= ing the factory, so that there would be no misunderstanding.

mcd- ok=

SRD> I think the current proposed text makes this= clear.
[JL] Agree that the current text is OK especi= ally when we use ‘May’ in place of ‘Should’.=

 <= /p>

mcd-ok

SRD> I'm okay with making this a MAY.

[JL]  Agreed

 

mcd- value should allow f= or assigning lower values, though a carrier can assign what they want in th= eir network, there needs to be a common meaning at the interconnection point

SRD> I'm open to any value we decide on.  If= there are real use cases that require pushing the default value more to th= e middle then we should do so.  At this point I've heard one use case = for the default being something other then the lowest value, thus the proposal to use priority_14 as the default.  <= o:p>

 <= /p>

 <= /p>

mcd-ok

SRD> I don't see a compelling argument to move be= yond 16. 
In addition, it isn't clear to me that there is value in defining an extens= ibility mechanism beyond what is already supported by Diameter.  Doing= so would add significant complexity to the DRMP mechanism for something th= at, in my view, has a low probability of being used.

I propose that we not allow extending the DRMP AVP.  Rather we require= that any extension require a new AVP.  We can then leave it to the do= cument that proposes the extension to deal with determining whether send th= e DRMP AVP or the newly defined DRMPv2 AVP. 
[JL] When we proposed that the range be exten= ded to 16, we thought that ‘16’ was large enough and future pro= of.

I am okay with having = an extensibility bit, if other companies want it. That said, I agree that i= t has a low probability of being used and added complexity.

 

 <= /p>

SRD> I agree that I don't see value in the +9= to -9 proposal.

[JL] Agreed

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Thursday, October 22, 2015 9:39 AM
To: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Hi

 <= /p>

1.      PRIORITY_14 as default priority value onl= y allows one level of lower priority (PRIORITY_15)  than the default o= ne; this seems not enough.  As use cases, we may have  some Machine type Communication (LTC) devices that may have lower priorities th= at normal communications without priority.  Even within a Diameter app= lication, some commands may have a lower priority as having a secundary imp= ortance.

 

Then which default  value ?

- &nbs= p;      it could be PRIORITY_8 in the middle, or = if we prefer to have a  larger range for higher priorities  than = for lower priorities,  the default value could be  e.g. PRIORITY_= 10,  giving 9 higher priorities and 5 lower priorities than the default one. I = would have a preference for this value PRIORITY_10.

 <= /p>

2.      About extensibility, the current range of= 16 values is already large, but we can have  a reserved value to indi= cate a further extension. With  an enumerated AVP, there is no possibility to add new values. 

 <= /p>

3.      I also had a look to some other IETF RFCs= addressing priorities that Ken mentioned, so to see if we can benefit from= these approaches although done for different contexts.

- &nbs= p;      in RFC 4412 (Resource-Priority Header in = SIP), wps and ets namespaces have a range of 5 values (0 to 4) with 0 as th= e highest priority  . But I have not found some indication  (I may have missed it) about the default priority  (I mean a SIP requ= est without  Resource-Priority Header compared  to a SIP request = with the Header). Implicitly, I would assume a SIP request without  Re= source-Priority Header corresponds to  the lowest priority.  DRMP has a similar approach but with  a larger range and also l= ower priorities.

 <= /p>

- &nbs= p;      RFC  6710 (priority for SMTP),  = ;uses another encoding of the priority values with an integer between -9 an= d +9. Lower priorities  are negative an higher priority being posi= tive. When a value increases, it means a higher priority, so the opposite  = to DRMP, wps or ets.  But the value 0 is here naturally the default va= lue. So this is an encoding alternative  to the  Enumerated type = of the DRMP AVP which avoids the question of the default value.

Note: RFC  67= 10 also defines some Priority Assignment Policies using a subset of the ran= ge.

 <= /p>

   SMTP server= s compliant with this specification are not

   required to supp= ort all 19 distinct priority levels (i.e., to treat

   each priority va= lue as a separate priority), ….  That is, an

   implementation t= hat only supports N priority levels (where N < 19)

   will internally = round up a syntactically valid priority value that

   isn't supported = to the next higher supported number (or to the

   highest supporte= d priority, if the value is higher than any supported priority).

- &nbs= p;      This raises the question to have this typ= e of  guideline if considered useful.

So to have your feedback

 <= /p>

Best regards<= /o:p>

 <= /p>

JJacques

 <= /p>

De : DiME [mailto:d= ime-bounces@ietf.org] De la part de DOLLY, MARTIN C
Envoy=E9 : jeudi 15 octobre 2015 12:33
=C0 : Lee, Jay; ken carlberg; Steve Donovan
Cc : dime@ietf.org
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime= ] #92 (drmp): Range of priority levels)

 

A couple thoughts:=

1. &nb= sp;    There needs to be a default value defined= by the standard, so that equipment have the same value leaving the factory=

2. &nb= sp;    This value can be over written based on l= ocal policy

3. &nb= sp;    Should have an extensibility bit in order= to and more values in the future

 <= /p>

 <= /p>

From: DiME [= mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay
Sent: Thursday, October 15, 2015 6:16 AM
To: ken carlberg <carlberg= @g11.org.uk>; Steve Donovan <srdonovan@usdonovans.com>
Cc: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

From my side, some more d= iscussion on Steve’s mail may be needed.

 <= /p>

‘Should’ vs. = ‘Must’:

One can say that ‘S= hould’ is not mandatory. But, in practice, this is a fairly strong st= atement, and often taken as required. So in this sense, the proposed Note is certainly helpful. But, since we allow operators to override the v= alue, I don’t see the reason why we use ‘Should’. My sugg= estion is using ‘May’.

 <= /p>

PRIORITY_14 priority:

Since operators can overw= rite it, I was not too concerned about it. But if we want to put some value= , why ‘14’? A value lower than 14 is suggested in order to allow more rooms for lower priorities.

 <= /p>

Jay

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg
Sent: Wednesday, October 14, 2015 8:40 AM
To: Steve Donovan
Cc: dime@ietf.org
Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (d= rmp): Range of priority levels)

 

with respect to the diff-serv example brought up bel= ow, some thing to add to that discussion is that it starts off with separat= e and distinct forwarding behavior whose marked packets provide segmentatio= n of other IP traffic.  The availability of only 6 bits to play with (along with the headaches of transitive trust)= also discouraged a line of thought to define end-to-end priority handling = versus a per diff-serv domain treatment.  RFC-4594 did provide configu= ration guidelines, but that’s a different story.

 

So back to a couple of ideas to consider.=

 

1) reserved space.  if we go back to the diff-s= erv model, the diff-serv working group agreed to set aside a set of values = that was reserved for experimental use that could be re-assigned some time = in the future.  I’m not suggesting that there should be space set side for experiments, but rather it may be prude= nt to set aside a reserved set of bits/values so that one doesn't need to d= efine a new AVP if in the future there was a need to define added values be= yond the 5 (plus some fudge factor) already mentioned on the list. 

 

2) sets of users.  previous work (e.g., rfc-441= 2, rfc-6710) recognized that there can be several sets of users/services th= at are distinct from each other and yet need to prioritize the traffic. &nb= sp;I bring this up because the draft already identifies two sets of users in sections 5.1 and 5.2 (note: I’m assu= ming that the latter is aimed at the general public and related to 911/112/= 999 type calls, which should probably be more specific in the draft).  = ;And there is also the potential of Firstnet users in the US.

 

As a side note, the distinction and separation of ge= neral public and other prioritized users in public phone infrastructures is= not exclusive to the US, so the group should not be concerned that this is= a US centric effort.  There has been GTPS in the UK, as well as other systems in other countries.  The RFC= is a bit dated, but feel free to go over rfc-4190 for added background.

 

and just to reiterate.  I’m not making re= commendations in the above — just bringing up some food for thought.<= o:p>

 

-ken

 

 

On Oct 14, 2015, at 10:12 AM, Steve Donovan <srdonovan@usdonovans.com> wr= ote:

 

Jay,

The current text is a SHOULD level require= ment:

   When there is a mix of transa= ctions specifying priority in request
   messages and transactions tha= t do not have the priority specified,
   transactions that do not have= a specified priority SHOULD be treated
   as having the PRIORITY_14 pri= ority.

As such, operators can choose to either no= t implement a priority or define a different value for their network.

I propose adding the following note after = this paragraph to further explain why it is a SHOULD and not a MUST:=

      Note: There= are scenarios where operators might want to 
      specify a d= ifferent default value for transactions that do not
      have an exp= licit priority.  In this case, the operator defined
      local polic= y would override the use of PRIORITY_14 as
      the default= priority.

This leaves the ability for there to be de= terministic behavior in Diameter networks that require a default to be defi= ned and are happy with the specified default.  It also gives operators= the ability to define a different behavior, most likely with some priority handling/mapping at the edge of the network= .

Does this address your concerns?
Regards,

Steve

On 10/14/15= 2:59 AM, Lee, Jay wrote:

From: DiME [mai= lto:dime-bounces@ietf.org]=  On Behalf Of lionel.morand@orange.com
Sent: Tuesday, Oct= ober 13, 2015 10:55 AM
To: Shaikh, Viqar = A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; <= a href=3D"mailto:dime@ietf.org">dime@ietf.org; Pollini, Gregory P
Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 

=B7     &nbs= p; 1) ULR with Prio-0

=B7     &nbs= p; 2) ULR with Prio-1

=B7     &nbs= p; 3) ULR with Prio-2

=B7     &nbs= p; 4) ULR with no priority AVP

De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] 
Envoy=E9 : sa= medi 3 octobre 2015 01:21
=C0 : MORAND = Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; dime@ietf.org<= span lang=3D"FR" style=3D"font-size:10.0pt;font-family:"Tahoma",&= quot;sans-serif"">; Pollini, Gregory P
Objet : RE: [= Dime] [dime] #92 (drmp): Range of priority levels

 <= /span>

Hello all,

 

Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS= 29.212 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined.

 

Having 15 rather than 16 would be useful from an interworking point of vie= w on Diameter interfaces connecting to the EPS.  

 

Also, my understanding has been that the default value is per local p= olicy. 

 

My 2 cents....

Viqar 

<= span lang=3D"FR" style=3D"font-size:10.0pt;font-family:"Tahoma",&= quot;sans-serif"">From: DiME [dim= e-bounces@ietf.org] on behalf of lionel.morand@orange.com <= span lang=3D"FR" style=3D"font-size:10.0pt;font-family:"Tahoma",&= quot;sans-serif"">[lionel.morand@orange.com]
Sent: Thursday, Oc= tober 01, 2015 3:36 AM
To: Janet P Gunn; = DOLLY, MARTIN C
Cc: DiME; dime@ietf.org
Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

 <= /span>

De : DiME [mai= lto:dime-bounces@ietf.org]=  De la part de&nbs= p;Janet P Gunn
Envoy=E9 : me= rcredi 30 septembre 2015 22:53
=C0 : DOLLY, = MARTIN C
Cc : DiME; dime@ietf.org<= span lang=3D"FR" style=3D"font-size:10.0pt;font-family:"Tahoma",&= quot;sans-serif"">
Objet : Re: [= Dime] [dime] #92 (drmp): Range of priority levels

 <= /span>

= Same here.  The "default priority" should be a matter of loc= al policy.&n= bsp;

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose. 



From:        = ;"DOLLY, MARTIN C" <md3135@att.c= om> 
To:        <= /span>Steve Donovan <srdonovan@usdonova= ns.com>, "dime@ietf.org" <dime@ietf.org> <= /span>
Date:        = ;09/30/2015 04:40 PM =
Subject:       &n= bsp;Re: [Dime] [dime] #92 (drmp): Range of pri= ority levels=  
Sent by:       &n= bsp;"DiME" <dime-bounces@= ietf.org>




Me as well 
  
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Dono= van
Sent: Wednesday, Sept= ember 30, 2015 4:38 PM
To: dime@ietf.org<= /a>
Subject: Re: [Dime] [dime] #92 (= drmp): Range of priority levels 
  
I'm okay with Jay's proposal on not specify= ing a default value.

Steve <= /span>
On 9/30/15 3:27 PM, Lee, Jay wrote:<= span class=3D"apple-converted-space"> =
Hi Steve and all, =
  
For the first proposal, as I indicated, I s= upport increasing the number of priority levels up to 16. 
  
I am also fine with the second proposal. My= question is: do we need to mandate this feature, as individual operators h= ave different situations? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that whe= n there is no DRMP AVP, this correspond to ‘normal traffic’ wit= hout a particular high or low priority. Then each operator can map this def= ault to a value (e.g., 8 or something else) that they feel appropriate. 
  
Thanks, 
  
Jay 



_______________________= ________________________ 
DiME mailing list 
DiME@ietf.org 
https://www.ietf.org/mailman/li= stinfo/dime   _____________= __________________________________
DiME mailing list
DiME@ietf.org<= /span>
https://ww= w.ietf.org/mailman/listinfo/dime

_____________________________________=
___________________________________________________________________________=
_________
 
Ce message et ses pieces jointes peuv=
ent contenir des informations confidentielles ou privilegiees et ne doivent=
 donc
pas etre diffuses, exploites ou copie=
s sans autorisation. Si vous avez recu ce message par erreur, veuillez le s=
ignaler
a l'expediteur et le detruire ainsi q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration,
Orange decline toute responsabilite s=
i ce message a ete altere, deforme ou falsifie. Merci.

 


This message and its attachments may =
contain confidential or privileged information that may be protected by law=
;


they should not be distributed, used =
or copied without authorisation.


If you have received this email in er=
ror, please notify the sender and delete this message and its attachments.<=
/span>


As emails may be altered, Orange is n=
ot liable for messages that have been modified, changed or falsified.


Thank you.


_____________________________________=
___________________________________________________________________________=
_________
 
Ce message et ses pieces jointes peuv=
ent contenir des informations confidentielles ou privilegiees et ne doivent=
 donc
pas etre diffuses, exploites ou copie=
s sans autorisation. Si vous avez recu ce message par erreur, veuillez le s=
ignaler
a l'expediteur et le detruire ainsi q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration,
Orange decline toute responsabilite s=
i ce message a ete altere, deforme ou falsifie. Merci.

 


This message and its attachments may =
contain confidential or privileged information that may be protected by law=
;


they should not be distributed, used =
or copied without authorisation.


If you have received this email in er=
ror, please notify the sender and delete this message and its attachments.<=
/span>


As emails may be altered, Orange is n=
ot liable for messages that have been modified, changed or falsified.


Thank you.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.ietf.org/mailman/listinfo/di=
me





__________________________________________=
_____

DiME mailing list

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime=

 




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

 

--_000_C026C31E3CD6CA43953D6D95AB48048003A903CASAC1EXP009uswin_-- From nobody Fri Oct 23 10:32:43 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491AD1A8888 for ; Fri, 23 Oct 2015 10:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6oZd213mWx8 for ; Fri, 23 Oct 2015 10:32:37 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::703]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965761A8745 for ; Fri, 23 Oct 2015 10:32:37 -0700 (PDT) Received: from BN1AFFO11FD009.protection.gbl (10.58.52.30) by BN1AFFO11HUB039.protection.gbl (10.58.52.150) with Microsoft SMTP Server (TLS) id 15.1.300.4; Fri, 23 Oct 2015 17:32:32 +0000 Authentication-Results: spf=pass (sender IP is 144.230.172.39) smtp.mailfrom=sprint.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=sprint.com; Received-SPF: Pass (protection.outlook.com: domain of sprint.com designates 144.230.172.39 as permitted sender) receiver=protection.outlook.com; client-ip=144.230.172.39; helo=plsapdm3.corp.sprint.com; Received: from plsapdm3.corp.sprint.com (144.230.172.39) by BN1AFFO11FD009.mail.protection.outlook.com (10.58.52.69) with Microsoft SMTP Server (TLS) id 15.1.306.13 via Frontend Transport; Fri, 23 Oct 2015 17:32:32 +0000 Received: from pps.filterd (plsapdm3.corp.sprint.com [127.0.0.1]) by plsapdm3.corp.sprint.com (8.15.0.59/8.15.0.59) with SMTP id t9NFXRYN024150 for ; Fri, 23 Oct 2015 12:32:31 -0500 Received: from plswe13m08.ad.sprint.com (plswe13m08.corp.sprint.com [144.229.214.27]) by plsapdm3.corp.sprint.com with ESMTP id 1xp4ymdr3h-1 (version=TLSv1/SSLv3 cipher=AES128-SHA256 bits=128 verify=NOT) for ; Fri, 23 Oct 2015 12:32:31 -0500 Received: from PLSWE13M07.ad.sprint.com (2002:90e5:d61a::90e5:d61a) by PLSWE13M08.ad.sprint.com (2002:90e5:d61b::90e5:d61b) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 23 Oct 2015 12:32:31 -0500 Received: from PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8]) by PLSWE13M07.ad.sprint.com ([fe80::208d:c2cd:4516:17d8%24]) with mapi id 15.00.1076.000; Fri, 23 Oct 2015 12:32:31 -0500 From: "Bertz, Lyle T [CTO]" To: "dime@ietf.org" Thread-Topic: Support for IPv6 Extension Headers using a RFC 5777 Filter-Rule AVP Thread-Index: AdENttzpopPBtNyyS4S7QxKQdi40yw== Date: Fri, 23 Oct 2015 17:32:30 +0000 Message-ID: <349404e1d2e14e3d9da97ff260d5d400@PLSWE13M07.ad.sprint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.214.116.29] Content-Type: multipart/alternative; boundary="_000_349404e1d2e14e3d9da97ff260d5d400PLSWE13M07adsprintcom_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD009; 1:DVTWFqNHoicBquruYeihym9T4SSGxKHuYp9L1Tbx+B4mofHvZ/eoLtK4Y8bAp30Hlc3q2t0DXC9NCe3l1Ri3dCAnHC90HXDwduw9W6ChvnvrVd3n5grx+oa6mC4miH1EgqlVSRNU2kosofsGymcYIGpIBqfZExNzlfkHiZOm2LdKXrFzWYfm/6UgKd5SibJ295hhkQBFxw4IoAuzl3vIYE/OGXjDJ7+KSxN+bgvB7FrykAFomIGTgdoJPNGGjiAIjxEJ4RTEQCyTdHbbw4hR3Bhzp9IyVOl/He0n2xeyCBQHYDq1rZ1wkzrZ31YVSVr8UB4x+gpQt0lIIWThSuIA8g== X-Forefront-Antispam-Report: CIP:144.230.172.39; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(199003)(189002)(5250100002)(2900100001)(102836002)(15975445007)(5004730100002)(5007970100001)(81156007)(189998001)(110136002)(97736004)(2501003)(108616004)(5001960100002)(86362001)(107886002)(2351001)(450100001)(229853001)(11100500001)(6806005)(5008740100001)(30436002)(92566002)(87936001)(54356999)(19580405001)(19580395003)(4546004)(33646002)(5003600100002)(84326002)(106466001)(512954002)(24736003)(19625215002)(19300405004)(50986999)(16236675004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB039; H:plsapdm3.corp.sprint.com; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB039; 2:Ou7cgQi4bQOBJPRwt33PkZXUhvxQKVgS7KlDwihEdPbK/af0H1fqc6UWE0QXNwrI+tRCud6JW+XdDNt+zcFXd7NA5PhxmswjOm9dnbq0iUZJ9InpHVSXWf2Pmv+qJTEJOv46Dwo4jiaOgeHgdympMLI0GR+F8DJ5cWDcfSD8aRQ=; 3:mkh1OCaDb0P57IWJ6wxNt04DkYUxDItu4+KFDknaoKSqZo1hB2sFUK7nTrjwa5nRsc2ji/wKkpdCuGapoZhpfqD0ekMYXcmWoff7hnG/l0V52omCh3iqE5aV/2PCR3auRKUIuo4CKH9CwIzqo5rQ5JyoZ2ABh2THOS4bpMpbZ1E552oy+G2j4+dTvKglC2gUDxqYZGJF8bpLdhUQRdaaaVtXCJ2xiDWlQttauD1T5CCmQnwhg9fYLBg/HhKBpaveWapFTlonxXd3AQxG57niNg==; 25:uhXflbir+dGMc+LxVOv8H3aR9RityDZ7Y2ElNnJhAfX3wEq6Xk/ZXuLReeqX6Dtj+HtT50hPQfX4pbqGMvc8/pmY0jEJnzjgj6TYYDjXngMlAFlVUe3ijUih/S76UNYZhKeYvdmhDKtO52dcObFifBTpSO4wHHbDyXchsAqXLNAVGBYPDRaCRZUciCCifqR/Q2VvA64Uz3pEiQW5MM2GSQl/c3QRIVWa1TyF4hhjPY2MrBB2KzyTnqxQmPD2FsmA X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:BN1AFFO11HUB039; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB039; 20:yfD8wubaZQ8Od431EDgrqfo6NAw9/WvivFdLUe/lzHxaRvDJ+hTOVYvtJ6GTX/r20O/eYXPaefYycQoAdp834h7D21Q2vVSlIcEoneHvu38QgvfuWY+Ck7bkAycRAQJT3MivOwBELJB9SAGILofaxtEDpKYocgU0ANdffTEyvvA7F3n4qWyZTTJ2DmoXDPQ6/6Y+QnDhyWh17H0BafTIM6WzGw62CQk4b6e8YpdEb7x4aWV7+MSYPni8dcry1LrJ; 4:PYDuSXvGQ0IuxYBZ9MtJMhagM/lOqo3r0/q9cRneXke38lyXnwLZ30dTvVwR1FGZ1hl6xQuS2BgPqrq2K10VG7r+1qhVUbmmXHiyhgz53JBsHLjaGPGyWHZFvzc/EMoLk14cXauH/v7xNzign2zqK7099nao1UtbwdYs8NKeZ8NO1hmrXMKL4QDYR5qoAkBz7od8p5AN+D7BTVM9+gAtVb4f6AWhDOc+v02IfJXT5hY89rsFVEdR/fSALen9ssTm414Y0AxzcIy95zjRwO05Q6IPRKrp8WZ6V60U241CQZrFzm2dzIHybN4xVAlLEEzTuTBGR6rrMFJxvPX05jQE8cgcoyJktKujLxMXC+ll0HNkPjnXGBSl1Ub3Zl1vF+kKl5DSPgz2gAkKTWLl59imPA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(18430343700868)(108003899814671); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501024)(102215026); SRVR:BN1AFFO11HUB039; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB039; X-Forefront-PRVS: 0738AF4208 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB039; 23:+onjzFU2eRR8uA51DlY+2VXz5eNPR68CEWswE4m?= =?us-ascii?Q?oXHxcShBKg8AGyGFtsK5IUh6EB4NO9yykacQW5lRKDdBbqMphhKar9UgZYnO?= =?us-ascii?Q?a9tor+ZkBieqgEmqoCtFh0HW3GwDJMX185WFWKP9xEy6YEcxT81lcF2kHRpv?= =?us-ascii?Q?U0bZaMxUHmOfAxylOIwDhVWySb39VDTLxNvBn//uedyJddrbL9TYWY6zKE/v?= =?us-ascii?Q?PTAtNvnqy+BRqCAfHcXtNb4ELpQw/vzNIhctaER2TmoPK+ARgfhnpm0E3zjV?= =?us-ascii?Q?topAfgPOlUwBfwn5YaWuvOzeN/S2e+kTsA0WkyXChX2Q80JCcFZ9AUvImhLw?= =?us-ascii?Q?76iNxzOtNGujQ2cwjQ79Is6pli0sAxeESnevDliDNAQlmlfStR4F/zAaYyD3?= =?us-ascii?Q?kVtIzhp3QK+IetrNVOQkawdhxspEgYNjtHmCQSAJzdN0BS/0Rrc11hIB0hFg?= =?us-ascii?Q?+Nr1HnfKL05fU29rPHiiTLz/D/nEZS09cl6QH0mWXIwkCZMnIM/4Qw7XpbAe?= =?us-ascii?Q?zIDfjDOnsO19uGRUeES9X0wdVfcfhDl4w1aXP3Yrfs4i2vPTNBTYvWVk3CmE?= =?us-ascii?Q?eTY1R0KtJoesXp2mXVVXrUGQZatR0F3K5QLeA7kDuvCOoWXc6mQ52vPJAFcp?= =?us-ascii?Q?UKKHRTpmwBrH6gDBcyLMCUjorsdpqLdK5ARZ0Bg3BH1b5pTY06lD73L+FQqb?= =?us-ascii?Q?0hRx82hQG3mdgMxogIoQznUTX/w9N56JGtMNpU4Dsq7JDnAk0kLcRQYOzojy?= =?us-ascii?Q?yuGZCSR9nJxRvejsmwbEh0hJIOYyogNY6SUmeNMllcFAyHUz4yWgpSxsxPIK?= =?us-ascii?Q?NHdBLMwViXvPrhawP1JFGDqAe8Kjb/kpkRLAoflAj/K5zP4dFLMl2J2Hf1eZ?= =?us-ascii?Q?/X31BQYo+R4Lpls7aPjRhRctq3uKa/D3b9woa1MLI6PCRe7WQXUSQNrqEa69?= =?us-ascii?Q?o72vu4GYa+Y/I2GAxmXIQEgJ+umHqaWN/qemtpSYHflV4ygObgoTNyGIXam6?= =?us-ascii?Q?428YLs8/LmGdNAnCROHx9GqC+g3rtyimCT3yiBka02X4VI4K59fTY7hLM5om?= =?us-ascii?Q?0oKDI50q8eKrMpxWVVpXSfR+42dsXBUhHzzcyjq6u/+xpPg+A/upq8DfOlZ5?= =?us-ascii?Q?q3CqxoiokjCiuD4VlrVQCPGb/RsFxJk6O3rzFaEe1Bo57PlRiaMM83OghMQB?= =?us-ascii?Q?P581bCS3dDN4Ki1g=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB039; 5:GyVuNfzO5Huo3vCRx46gQOWja+GnGLHEXAMc6gpRc53Dr9Icex8pxIZaHreGflejdw+Qc5W6ae3eMhlZ25qJfFD8LihX5lfd7DF1qBuAGwDwAKMMPHgITiQReezr5Re7Khp3VnsX9Zf99TzxVxyQeQ==; 24:ocqi21grUEg2xCDj4qvCHOZbFwULFIsftBXuHPCKAmxEcjHX5YI+p57qjQL7e+yyyb1b3qKhr7/4BwlsOne8yNrfvcax9VVeE0V8zxLE6uo= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: sprint.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Oct 2015 17:32:32.4846 (UTC) X-MS-Exchange-CrossTenant-Id: 4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=4f8bc0ac-bd78-4bf5-b55f-1b31301d9adf; Ip=[144.230.172.39]; Helo=[plsapdm3.corp.sprint.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB039 Archived-At: Subject: [Dime] Support for IPv6 Extension Headers using a RFC 5777 Filter-Rule AVP X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 23 Oct 2015 17:32:41 -0000 --_000_349404e1d2e14e3d9da97ff260d5d400PLSWE13M07adsprintcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, RFC 5777 state IP Options AVP "values are managed by IANA under the IP Opti= on Numbers registry". Are IPv6 Extension Headers defined in another RFC (I= am hoping I have overlooked one) or did I miss an option in 5777? Thanks! Lyle Bertz Tech Dev Strategist IV O: 913-315-1245 / M: 816-582-1784 lyle.t.bertz@sprint.com ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. --_000_349404e1d2e14e3d9da97ff260d5d400PLSWE13M07adsprintcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

RFC 5777 state IP Options AVP ̶=
0;values are managed by IANA under the IP Optio=
n Numbers registry”.  Are IPv6 Extension Headers defined =
in another RFC (I am hoping I have overlooked one) or did I miss an option =
in 5777?
 
Thanks!
 
&n=
bsp;

Lyle Bertz

Tech Dev Strategist IV

O: 913-315-1245 / M: 816-= 582-1784

lyle.t.bertz@sprint.com

 

 



This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message.
 --_000_349404e1d2e14e3d9da97ff260d5d400PLSWE13M07adsprintcom_-- From nobody Mon Oct 26 08:08:30 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CBD1B492D for ; Mon, 26 Oct 2015 08:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDpkF3FP1Rj9 for ; Mon, 26 Oct 2015 08:08:26 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DDF51B4936 for ; Mon, 26 Oct 2015 08:07:10 -0700 (PDT) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 9C4404037B for ; Mon, 26 Oct 2015 16:07:08 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 66BE51A0054 for ; Mon, 26 Oct 2015 16:07:08 +0100 (CET) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%19]) with mapi id 14.03.0248.002; Mon, 26 Oct 2015 16:07:08 +0100 From: To: "dime@ietf.org" Thread-Topic: Draft Agenda for Dime session in IETF94 Thread-Index: AdEPluiUl7mESVEtSpa7f5dZFPA0TA== Date: Mon, 26 Oct 2015 15:07:07 +0000 Message-ID: <9951_1445872028_562E419C_9951_18282_1_6B7134B31289DC4FAF731D844122B36E01D4E43A@OPEXCLILM43.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.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dime] Draft Agenda for Dime session in IETF94 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 26 Oct 2015 15:08:28 -0000 Hi, The draft agenda for the next IETF meeting has just been uploaded. Regards, Lionel & Jouni ------------------------------------------------ Chairs: Jouni Korhonen =20 Lionel Morand 1300-1400 TUESDAY, November 3, 2015, Afternoon Session I (60 mins) meeting room: Room 413 Jabber room: dime at jabber.ietf.org (Please join)=20 13:00 - 13:05, Preliminaries (5 minutes) ------------------------------------------ Audio/Video & Remote Presentation Debugging Note Well=20 Note Takers=20 Jabber scribe Agenda bashing=20 13:05 - 13:10, WG Document Status (5 minutes) ------------------------------------------ =09 * draft-ietf-dime-agent-overload-03 --> In WG --> WGLC? *draft-ietf-dime-doic-rate-control-02 --> In WG --> WGLC? * draft-ietf-dime-drmp-01 --> In WG --> WGLC? * draft-ietf-dime-e2e-sec-req-03 --> In WGLC --> Write Up * draft-ietf-dime-group-signaling-05 --> In WG --> WGLC? * draft-ietf-dime-load-01 --> In WG --> WGLC? * draft-ietf-dime-ovli-10 --> Auth48 --> RFC publication Dime working group draft discussions (45 minutes) ------------------------------------------- 13:10 - 13:20 Diameter Request Message Priority, Steve (10 minutes) https://datatracker.ietf.org/doc/draft-ietf-dime-drmp/ 13:30 - 13:40 Diameter Load Control, Steve (10 minutes) https://datatracker.ietf.org/doc/draft-ietf-dime-load/ 13:40 - 13:50 Diameter overload control extension, Steve (10 minutes) https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/ 13:50 - 13:55 Diameter Group Signaling, Marco (5 minutes) https://datatracker.ietf.org/doc/draft-ietf-dime-group-signaling/ Wrap-up and Next (5 minutes) -------------------- 13:55 - 14:00 Next Steps: WG Chairs & ADs (5 minutes)=20 WG Goals/Milestones status, next steps=20=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 authorization. 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 shall not be liable if th= is message was modified, changed or falsified. Thank you. From nobody Mon Oct 26 08:11:42 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA2F1B4929 for ; Mon, 26 Oct 2015 08:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEZvz1F7u7fu for ; Mon, 26 Oct 2015 08:11:22 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40DC1B4911 for ; Mon, 26 Oct 2015 08:11:20 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 3EDCD48E84BDA for ; Mon, 26 Oct 2015 15:11:15 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t9QFBI5I004244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 26 Oct 2015 16:11:18 +0100 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.230]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 26 Oct 2015 16:11:17 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) Thread-Index: AQHRBzKIwn0SbO3rXUW/ebDof+lRcp5sOcGAgAtoZjCAAZc3ZYAAEqiAgASJrNA= Date: Mon, 26 Oct 2015 15:11:17 +0000 Message-ID: References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> <20151014075941.062E21B2C1F@ietfa.amsl.com> <561E62C9.20500@usdonovans.com> <1431d0b2-5ae7-426e-b5ff-42b23fecbee5@CASAC1EXH002.uswin.ad.vzwcorp.com> <20151015101558.111761ACD5C@ietfa.amsl.com> <3e7a25c8-5eea-49a5-9905-3009c4dc45b8@NYORA1HUB001.uswin.ad.vzwcorp.com> <20151023055927.9223C1B3292@ietfa.amsl.com> <20151023165728.7D0E01A874F@ietfa.amsl.com> In-Reply-To: <20151023165728.7D0E01A874F@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D29D46413EFR712WXCHMBA12z_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 26 Oct 2015 15:11:38 -0000 --_000_E194C2E18676714DACA9C3A2516265D29D46413EFR712WXCHMBA12z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Please see my comments also in line. I think we are close to finalise our c= hoice on the different points of this thread Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de Lee, Jay Envoy=E9 : vendredi 23 octobre 2015 18:57 =C0 : dime@ietf.org Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp)= : Range of priority levels) Please see my comments inline. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Friday, October 23, 2015 8:02 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Please see my comments inline. Steve On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote: See inline From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay Sent: Friday, October 23, 2015 1:59 AM To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) ; dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Some further comments from my side: */ If we need to assign (but not specify) a value to the default case, we n= eed to make it clear that this value can be overwritten by operators, and t= he value is for some use cases like e.g., equipment having the same value w= hen leaving the factory, so that there would be no misunderstanding. mcd- ok SRD> I think the current proposed text makes this clear. [JL] Agree that the current text is OK especially when we use 'May' in plac= e of 'Should' [JJ] OK . */ Since we agree that the default value is per local policy, 'May' is pref= erred to 'Should' in order not to cause confusion. mcd-ok SRD> I'm okay with making this a MAY. [JL] Agreed [JJ] Also in favor of a MAY */ For assignment of the default value, I am quite open. But any value betw= een 9 - 12 seems reasonable to me. mcd- value should allow for assigning lower values, though a carrier can as= sign what they want in their network, there needs to be a common meaning at= the interconnection point SRD> I'm open to any value we decide on. If there are real use cases that = require pushing the default value more to the middle then we should do so. = At this point I've heard one use case for the default being something othe= r then the lowest value, thus the proposal to use priority_14 as the defaul= t. [JJ] Regarding use cases, there may be - The case where for "normal" users, an application use the defaul= t value for most of its requests except some which have a lower priority - the case where besides "normal" user (and high priority users), = some users have lower priorities, e.g. Some Machine type Communications (MT= C) devices. So potentially more than one low priority level would be needed. We also have chosen a rather large range of values (16) , allowing flexibil= ity for an operator when they define the number of priorities they want , l= eaving possibility to future additions. If PRIORITY _14 is the default, it = leaves only one lower priority and an operator cannot add a second one ex= cept by choosing a default value other than the 14 value. Then as, in practice, we may expect a range of low priority smaller than t= he range of high priority values, this is why the default value was propose= d to be in the range 9-12 . Then I proposed 10 so to do a proposal but I a= m open on another value. */ Current proposal of 16 values may be enough now, but I am fine with hav= ing an extensibility bit to be future proof. mcd-ok SRD> I don't see a compelling argument to move beyond 16. In addition, it isn't clear to me that there is value in defining an extens= ibility mechanism beyond what is already supported by Diameter. Doing so w= ould add significant complexity to the DRMP mechanism for something that, i= n my view, has a low probability of being used. I propose that we not allow extending the DRMP AVP. Rather we require that= any extension require a new AVP. We can then leave it to the document tha= t proposes the extension to deal with determining whether send the DRMP AVP= or the newly defined DRMPv2 AVP. [JL] When we proposed that the range be extended to 16, we thought that '16= ' was large enough and future proof. I am okay with having an extensibility bit, if other companies want it. Tha= t said, I agree that it has a low probability of being used and added compl= exity. [JJ] JJ I also agree that with 16 values , the offered range is large enoug= h in practice. This point is only to check if it would be easy to do an ext= ension, if we have this requirement in the future. I agree with Steve that= for an extensibility, it will require a new AVP in a new document rather t= han to define a set of reserved values in the DRMP AVP. A point is that it= will require an additional parsing effort for a node to look for this seco= nd AVP even if it is not present most of the time. */ I am not sure of alternative encoding method (say, +9 to -9 per JJacques= ' proposal) compared to the current enumerated type of DRMP. It offers a lo= gical way of assigning a value 0 to the default case. But it offers less fl= exibility to operators, since the default value may not be easily moved to = have more higher/lower priority values. Also, we are used to the enumerated= type of DRMP and just want to have extension from 5 to 16, but this may r= equire more deviation from the current design and thinking. For this, I wou= ld like to see more on qualitative pros/cons, but, given its little benefit= , I am reluctant to accept this alternative. SRD> I agree that I don't see value in the +9 to -9 proposal. [JL] Agreed [J] I presented this second approach so to review the possible alternativ= es as we usually do before selecting the solution, this alternative being a= lready used in a recent RFC. That being said, I am fine with the enumerat= ed DRMP AVP. Best regards JJacques From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: Thursday, October 22, 2015 9:39 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Hi 1. PRIORITY_14 as default priority value only allows one level of lowe= r priority (PRIORITY_15) than the default one; this seems not enough. As = use cases, we may have some Machine type Communication (LTC) devices that = may have lower priorities that normal communications without priority. Eve= n within a Diameter application, some commands may have a lower priority as= having a secundary importance. Then which default value ? - it could be PRIORITY_8 in the middle, or if we prefer to have a l= arger range for higher priorities than for lower priorities, the default = value could be e.g. PRIORITY_10, giving 9 higher priorities and 5 lower p= riorities than the default one. I would have a preference for this value PR= IORITY_10. 2. About extensibility, the current range of 16 values is already larg= e, but we can have a reserved value to indicate a further extension. With = an enumerated AVP, there is no possibility to add new values. 3. I also had a look to some other IETF RFCs addressing priorities tha= t Ken mentioned, so to see if we can benefit from these approaches although= done for different contexts. - in RFC 4412 (Resource-Priority Header in SIP), wps and ets namespa= ces have a range of 5 values (0 to 4) with 0 as the highest priority . But= I have not found some indication (I may have missed it) about the default= priority (I mean a SIP request without Resource-Priority Header compared= to a SIP request with the Header). Implicitly, I would assume a SIP reque= st without Resource-Priority Header corresponds to the lowest priority. = DRMP has a similar approach but with a larger range and also lower priorit= ies. - RFC 6710 (priority for SMTP), uses another encoding of the prior= ity values with an integer between -9 and +9. Lower priorities are negativ= e an higher priority being positive. When a value increases, it means a hig= her priority, so the opposite to DRMP, wps or ets. But the value 0 is her= e naturally the default value. So this is an encoding alternative to the = Enumerated type of the DRMP AVP which avoids the question of the default va= lue. Note: RFC 6710 also defines some Priority Assignment Policies using a subs= et of the range. RFC 6710 has also this guideline : SMTP servers compliant with this specification are not required to support all 19 distinct priority levels (i.e., to treat each priority value as a separate priority), .... That is, an implementation that only supports N priority levels (where N < 19) will internally round up a syntactically valid priority value that isn't supported to the next higher supported number (or to the highest supported priority, if the value is higher than any supported pr= iority). - This raises the question to have this type of guideline if consid= ered useful. So to have your feedback Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C Envoy=E9 : jeudi 15 octobre 2015 12:33 =C0 : Lee, Jay; ken carlberg; Steve Donovan Cc : dime@ietf.org Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp)= : Range of priority levels) A couple thoughts: 1. There needs to be a default value defined by the standard, so that = equipment have the same value leaving the factory 2. This value can be over written based on local policy 3. Should have an extensibility bit in order to and more values in the= future From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay Sent: Thursday, October 15, 2015 6:16 AM To: ken carlberg >; Steve D= onovan > Cc: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) >From my side, some more discussion on Steve's mail may be needed. 'Should' vs. 'Must': One can say that 'Should' is not mandatory. But, in practice, this is a fai= rly strong statement, and often taken as required. So in this sense, the pr= oposed Note is certainly helpful. But, since we allow operators to override= the value, I don't see the reason why we use 'Should'. My suggestion is us= ing 'May'. PRIORITY_14 priority: Since operators can overwrite it, I was not too concerned about it. But if = we want to put some value, why '14'? A value lower than 14 is suggested in = order to allow more rooms for lower priorities. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg Sent: Wednesday, October 14, 2015 8:40 AM To: Steve Donovan Cc: dime@ietf.org Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): R= ange of priority levels) with respect to the diff-serv example brought up below, some thing to add t= o that discussion is that it starts off with separate and distinct forwardi= ng behavior whose marked packets provide segmentation of other IP traffic. = The availability of only 6 bits to play with (along with the headaches of = transitive trust) also discouraged a line of thought to define end-to-end p= riority handling versus a per diff-serv domain treatment. RFC-4594 did pro= vide configuration guidelines, but that's a different story. So back to a couple of ideas to consider. 1) reserved space. if we go back to the diff-serv model, the diff-serv wor= king group agreed to set aside a set of values that was reserved for experi= mental use that could be re-assigned some time in the future. I'm not sugg= esting that there should be space set side for experiments, but rather it m= ay be prudent to set aside a reserved set of bits/values so that one doesn'= t need to define a new AVP if in the future there was a need to define adde= d values beyond the 5 (plus some fudge factor) already mentioned on the lis= t. 2) sets of users. previous work (e.g., rfc-4412, rfc-6710) recognized that= there can be several sets of users/services that are distinct from each ot= her and yet need to prioritize the traffic. I bring this up because the dr= aft already identifies two sets of users in sections 5.1 and 5.2 (note: I'm= assuming that the latter is aimed at the general public and related to 911= /112/999 type calls, which should probably be more specific in the draft). = And there is also the potential of Firstnet users in the US. As a side note, the distinction and separation of general public and other = prioritized users in public phone infrastructures is not exclusive to the U= S, so the group should not be concerned that this is a US centric effort. = There has been GTPS in the UK, as well as other systems in other countries.= The RFC is a bit dated, but feel free to go over rfc-4190 for added backg= round. and just to reiterate. I'm not making recommendations in the above - just = bringing up some food for thought. -ken On Oct 14, 2015, at 10:12 AM, Steve Donovan > wrote: Jay, The current text is a SHOULD level requirement: When there is a mix of transactions specifying priority in request messages and transactions that do not have the priority specified, transactions that do not have a specified priority SHOULD be treated as having the PRIORITY_14 priority. As such, operators can choose to either not implement a priority or define = a different value for their network. I propose adding the following note after this paragraph to further explain= why it is a SHOULD and not a MUST: Note: There are scenarios where operators might want to specify a different default value for transactions that do not have an explicit priority. In this case, the operator defined local policy would override the use of PRIORITY_14 as the default priority. This leaves the ability for there to be deterministic behavior in Diameter = networks that require a default to be defined and are happy with the specif= ied default. It also gives operators the ability to define a different beh= avior, most likely with some priority handling/mapping at the edge of the n= etwork. Does this address your concerns? Regards, Steve On 10/14/15 2:59 AM, Lee, Jay wrote: Regarding the issue of whether we need to specify a default value or not, t= here are pros and cons. If we specify a value for the default case, we can see the benefits in scen= arios between different operator networks, but we take away important optio= ns on what operators can do with priority values. On the other hand, if we = do not specify the default value, operators may have more options, but ther= e is a question of what to do for this inter-PLMN cases when the networks m= ay use different default values. In practice, this issue can be addressed at the edge of the network, where = Diameter edge agent (DEA) can perform some priority mapping based on bilate= ral roaming agreement (or SLA (service level agreement)) and other means to= insure the proper handling. One may argue that this is not as good as the = 'deterministic' case, but operator should be able handle this in a reasonab= le way. We are fully aware of the fact that, in case of this 'non-determini= stic' case, the default value can differ from one operator network to anoth= er, and it becomes difficult to guarantee the intended priority handling. D= espite this, we still prefer giving options to operators by not specifying = the default value. What we are saying here, however, is not anything new. This is the typical = way of handling priority levels. If anything, specifying the default value = would be something new. As already mentioned in CT discussion, there is a g= ood example of this - Internet QoS, more specifically DiffServ. In order to guarantee end-to-end QoS for a specific service, IETF could hav= e specified a value (DiffServ codepoint) for the specific service to have p= redetermined handling of the traffic, but IETF did not. Instead, DiffServ s= imply provided a framework for operators to have its own classification an= d differentiated treatment of the services. To guarantee end-to-end QoS acr= oss different networks, then, operators need to do packet inspection, (re)c= lassification, QoS mapping, use of SLA and possibly others at the edge of n= etwork (edge router). Therefore, in the DiffServ architecture, intelligence= was pushed to the edge of the network. While the end results may not be gu= aranteed as well as in the case of predetermined handling, it was still a p= referred way to give flexibility to operators. My point is that we went thr= ough all these troubles to give options of priority handling to operators. By the way, if we are thinking of possibility of specifying the default val= ue, are we assuming that all operators are interested in this feature (defa= ult value in the middle, and high and low priorities at other ends)? Aren't= there other operators who are not interested in this feature? I know that = at least there is one - Verizon. We have no interest in this feature, and n= o plan for implementing it. We are OK, if other operators are interested in= this feature, and the default value is NOT specified. But we are certainly= not happy if DIME is trying to impose this on us. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, October 13, 2015 10:55 AM To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org; Pollini, Gregory P Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Assuming that we define a range of 3 values, Assuming that 0 is the lowest priority and 2 the highest, Assuming that an agent receives 4 messages at the same time while being in = overload control: * 1) ULR with Prio-0 * 2) ULR with Prio-1 * 3) ULR with Prio-2 * 4) ULR with no priority AVP Assuming that the default is locally defined as proposed below, How do you know that the ULR with priority 2 will be handled with a higher = priority than the request without priority indication? And what about ULR message with priority 1 with two levels of highest prior= ity e.g. emergency/Important and government/very important? Sorry if the answer is obvious but I fail to understand. Lionel De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] Envoy=E9 : samedi 3 octobre 2015 01:21 =C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C Cc : DiME; dime@ietf.org; Pollini, Gregory P Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels Hello all, Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.21= 2 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defi= ned. Having 15 rather than 16 would be useful from an interworking point of view= on Diameter interfaces connecting to the EPS. Also, my understanding has been that the default value is per local policy. My 2 cents.... Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf = of lionel.morand@orange.com [lionel.morand= @orange.com] Sent: Thursday, October 01, 2015 3:36 AM To: Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Hi, I think that the case "no Priority indication in request" is the default si= tuation today. So if we agree that it should be possible to explicitly indicate a request = with a lower priority, we should divide the range of priority values in thr= ee sub-ranges: [lower priorities][no priority indication][higher priorities= ], e.g. with 17 values: [0-7][8][9-16]. If any operator can freely fix the default value, there would be no way to = ensure the sender that a request with a specific priority value (e.g. 6) wi= ll be handled with a lower or higher priority than a request with no priori= ty indication. Therefore, for a deterministic handling mechanism, I think that it is then = more relevant to define a standard value for the default value. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn Envoy=E9 : mercredi 30 septembre 2015 22:53 =C0 : DOLLY, MARTIN C Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels Same here. The "default priority" should be a matter of local policy. Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "DOLLY, MARTIN C" > To: Steve Donovan >, "dime@ietf.org" > Date: 09/30/2015 04:40 PM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" = > ________________________________ Me as well From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, September 30, 2015 4:38 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels I'm okay with Jay's proposal on not specifying a default value. Steve On 9/30/15 3:27 PM, Lee, Jay wrote: Hi Steve and all, For the first proposal, as I indicated, I support increasing the number of = priority levels up to 16. I am also fine with the second proposal. My question is: do we need to mand= ate this feature, as individual operators have different situations? Perhap= s some flexibility should be allowed? Instead of mandating it, we can inclu= de the statement that when there is no DRMP AVP, this correspond to 'normal= traffic' without a particular high or low priority. Then each operator can= map this default to a value (e.g., 8 or something else) that they feel app= ropriate. Thanks, Jay _______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_E194C2E18676714DACA9C3A2516265D29D46413EFR712WXCHMBA12z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 <= /p>

Please see my comments al= so in line. I think we are close to finalise our choice on the different po= ints  of this thread

 <= /p>

Best regards

 <= /p>

JJacques

 <= /p>

De := DiME [mail= to:dime-bounces@ietf.org] De la part de Lee, Jay
Envoy=E9 : vendredi 23 octobre 2015 18:57
=C0 : dime@ietf.org
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime= ] #92 (drmp): Range of priority levels)

 

Please see my comments in= line.

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Friday, October 23, 2015 8:02 AM
To: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Please see my comment= s inline.

Steve

On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote:

See inline

 <= /p>

From: DiME [= mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay
Sent: Friday, October 23, 2015 1:59 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) <jean-jacques.trottin@alcatel-lucent.com>; dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Some further comments fro= m my side:

 <= /p>

*/ If we need to assign (= but not specify) a value to the default case, we need to make it clear that= this value can be overwritten by operators, and the value is for some use cases like e.g., equipment having the same value when leav= ing the factory, so that there would be no misunderstanding.

mcd- ok=

SRD> I think the current proposed text makes this= clear.
[JL] Agree that the current text is OK especi= ally when we use ‘May’ in place of ‘Should’<= span style=3D"color:#1F497D">

[JJ] OK

.

 <= /p>

*/ Since we agree that the default value is per local policy, ‘Ma= y’ is preferred to ‘Should’ in order not to cause confusi= on.

mcd-ok

SRD> I'm okay with making this a MAY.

[JL]  Agreed

[JJ] Also in favor of a M= AY

 

*/ For assignment of the default value, I am quite open. But any value = between 9 – 12 seems reasonable to me.

mcd- value should allow f= or assigning lower values, though a carrier can assign what they want in th= eir network, there needs to be a common meaning at the interconnection point

SRD> I'm open to any value we decide on.  If= there are real use cases that require pushing the default value more to th= e middle then we should do so.  At this point I've heard one use case = for the default being something other then the lowest value, thus the proposal to use priority_14 as the default.  <= o:p>

[JJ] Regarding use cases,= there may be

- = ;         The case where fo= r “normal” users, an application use the default value for most= of its requests except some which have a lower priority<= /p>

- = ;         the case where be= sides “normal” user (and high priority users), some users have = lower priorities, e.g. Some Machine type Communications (MTC) devices.

So potentially more than = one low priority level would be needed.

We also have chosen a rat= her large range of values (16) , allowing flexibility for an operator when = they define the number of priorities they want , leaving possibility to future additions. If PRIORITY _14 is the default, it leaves= only one lower priority and an operator  cannot add a second one &nbs= p;except by choosing  a default value other than the 14  value.

Then as, in practice, we = may expect a range of low priority smaller than  the range of high pri= ority values, this is why the default value was proposed to be in the range 9-12  . Then I proposed 10 so to do a proposal but I am = open on another value.

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      

*/  Current proposal of 16 values may be enough now, but I am fine= with having an extensibility bit to be future proof.

mcd-ok

SRD> I don't see a compelling argument to move be= yond 16. 
In addition, it isn't clear to me that there is value in defining an extens= ibility mechanism beyond what is already supported by Diameter.  Doing= so would add significant complexity to the DRMP mechanism for something th= at, in my view, has a low probability of being used.

I propose that we not allow extending the DRMP AVP.  Rather we require= that any extension require a new AVP.  We can then leave it to the do= cument that proposes the extension to deal with determining whether send th= e DRMP AVP or the newly defined DRMPv2 AVP. 
[JL] When we proposed that the range be exten= ded to 16, we thought that ‘16’ was large enough and future pro= of.

I am okay with having = an extensibility bit, if other companies want it. That said, I agree that i= t has a low probability of being used and added complexity.

[JJ] JJ I also agree t= hat with 16 values , the offered range is large enough in practice. This po= int is only to check if it would be easy to do an extension, if we have thi= s requirement in the future.  I agree with Steve that for an extensibility, it will require a new AVP in a new d= ocument rather than to define a set of reserved values in the DRMP AVP. &nb= sp;A point is that it will require an additional parsing effort for a node = to look for this second AVP even if it is not present most of the time.  

 

*/ I am not sure of alternative encoding method (say, +9 to -9 per = JJacques’ proposal) compared to the current enumerated type of DRMP. It offers a logical way of assigning a value 0 to the default case. = But it offers less flexibility to operators, since the default value may no= t be easily moved to have more higher/lower priority values. Also, we are u= sed to the enumerated type of DRMP and just want to have extension from 5 to 16,  but this may require m= ore deviation from the current design and thinking. For this, I would like = to see more on qualitative pros/cons, but, given its little benefit, I am r= eluctant to accept this alternative.

SRD> I agree that I don't see value in the +9= to -9 proposal.

[JL] Agreed

[J] I presented this seco= nd  approach  so to review the possible alternatives as we usuall= y do before selecting the solution, this alternative being already used in a recent RFC.   That being said, I am fine with the enum= erated DRMP AVP.

 <= /p>

Best regards

 <= /p>

JJacques  

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Thursday, October 22, 2015 9:39 AM
To: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Hi

 <= /p>

1.      PRIORITY_14 as default priority value onl= y allows one level of lower priority (PRIORITY_15)  than the default o= ne; this seems not enough.  As use cases, we may have  some Machine type Communication (LTC) devices that may have lower priorities th= at normal communications without priority.  Even within a Diameter app= lication, some commands may have a lower priority as having a secundary imp= ortance.

 

Then which default  value ?

- &nb= sp;      it could be PRIORITY_8 in the middle, or = if we prefer to have a  larger range for higher priorities  than = for lower priorities,  the default value could be  e.g. PRIORITY_= 10,  giving 9 higher priorities and 5 lower priorities than the default one. I = would have a preference for this value PRIORITY_10.

 <= /p>

2.      About extensibility, the current range of= 16 values is already large, but we can have  a reserved value to indi= cate a further extension. With  an enumerated AVP, there is no possibility to add new values. 

 <= /p>

3.      I also had a look to some other IETF RFCs= addressing priorities that Ken mentioned, so to see if we can benefit from= these approaches although done for different contexts.

- &nb= sp;      in RFC 4412 (Resource-Priority Header in = SIP), wps and ets namespaces have a range of 5 values (0 to 4) with 0 as th= e highest priority  . But I have not found some indication  (I may have missed it) about the default priority  (I mean a SIP requ= est without  Resource-Priority Header compared  to a SIP request = with the Header). Implicitly, I would assume a SIP request without  Re= source-Priority Header corresponds to  the lowest priority.  DRMP has a similar approach but with  a larger range and also l= ower priorities.

 <= /p>

- &nb= sp;      RFC  6710 (priority for SMTP),  = ;uses another encoding of the priority values with an integer between -9 an= d +9. Lower priorities  are negative an higher priority being posi= tive. When a value increases, it means a higher priority, so the opposite  = to DRMP, wps or ets.  But the value 0 is here naturally the default va= lue. So this is an encoding alternative  to the  Enumerated type = of the DRMP AVP which avoids the question of the default value.

Note: RFC  67= 10 also defines some Priority Assignment Policies using a subset of the ran= ge.

 <= /p>

RFC 6710 has also this guideline :

   SMTP server= s compliant with this specification are not

   required to supp= ort all 19 distinct priority levels (i.e., to treat

   each priority va= lue as a separate priority), ….  That is, an

   implementation t= hat only supports N priority levels (where N < 19)

   will internally = round up a syntactically valid priority value that

   isn't supported = to the next higher supported number (or to the

   highest supporte= d priority, if the value is higher than any supported priority).

- &nb= sp;      This raises the question to have this typ= e of  guideline if considered useful.

 

So to have your feedback

 <= /p>

Best regards<= /o:p>

 <= /p>

JJacques

 <= /p>

De : DiME= [<= span lang=3D"EN-US">mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C
Envoy=E9 : jeudi 15 octobre 2015 12:33
=C0 : Lee, Jay; ken carlberg; Steve Donovan
Cc : dime@ietf.org
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime= ] #92 (drmp): Range of priority levels)

 

A couple thoughts:=

1. &n= bsp;    There needs to be a default value defined= by the standard, so that equipment have the same value leaving the factory=

2. &n= bsp;    This value can be over written based on l= ocal policy

3. &n= bsp;    Should have an extensibility bit in order= to and more values in the future

 <= /p>

 <= /p>

From: DiME [= mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay
Sent: Thursday, October 15, 2015 6:16 AM
To: ken carlberg <carlberg= @g11.org.uk>; Steve Donovan <srdonovan@usdonovans.com>
Cc: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

From my side, some more d= iscussion on Steve’s mail may be needed.

 <= /p>

‘Should’ vs. = ‘Must’:

One can say that ‘S= hould’ is not mandatory. But, in practice, this is a fairly strong st= atement, and often taken as required. So in this sense, the proposed Note is certainly helpful. But, since we allow operators to override the v= alue, I don’t see the reason why we use ‘Should’. My sugg= estion is using ‘May’.

 <= /p>

PRIORITY_14 priority:

Since operators can overw= rite it, I was not too concerned about it. But if we want to put some value= , why ‘14’? A value lower than 14 is suggested in order to allow more rooms for lower priorities.

 <= /p>

Jay

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg
Sent: Wednesday, October 14, 2015 8:40 AM
To: Steve Donovan
Cc: dime@ietf.org
Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (d= rmp): Range of priority levels)

 

with respect to the diff-serv example brought up bel= ow, some thing to add to that discussion is that it starts off with separat= e and distinct forwarding behavior whose marked packets provide segmentatio= n of other IP traffic.  The availability of only 6 bits to play with (along with the headaches of transitive trust)= also discouraged a line of thought to define end-to-end priority handling = versus a per diff-serv domain treatment.  RFC-4594 did provide configu= ration guidelines, but that’s a different story.

 

So back to a couple of ideas to consider.=

 

1) reserved space.  if we go back to the diff-s= erv model, the diff-serv working group agreed to set aside a set of values = that was reserved for experimental use that could be re-assigned some time = in the future.  I’m not suggesting that there should be space set side for experiments, but rather it may be prude= nt to set aside a reserved set of bits/values so that one doesn't need to d= efine a new AVP if in the future there was a need to define added values be= yond the 5 (plus some fudge factor) already mentioned on the list. 

 

2) sets of users.  previous work (e.g., rfc-441= 2, rfc-6710) recognized that there can be several sets of users/services th= at are distinct from each other and yet need to prioritize the traffic. &nb= sp;I bring this up because the draft already identifies two sets of users in sections 5.1 and 5.2 (note: I’m assu= ming that the latter is aimed at the general public and related to 911/112/= 999 type calls, which should probably be more specific in the draft).  = ;And there is also the potential of Firstnet users in the US.

 

As a side note, the distinction and separation of ge= neral public and other prioritized users in public phone infrastructures is= not exclusive to the US, so the group should not be concerned that this is= a US centric effort.  There has been GTPS in the UK, as well as other systems in other countries.  The RFC= is a bit dated, but feel free to go over rfc-4190 for added background.

 

and just to reiterate.  I’m not making re= commendations in the above — just bringing up some food for thought.<= o:p>

 

-ken

 

 

On Oct 14, 2015, at 10:12 AM, Steve Donovan <srdonovan@usdonovans.com> wr= ote:

 

Jay,

The current text is a SHOULD level require= ment:

   When there is a mix of transa= ctions specifying priority in request
   messages and transactions tha= t do not have the priority specified,
   transactions that do not have= a specified priority SHOULD be treated
   as having the PRIORITY_14 pri= ority.

As such, operators can choose to either no= t implement a priority or define a different value for their network.

I propose adding the following note after = this paragraph to further explain why it is a SHOULD and not a MUST:=

      Note: There= are scenarios where operators might want to 
      specify a d= ifferent default value for transactions that do not
      have an exp= licit priority.  In this case, the operator defined
      local polic= y would override the use of PRIORITY_14 as
      the default= priority.

This leaves the ability for there to be de= terministic behavior in Diameter networks that require a default to be defi= ned and are happy with the specified default.  It also gives operators= the ability to define a different behavior, most likely with some priority handling/mapping at the edge of the network= .

Does this address your concerns?
Regards,

Steve

On 10/14/15= 2:59 AM, Lee, Jay wrote:

From: DiME [mai= lto:dime-bounces@ietf.org]=  On Behalf Of lionel.morand@orange.com
Sent: Tuesday, Oct= ober 13, 2015 10:55 AM
To: Shaikh, Viqar = A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; <= a href=3D"mailto:dime@ietf.org">dime@ietf.org; Pollini, Gregory P
Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 

=B7     &nb= sp; 1) ULR with Prio-0

=B7     &nb= sp; 2) ULR with Prio-1

=B7     &nb= sp; 3) ULR with Prio-2

=B7     &nb= sp; 4) ULR with no priority AVP

De :<= /span> Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] 
Envoy=E9 : sa= medi 3 octobre 2015 01:21
=C0 : MORAND = Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; dime= @ietf.org; Pollini, Gregory P
Objet : RE: [= Dime] [dime] #92 (drmp): Range of priority levels

 

Hello all,

 =

Note tha= t the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 t= akes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined.

 =

Having 15 rat= her than 16 would be useful from an interworking point of view on Diameter = interfaces connecting to the EPS.  

 =

Also, my unde= rstanding has been that the default value is per local policy. 

 =

My 2 cents....

Viqar 

<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">From: DiME [<= span lang=3D"EN-US" style=3D"color:purple">dime-bounces@ietf.org= ] on behalf of lionel.morand@orange.com [lionel.morand@orange.com<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">]
Sent: Thursday, Oc= tober 01, 2015 3:36 AM
To: Janet P Gunn; = DOLLY, MARTIN C
Cc: DiME; dime@ietf.= org
Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 

 

 

Regards,

 <= o:p>

Lionel

 <= o:p>

 <= o:p>

De : DiME [mai= lto:dime-bounces@ietf.org]=  De la part de&nbs= p;Janet P Gunn
Envoy=E9 : me= rcredi 30 septembre 2015 22:53
=C0 : DOLLY, = MARTIN C
Cc : DiME; dime@ietf.org<= span lang=3D"FR" style=3D"font-size:10.0pt;font-family:"Tahoma",&= quot;sans-serif"">
Objet : Re: [= Dime] [dime] #92 (drmp): Range of priority levels<= o:p>

 <= o:p>

Same here. &nb= sp;The "default priority" should be a matter of local policy. 

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose. 



From:        &= quot;DOLLY, MARTIN C" <md3135@att.com<= /a>> =
To:        S= teve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org>&nbs= p;
Date:        0= 9/30/2015 04:40 PM 
Subject:        Re: [Dime] [dime] #92 (drmp): Range of priority levels 
Sent by:        "DiME" <dime-bounces@ietf.org>




Me as well 
  
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Dono= van
Sent: Wednesday, Sept= ember 30, 2015 4:38 PM
To: dime@ietf.org
Subject: = ;Re: [Dime] [dime] #92 (drmp): Range of priority= levels 
  
I'm okay with Jay's proposal on not specifying a default value= .

Steve 
On 9/30/15 3:27 PM, Lee, Jay wrote: 
Hi Steve and all,=  
  
For the first proposal, as I indicated, I support increasing t= he number of priority levels up to 16. 
  
I am also fine with the second proposal. My question is: do we= need to mandate this feature, as individual operators have different situa= tions? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that when there is no DRMP A= VP, this correspond to ‘normal traffic’ without a particular hi= gh or low priority. Then each operator can map this default to a value (e.g= ., 8 or something else) that they feel appropriate. 
  
Thanks, 
  
Jay <= br>


__________________________________________= _____ 
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= 

_____________________________________=
___________________________________________________________________________=
_________
 <=
/o:p>
Ce message et ses pieces jointes peuv=
ent contenir des informations confidentielles ou privilegiees et ne doivent=
 donc
pas etre diffuses, exploites ou copie=
s sans autorisation. Si vous avez recu ce message par erreur, veuillez le s=
ignaler
a l'expediteur et le detruire ainsi q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration,
Orange decline toute responsabilite s=
i ce message a ete altere, deforme ou falsifie. Merci.

 


This message and its attachments may contain conf=
idential or privileged information that may be protected by law;


they should not be distributed, used or copied wi=
thout authorisation.


If you have received this email in error, please =
notify the sender and delete this message and its attachments.<=
/o:p>


As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=



Thank you.


_____________________________________=
___________________________________________________________________________=
_________
 <=
/o:p>
Ce message et ses pieces jointes peuv=
ent contenir des informations confidentielles ou privilegiees et ne doivent=
 donc
pas etre diffuses, exploites ou copie=
s sans autorisation. Si vous avez recu ce message par erreur, veuillez le s=
ignaler
a l'expediteur et le detruire ainsi q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration,
Orange decline toute responsabilite s=
i ce message a ete altere, deforme ou falsifie. Merci.

 


This message and its attachments may contain conf=
idential or privileged information that may be protected by law;


they should not be distributed, used or copied wi=
thout authorisation.


If you have received this email in error, please =
notify the sender and delete this message and its attachments.<=
/o:p>


As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=



Thank you.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.ietf.org/mailman/listinfo/di=
me





__________________________________________=
_____

DiME mailing list

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime=

 



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

 

--_000_E194C2E18676714DACA9C3A2516265D29D46413EFR712WXCHMBA12z_-- From nobody Tue Oct 27 16:16:41 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783431B2DEC; Tue, 27 Oct 2015 16:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5q_5Qaqs_OP; Tue, 27 Oct 2015 16:16:34 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAFB1B2DEB; Tue, 27 Oct 2015 16:16:31 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A9457187E50; Tue, 27 Oct 2015 16:15:54 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20151027231554.A9457187E50@rfc-editor.org> Date: Tue, 27 Oct 2015 16:15:54 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] RFC 7683 on Diameter Overload Indication Conveyance X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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 Oct 2015 23:16:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7683 Title: Diameter Overload Indication Conveyance Author: J. Korhonen, Ed., S. Donovan, Ed., B. Campbell, L. Morand Status: Standards Track Stream: IETF Date: October 2015 Mailbox: jouni.nospam@gmail.com, srdonovan@usdonovans.com, ben@nostrum.com, lionel.morand@orange.com Pages: 42 Characters: 96330 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dime-ovli-10.txt URL: https://www.rfc-editor.org/info/rfc7683 DOI: http://dx.doi.org/10.17487/RFC7683 This specification defines a base solution for Diameter overload control, referred to as Diameter Overload Indication Conveyance (DOIC). This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Oct 28 06:44:34 2015 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 214541B553A for ; Wed, 28 Oct 2015 06:44:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151028134433.13575.603.idtracker@ietfa.amsl.com> Date: Wed, 28 Oct 2015 06:44:33 -0700 From: IETF Secretariat Archived-At: Subject: [Dime] Milestones changed for dime WG X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 13:44:33 -0000 Changed milestone "Submit 'problem statement and requirements for Diameter end-to-end security framework' as Dime working group item", resolved as "Done", added draft-ietf-dime-e2e-sec-req to milestone. Changed milestone "Submit I-D 'Diameter Overload Control' to the IESG for consideration as a Proposed Standard", resolved as "Done", added draft-ietf-dime-ovli to milestone. Changed milestone "Submit I-D 'Diameter Congestion and Filter Attributes' to the IESG for considerations as a Proposed Standard", resolved as "Done". Changed milestone "Submit a document on 'Diameter Agent Overload' as a working group item", resolved as "Done", added draft-ietf-dime-agent-overload to milestone. Changed milestone "Submit a document on 'Diameter Overload Control Rate Abatement Algorithm' as a working group item", resolved as "Done", added draft-ietf-dime-doic-rate-control to milestone. Changed milestone "Submit a document on 'Diameter Load Information' as a working group item", resolved as "Done", added draft-ietf-dime-load to milestone. URL: https://datatracker.ietf.org/wg/dime/charter/ From nobody Wed Oct 28 11:35:15 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71491A8A7E for ; Wed, 28 Oct 2015 11:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEGTp7-vWwsB for ; Wed, 28 Oct 2015 11:34:56 -0700 (PDT) Received: from eris.verizonwireless.com (eris.verizonwireless.com [137.188.99.119]) by ietfa.amsl.com (Postfix) with ESMTP id 88E9E1A899A for ; Wed, 28 Oct 2015 11:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizonwireless.com; i=@verizonwireless.com; q=dns/txt; s=prodmail; t=1446057295; x=1477593295; h=from:to:subject:date:references:in-reply-to:mime-version; bh=mAsNsrcqkw39fRC1iModMzn42kTXFYtUa297RU+S+TI=; b=dzihNplMDXoR9p4AuijudXegBcR0ynP9JjHqT9ABTiAFlwiYZHGF78Qk K/4VhWjPFVJYO6tYEQd3ZUQRtMbF5aepbXKyQuQ5+ilpazMGH5Meo1qGJ f7B+lN7wJbarvjkc3KwZBsoUeYAAhbz3smSAlHuRAfEtL+PT+8T13QceS c=; X-Host: surveyor.tdc.vzwcorp.com Received: from casac1exh001.uswin.ad.vzwcorp.com ([10.11.218.43]) by eris.verizonwireless.com with ESMTP/TLS/AES128-SHA; 28 Oct 2015 14:34:52 -0400 Received: from CASAC1EXP009.uswin.ad.vzwcorp.com ([fe80::558c:d7cc:1a42:f4d6]) by CASAC1EXH001.uswin.ad.vzwcorp.com ([::1]) with mapi id 14.03.0146.000; Wed, 28 Oct 2015 11:34:18 -0700 From: "Lee, Jay" To: "dime@ietf.org" Thread-Topic: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) Thread-Index: AQHRBzKIwn0SbO3rXUW/ebDof+lRcp5sOcGAgAtoZjCAAZc3ZYAAEqiAgASJrNCAA3T5QA== Date: Wed, 28 Oct 2015 18:34:18 +0000 References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> <20151014075941.062E21B2C1F@ietfa.amsl.com> <561E62C9.20500@usdonovans.com> <1431d0b2-5ae7-426e-b5ff-42b23fecbee5@CASAC1EXH002.uswin.ad.vzwcorp.com> <20151015101558.111761ACD5C@ietfa.amsl.com> <3e7a25c8-5eea-49a5-9905-3009c4dc45b8@NYORA1HUB001.uswin.ad.vzwcorp.com> <20151023055927.9223C1B3292@ietfa.amsl.com> <20151023165728.7D0E01A874F@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.11.60.250] Content-Type: multipart/alternative; boundary="_000_C026C31E3CD6CA43953D6D95AB480480047A6ECASAC1EXP009uswin_" MIME-Version: 1.0 Message-Id: <20151028183455.88E9E1A899A@ietfa.amsl.com> Archived-At: Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2015 18:35:12 -0000 --_000_C026C31E3CD6CA43953D6D95AB480480047A6ECASAC1EXP009uswin_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I also think that we agree on all different points for the finalization, ex= cept one point: the value for the default case. Use of the default case as = discussed here is rather in the future than in the present for us, so I do = not have strong opinion, especially when the default value can be overwritt= en. Looking at this objectively and also for the sake of progress, however, it = would be prudent to have more than one lower priority cases. In the near fu= ture, we may identify additional use cases for lower priority case. Even wi= th one use case identified, this does not necessarily mean one priority lev= el per use case. One use case may require multiple lower priority levels, d= epending on applications. Any value from 9 to 12 seems reasonable to me. But, without all use cases i= dentified at the present time, I propose 10 (JJacques' proposal) or 11. Thanks, Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: Monday, October 26, 2015 8:11 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Hi Please see my comments also in line. I think we are close to finalise our c= hoice on the different points of this thread Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de Lee, Jay Envoy=E9 : vendredi 23 octobre 2015 18:57 =C0 : dime@ietf.org Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp)= : Range of priority levels) Please see my comments inline. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Friday, October 23, 2015 8:02 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Please see my comments inline. Steve On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote: See inline From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay Sent: Friday, October 23, 2015 1:59 AM To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) ; dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Some further comments from my side: */ If we need to assign (but not specify) a value to the default case, we n= eed to make it clear that this value can be overwritten by operators, and t= he value is for some use cases like e.g., equipment having the same value w= hen leaving the factory, so that there would be no misunderstanding. mcd- ok SRD> I think the current proposed text makes this clear. [JL] Agree that the current text is OK especially when we use 'May' in plac= e of 'Should' [JJ] OK . */ Since we agree that the default value is per local policy, 'May' is pref= erred to 'Should' in order not to cause confusion. mcd-ok SRD> I'm okay with making this a MAY. [JL] Agreed [JJ] Also in favor of a MAY */ For assignment of the default value, I am quite open. But any value betw= een 9 - 12 seems reasonable to me. mcd- value should allow for assigning lower values, though a carrier can as= sign what they want in their network, there needs to be a common meaning at= the interconnection point SRD> I'm open to any value we decide on. If there are real use cases that = require pushing the default value more to the middle then we should do so. = At this point I've heard one use case for the default being something othe= r then the lowest value, thus the proposal to use priority_14 as the defaul= t. [JJ] Regarding use cases, there may be - The case where for "normal" users, an application use the defaul= t value for most of its requests except some which have a lower priority - the case where besides "normal" user (and high priority users), = some users have lower priorities, e.g. Some Machine type Communications (MT= C) devices. So potentially more than one low priority level would be needed. We also have chosen a rather large range of values (16) , allowing flexibil= ity for an operator when they define the number of priorities they want , l= eaving possibility to future additions. If PRIORITY _14 is the default, it = leaves only one lower priority and an operator cannot add a second one ex= cept by choosing a default value other than the 14 value. Then as, in practice, we may expect a range of low priority smaller than t= he range of high priority values, this is why the default value was propose= d to be in the range 9-12 . Then I proposed 10 so to do a proposal but I a= m open on another value. */ Current proposal of 16 values may be enough now, but I am fine with hav= ing an extensibility bit to be future proof. mcd-ok SRD> I don't see a compelling argument to move beyond 16. In addition, it isn't clear to me that there is value in defining an extens= ibility mechanism beyond what is already supported by Diameter. Doing so w= ould add significant complexity to the DRMP mechanism for something that, i= n my view, has a low probability of being used. I propose that we not allow extending the DRMP AVP. Rather we require that= any extension require a new AVP. We can then leave it to the document tha= t proposes the extension to deal with determining whether send the DRMP AVP= or the newly defined DRMPv2 AVP. [JL] When we proposed that the range be extended to 16, we thought that '16= ' was large enough and future proof. I am okay with having an extensibility bit, if other companies want it. Tha= t said, I agree that it has a low probability of being used and added compl= exity. [JJ] JJ I also agree that with 16 values , the offered range is large enoug= h in practice. This point is only to check if it would be easy to do an ext= ension, if we have this requirement in the future. I agree with Steve that= for an extensibility, it will require a new AVP in a new document rather t= han to define a set of reserved values in the DRMP AVP. A point is that it= will require an additional parsing effort for a node to look for this seco= nd AVP even if it is not present most of the time. */ I am not sure of alternative encoding method (say, +9 to -9 per JJacques= ' proposal) compared to the current enumerated type of DRMP. It offers a lo= gical way of assigning a value 0 to the default case. But it offers less fl= exibility to operators, since the default value may not be easily moved to = have more higher/lower priority values. Also, we are used to the enumerated= type of DRMP and just want to have extension from 5 to 16, but this may r= equire more deviation from the current design and thinking. For this, I wou= ld like to see more on qualitative pros/cons, but, given its little benefit= , I am reluctant to accept this alternative. SRD> I agree that I don't see value in the +9 to -9 proposal. [JL] Agreed [J] I presented this second approach so to review the possible alternativ= es as we usually do before selecting the solution, this alternative being a= lready used in a recent RFC. That being said, I am fine with the enumerat= ed DRMP AVP. Best regards JJacques From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: Thursday, October 22, 2015 9:39 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Hi 1. PRIORITY_14 as default priority value only allows one level of lowe= r priority (PRIORITY_15) than the default one; this seems not enough. As = use cases, we may have some Machine type Communication (LTC) devices that = may have lower priorities that normal communications without priority. Eve= n within a Diameter application, some commands may have a lower priority as= having a secundary importance. Then which default value ? - it could be PRIORITY_8 in the middle, or if we prefer to have a l= arger range for higher priorities than for lower priorities, the default = value could be e.g. PRIORITY_10, giving 9 higher priorities and 5 lower p= riorities than the default one. I would have a preference for this value PR= IORITY_10. 2. About extensibility, the current range of 16 values is already larg= e, but we can have a reserved value to indicate a further extension. With = an enumerated AVP, there is no possibility to add new values. 3. I also had a look to some other IETF RFCs addressing priorities tha= t Ken mentioned, so to see if we can benefit from these approaches although= done for different contexts. - in RFC 4412 (Resource-Priority Header in SIP), wps and ets namespa= ces have a range of 5 values (0 to 4) with 0 as the highest priority . But= I have not found some indication (I may have missed it) about the default= priority (I mean a SIP request without Resource-Priority Header compared= to a SIP request with the Header). Implicitly, I would assume a SIP reque= st without Resource-Priority Header corresponds to the lowest priority. = DRMP has a similar approach but with a larger range and also lower priorit= ies. - RFC 6710 (priority for SMTP), uses another encoding of the prior= ity values with an integer between -9 and +9. Lower priorities are negativ= e an higher priority being positive. When a value increases, it means a hig= her priority, so the opposite to DRMP, wps or ets. But the value 0 is her= e naturally the default value. So this is an encoding alternative to the = Enumerated type of the DRMP AVP which avoids the question of the default va= lue. Note: RFC 6710 also defines some Priority Assignment Policies using a subs= et of the range. RFC 6710 has also this guideline : SMTP servers compliant with this specification are not required to support all 19 distinct priority levels (i.e., to treat each priority value as a separate priority), .... That is, an implementation that only supports N priority levels (where N < 19) will internally round up a syntactically valid priority value that isn't supported to the next higher supported number (or to the highest supported priority, if the value is higher than any supported pr= iority). - This raises the question to have this type of guideline if consid= ered useful. So to have your feedback Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C Envoy=E9 : jeudi 15 octobre 2015 12:33 =C0 : Lee, Jay; ken carlberg; Steve Donovan Cc : dime@ietf.org Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp)= : Range of priority levels) A couple thoughts: 1. There needs to be a default value defined by the standard, so that = equipment have the same value leaving the factory 2. This value can be over written based on local policy 3. Should have an extensibility bit in order to and more values in the= future From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay Sent: Thursday, October 15, 2015 6:16 AM To: ken carlberg >; Steve D= onovan > Cc: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) >From my side, some more discussion on Steve's mail may be needed. 'Should' vs. 'Must': One can say that 'Should' is not mandatory. But, in practice, this is a fai= rly strong statement, and often taken as required. So in this sense, the pr= oposed Note is certainly helpful. But, since we allow operators to override= the value, I don't see the reason why we use 'Should'. My suggestion is us= ing 'May'. PRIORITY_14 priority: Since operators can overwrite it, I was not too concerned about it. But if = we want to put some value, why '14'? A value lower than 14 is suggested in = order to allow more rooms for lower priorities. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg Sent: Wednesday, October 14, 2015 8:40 AM To: Steve Donovan Cc: dime@ietf.org Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): R= ange of priority levels) with respect to the diff-serv example brought up below, some thing to add t= o that discussion is that it starts off with separate and distinct forwardi= ng behavior whose marked packets provide segmentation of other IP traffic. = The availability of only 6 bits to play with (along with the headaches of = transitive trust) also discouraged a line of thought to define end-to-end p= riority handling versus a per diff-serv domain treatment. RFC-4594 did pro= vide configuration guidelines, but that's a different story. So back to a couple of ideas to consider. 1) reserved space. if we go back to the diff-serv model, the diff-serv wor= king group agreed to set aside a set of values that was reserved for experi= mental use that could be re-assigned some time in the future. I'm not sugg= esting that there should be space set side for experiments, but rather it m= ay be prudent to set aside a reserved set of bits/values so that one doesn'= t need to define a new AVP if in the future there was a need to define adde= d values beyond the 5 (plus some fudge factor) already mentioned on the lis= t. 2) sets of users. previous work (e.g., rfc-4412, rfc-6710) recognized that= there can be several sets of users/services that are distinct from each ot= her and yet need to prioritize the traffic. I bring this up because the dr= aft already identifies two sets of users in sections 5.1 and 5.2 (note: I'm= assuming that the latter is aimed at the general public and related to 911= /112/999 type calls, which should probably be more specific in the draft). = And there is also the potential of Firstnet users in the US. As a side note, the distinction and separation of general public and other = prioritized users in public phone infrastructures is not exclusive to the U= S, so the group should not be concerned that this is a US centric effort. = There has been GTPS in the UK, as well as other systems in other countries.= The RFC is a bit dated, but feel free to go over rfc-4190 for added backg= round. and just to reiterate. I'm not making recommendations in the above - just = bringing up some food for thought. -ken On Oct 14, 2015, at 10:12 AM, Steve Donovan > wrote: Jay, The current text is a SHOULD level requirement: When there is a mix of transactions specifying priority in request messages and transactions that do not have the priority specified, transactions that do not have a specified priority SHOULD be treated as having the PRIORITY_14 priority. As such, operators can choose to either not implement a priority or define = a different value for their network. I propose adding the following note after this paragraph to further explain= why it is a SHOULD and not a MUST: Note: There are scenarios where operators might want to specify a different default value for transactions that do not have an explicit priority. In this case, the operator defined local policy would override the use of PRIORITY_14 as the default priority. This leaves the ability for there to be deterministic behavior in Diameter = networks that require a default to be defined and are happy with the specif= ied default. It also gives operators the ability to define a different beh= avior, most likely with some priority handling/mapping at the edge of the n= etwork. Does this address your concerns? Regards, Steve On 10/14/15 2:59 AM, Lee, Jay wrote: Regarding the issue of whether we need to specify a default value or not, t= here are pros and cons. If we specify a value for the default case, we can see the benefits in scen= arios between different operator networks, but we take away important optio= ns on what operators can do with priority values. On the other hand, if we = do not specify the default value, operators may have more options, but ther= e is a question of what to do for this inter-PLMN cases when the networks m= ay use different default values. In practice, this issue can be addressed at the edge of the network, where = Diameter edge agent (DEA) can perform some priority mapping based on bilate= ral roaming agreement (or SLA (service level agreement)) and other means to= insure the proper handling. One may argue that this is not as good as the = 'deterministic' case, but operator should be able handle this in a reasonab= le way. We are fully aware of the fact that, in case of this 'non-determini= stic' case, the default value can differ from one operator network to anoth= er, and it becomes difficult to guarantee the intended priority handling. D= espite this, we still prefer giving options to operators by not specifying = the default value. What we are saying here, however, is not anything new. This is the typical = way of handling priority levels. If anything, specifying the default value = would be something new. As already mentioned in CT discussion, there is a g= ood example of this - Internet QoS, more specifically DiffServ. In order to guarantee end-to-end QoS for a specific service, IETF could hav= e specified a value (DiffServ codepoint) for the specific service to have p= redetermined handling of the traffic, but IETF did not. Instead, DiffServ s= imply provided a framework for operators to have its own classification an= d differentiated treatment of the services. To guarantee end-to-end QoS acr= oss different networks, then, operators need to do packet inspection, (re)c= lassification, QoS mapping, use of SLA and possibly others at the edge of n= etwork (edge router). Therefore, in the DiffServ architecture, intelligence= was pushed to the edge of the network. While the end results may not be gu= aranteed as well as in the case of predetermined handling, it was still a p= referred way to give flexibility to operators. My point is that we went thr= ough all these troubles to give options of priority handling to operators. By the way, if we are thinking of possibility of specifying the default val= ue, are we assuming that all operators are interested in this feature (defa= ult value in the middle, and high and low priorities at other ends)? Aren't= there other operators who are not interested in this feature? I know that = at least there is one - Verizon. We have no interest in this feature, and n= o plan for implementing it. We are OK, if other operators are interested in= this feature, and the default value is NOT specified. But we are certainly= not happy if DIME is trying to impose this on us. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, October 13, 2015 10:55 AM To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org; Pollini, Gregory P Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Assuming that we define a range of 3 values, Assuming that 0 is the lowest priority and 2 the highest, Assuming that an agent receives 4 messages at the same time while being in = overload control: * 1) ULR with Prio-0 * 2) ULR with Prio-1 * 3) ULR with Prio-2 * 4) ULR with no priority AVP Assuming that the default is locally defined as proposed below, How do you know that the ULR with priority 2 will be handled with a higher = priority than the request without priority indication? And what about ULR message with priority 1 with two levels of highest prior= ity e.g. emergency/Important and government/very important? Sorry if the answer is obvious but I fail to understand. Lionel De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] Envoy=E9 : samedi 3 octobre 2015 01:21 =C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C Cc : DiME; dime@ietf.org; Pollini, Gregory P Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels Hello all, Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.21= 2 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defi= ned. Having 15 rather than 16 would be useful from an interworking point of view= on Diameter interfaces connecting to the EPS. Also, my understanding has been that the default value is per local policy. My 2 cents.... Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf = of lionel.morand@orange.com [lionel.morand= @orange.com] Sent: Thursday, October 01, 2015 3:36 AM To: Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Hi, I think that the case "no Priority indication in request" is the default si= tuation today. So if we agree that it should be possible to explicitly indicate a request = with a lower priority, we should divide the range of priority values in thr= ee sub-ranges: [lower priorities][no priority indication][higher priorities= ], e.g. with 17 values: [0-7][8][9-16]. If any operator can freely fix the default value, there would be no way to = ensure the sender that a request with a specific priority value (e.g. 6) wi= ll be handled with a lower or higher priority than a request with no priori= ty indication. Therefore, for a deterministic handling mechanism, I think that it is then = more relevant to define a standard value for the default value. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn Envoy=E9 : mercredi 30 septembre 2015 22:53 =C0 : DOLLY, MARTIN C Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels Same here. The "default priority" should be a matter of local policy. Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "DOLLY, MARTIN C" > To: Steve Donovan >, "dime@ietf.org" > Date: 09/30/2015 04:40 PM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" = > ________________________________ Me as well From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, September 30, 2015 4:38 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels I'm okay with Jay's proposal on not specifying a default value. Steve On 9/30/15 3:27 PM, Lee, Jay wrote: Hi Steve and all, For the first proposal, as I indicated, I support increasing the number of = priority levels up to 16. I am also fine with the second proposal. My question is: do we need to mand= ate this feature, as individual operators have different situations? Perhap= s some flexibility should be allowed? Instead of mandating it, we can inclu= de the statement that when there is no DRMP AVP, this correspond to 'normal= traffic' without a particular high or low priority. Then each operator can= map this default to a value (e.g., 8 or something else) that they feel app= ropriate. Thanks, Jay _______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_C026C31E3CD6CA43953D6D95AB480480047A6ECASAC1EXP009uswin_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I also think that we agre= e on all different points for the finalization, except one point: the value= for the default case. Use of the default case as discussed here is rather in the future than in the present for us, so I do not have = strong opinion, especially when the default value can be overwritten.

 <= /p>

Looking at this objective= ly and also for the sake of progress, however, it would be prudent to have = more than one lower priority cases. In the near future, we may identify additional use cases for lower priority case. Even with on= e use case identified, this does not necessarily mean one priority level pe= r use case. One use case may require multiple lower priority levels, depend= ing on applications.

 <= /p>

Any value from 9 to 12 se= ems reasonable to me. But, without all use cases identified at the present = time, I propose 10 (JJacques’ proposal) or 11.

 <= /p>

Thanks,=

 <= /p>

Jay

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Monday, October 26, 2015 8:11 AM
To: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Hi

 <= /p>

Please see my comments al= so in line. I think we are close to finalise our choice on the different po= ints  of this thread

 <= /p>

Best regards

 <= /p>

JJacques

 <= /p>

De := DiME [mail= to:dime-bounces@ietf.org] De la part de Lee, Jay
Envoy=E9 : vendredi 23 octobre 2015 18:57
=C0 : dime@ietf.org
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime= ] #92 (drmp): Range of priority levels)

 

Please see my comments in= line.

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Friday, October 23, 2015 8:02 AM
To: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Please see my comment= s inline.

Steve

On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote:

See inline

 <= /p>

From: DiME [= mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay
Sent: Friday, October 23, 2015 1:59 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) <jean-jacques.trottin@alcatel-lucent.com>; dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Some further comments fro= m my side:

 <= /p>

*/ If we need to assign (= but not specify) a value to the default case, we need to make it clear that= this value can be overwritten by operators, and the value is for some use cases like e.g., equipment having the same value when leav= ing the factory, so that there would be no misunderstanding.

mcd- ok=

SRD> I think the current proposed text makes this= clear.
[JL] Agree that the current text is OK especi= ally when we use ‘May’ in place of ‘Should’

[JJ] OK

.

 <= /p>

mcd-ok

SRD> I'm okay with making this a MAY.

[JL]  Agreed

[JJ] Also in favor of a M= AY

 

mcd- value should allow f= or assigning lower values, though a carrier can assign what they want in th= eir network, there needs to be a common meaning at the interconnection point

SRD> I'm open to any value we decide on.  If= there are real use cases that require pushing the default value more to th= e middle then we should do so.  At this point I've heard one use case = for the default being something other then the lowest value, thus the proposal to use priority_14 as the default.  <= o:p>

[JJ] Regarding use cases,= there may be

- =          The case where fo= r “normal” users, an application use the default value for most= of its requests except some which have a lower priority<= /p>

- =          the case where be= sides “normal” user (and high priority users), some users have = lower priorities, e.g. Some Machine type Communications (MTC) devices.

So potentially more than = one low priority level would be needed.

We also have chosen a rat= her large range of values (16) , allowing flexibility for an operator when = they define the number of priorities they want , leaving possibility to future additions. If PRIORITY _14 is the default, it leaves= only one lower priority and an operator  cannot add a second one &nbs= p;except by choosing  a default value other than the 14  value.

Then as, in practice, we = may expect a range of low priority smaller than  the range of high pri= ority values, this is why the default value was proposed to be in the range 9-12  . Then I proposed 10 so to do a proposal but I am = open on another value.

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      

mcd-ok

SRD> I don't see a compelling argument to move be= yond 16. 
In addition, it isn't clear to me that there is value in defining an extens= ibility mechanism beyond what is already supported by Diameter.  Doing= so would add significant complexity to the DRMP mechanism for something th= at, in my view, has a low probability of being used.

I propose that we not allow extending the DRMP AVP.  Rather we require= that any extension require a new AVP.  We can then leave it to the do= cument that proposes the extension to deal with determining whether send th= e DRMP AVP or the newly defined DRMPv2 AVP. 
[JL] When we proposed that the range be exten= ded to 16, we thought that ‘16’ was large enough and future pro= of.

I am okay with having = an extensibility bit, if other companies want it. That said, I agree that i= t has a low probability of being used and added complexity.

[JJ] JJ I also agree t= hat with 16 values , the offered range is large enough in practice. This po= int is only to check if it would be easy to do an extension, if we have thi= s requirement in the future.  I agree with Steve that for an extensibility, it will require a new AVP in a new d= ocument rather than to define a set of reserved values in the DRMP AVP. &nb= sp;A point is that it will require an additional parsing effort for a node = to look for this second AVP even if it is not present most of the time.  

 

SRD> I agree that I don't see value in the +9= to -9 proposal.

[JL] Agreed

[J] I presented this seco= nd  approach  so to review the possible alternatives as we usuall= y do before selecting the solution, this alternative being already used in a recent RFC.   That being said, I am fine with the enum= erated DRMP AVP.

 <= /p>

Best regards

 <= /p>

JJacques  

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Thursday, October 22, 2015 9:39 AM
To: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Hi

 <= /p>

1.      PRIORITY_14 as default priority value onl= y allows one level of lower priority (PRIORITY_15)  than the default o= ne; this seems not enough.  As use cases, we may have  some Machine type Communication (LTC) devices that may have lower priorities th= at normal communications without priority.  Even within a Diameter app= lication, some commands may have a lower priority as having a secundary imp= ortance.

 

Then which default  value ?

- &nbs= p;      it could be PRIORITY_8 in the middle, or = if we prefer to have a  larger range for higher priorities  than = for lower priorities,  the default value could be  e.g. PRIORITY_= 10,  giving 9 higher priorities and 5 lower priorities than the default one. I = would have a preference for this value PRIORITY_10.

 <= /p>

2.      About extensibility, the current range of= 16 values is already large, but we can have  a reserved value to indi= cate a further extension. With  an enumerated AVP, there is no possibility to add new values. 

 <= /p>

3.      I also had a look to some other IETF RFCs= addressing priorities that Ken mentioned, so to see if we can benefit from= these approaches although done for different contexts.

- &nbs= p;      in RFC 4412 (Resource-Priority Header in = SIP), wps and ets namespaces have a range of 5 values (0 to 4) with 0 as th= e highest priority  . But I have not found some indication  (I may have missed it) about the default priority  (I mean a SIP requ= est without  Resource-Priority Header compared  to a SIP request = with the Header). Implicitly, I would assume a SIP request without  Re= source-Priority Header corresponds to  the lowest priority.  DRMP has a similar approach but with  a larger range and also l= ower priorities.

 <= /p>

- &nbs= p;      RFC  6710 (priority for SMTP),  = ;uses another encoding of the priority values with an integer between -9 an= d +9. Lower priorities  are negative an higher priority being posi= tive. When a value increases, it means a higher priority, so the opposite  = to DRMP, wps or ets.  But the value 0 is here naturally the default va= lue. So this is an encoding alternative  to the  Enumerated type = of the DRMP AVP which avoids the question of the default value.

Note: RFC  67= 10 also defines some Priority Assignment Policies using a subset of the ran= ge.

 <= /p>

   SMTP server= s compliant with this specification are not

   required to supp= ort all 19 distinct priority levels (i.e., to treat

   each priority va= lue as a separate priority), ….  That is, an

   implementation t= hat only supports N priority levels (where N < 19)

   will internally = round up a syntactically valid priority value that

   isn't supported = to the next higher supported number (or to the

   highest supporte= d priority, if the value is higher than any supported priority).

- &nbs= p;      This raises the question to have this typ= e of  guideline if considered useful.

So to have your feedback

 <= /p>

Best regards<= /o:p>

 <= /p>

JJacques

 <= /p>

De : DiME= [<= span lang=3D"EN-US">mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C
Envoy=E9 : jeudi 15 octobre 2015 12:33
=C0 : Lee, Jay; ken carlberg; Steve Donovan
Cc : dime@ietf.org
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime= ] #92 (drmp): Range of priority levels)

 

A couple thoughts:=

1. &nb= sp;    There needs to be a default value defined= by the standard, so that equipment have the same value leaving the factory=

2. &nb= sp;    This value can be over written based on l= ocal policy

3. &nb= sp;    Should have an extensibility bit in order= to and more values in the future

 <= /p>

 <= /p>

From: DiME [= mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay
Sent: Thursday, October 15, 2015 6:16 AM
To: ken carlberg <carlberg= @g11.org.uk>; Steve Donovan <srdonovan@usdonovans.com>
Cc: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

From my side, some more d= iscussion on Steve’s mail may be needed.

 <= /p>

‘Should’ vs. = ‘Must’:

One can say that ‘S= hould’ is not mandatory. But, in practice, this is a fairly strong st= atement, and often taken as required. So in this sense, the proposed Note is certainly helpful. But, since we allow operators to override the v= alue, I don’t see the reason why we use ‘Should’. My sugg= estion is using ‘May’.

 <= /p>

PRIORITY_14 priority:

Since operators can overw= rite it, I was not too concerned about it. But if we want to put some value= , why ‘14’? A value lower than 14 is suggested in order to allow more rooms for lower priorities.

 <= /p>

Jay

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg
Sent: Wednesday, October 14, 2015 8:40 AM
To: Steve Donovan
Cc: dime@ietf.org
Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (d= rmp): Range of priority levels)

 

with respect to the diff-serv example brought up bel= ow, some thing to add to that discussion is that it starts off with separat= e and distinct forwarding behavior whose marked packets provide segmentatio= n of other IP traffic.  The availability of only 6 bits to play with (along with the headaches of transitive trust)= also discouraged a line of thought to define end-to-end priority handling = versus a per diff-serv domain treatment.  RFC-4594 did provide configu= ration guidelines, but that’s a different story.

 

So back to a couple of ideas to consider.=

 

1) reserved space.  if we go back to the diff-s= erv model, the diff-serv working group agreed to set aside a set of values = that was reserved for experimental use that could be re-assigned some time = in the future.  I’m not suggesting that there should be space set side for experiments, but rather it may be prude= nt to set aside a reserved set of bits/values so that one doesn't need to d= efine a new AVP if in the future there was a need to define added values be= yond the 5 (plus some fudge factor) already mentioned on the list. 

 

2) sets of users.  previous work (e.g., rfc-441= 2, rfc-6710) recognized that there can be several sets of users/services th= at are distinct from each other and yet need to prioritize the traffic. &nb= sp;I bring this up because the draft already identifies two sets of users in sections 5.1 and 5.2 (note: I’m assu= ming that the latter is aimed at the general public and related to 911/112/= 999 type calls, which should probably be more specific in the draft).  = ;And there is also the potential of Firstnet users in the US.

 

As a side note, the distinction and separation of ge= neral public and other prioritized users in public phone infrastructures is= not exclusive to the US, so the group should not be concerned that this is= a US centric effort.  There has been GTPS in the UK, as well as other systems in other countries.  The RFC= is a bit dated, but feel free to go over rfc-4190 for added background.

 

and just to reiterate.  I’m not making re= commendations in the above — just bringing up some food for thought.<= o:p>

 

-ken

 

 

On Oct 14, 2015, at 10:12 AM, Steve Donovan <srdonovan@usdonovans.com> wr= ote:

 

Jay,

The current text is a SHOULD level require= ment:

   When there is a mix of transa= ctions specifying priority in request
   messages and transactions tha= t do not have the priority specified,
   transactions that do not have= a specified priority SHOULD be treated
   as having the PRIORITY_14 pri= ority.

As such, operators can choose to either no= t implement a priority or define a different value for their network.

I propose adding the following note after = this paragraph to further explain why it is a SHOULD and not a MUST:=

      Note: There= are scenarios where operators might want to 
      specify a d= ifferent default value for transactions that do not
      have an exp= licit priority.  In this case, the operator defined
      local polic= y would override the use of PRIORITY_14 as
      the default= priority.

This leaves the ability for there to be de= terministic behavior in Diameter networks that require a default to be defi= ned and are happy with the specified default.  It also gives operators= the ability to define a different behavior, most likely with some priority handling/mapping at the edge of the network= .

Does this address your concerns?
Regards,

Steve

On 10/14/15= 2:59 AM, Lee, Jay wrote:

From: DiME [mai= lto:dime-bounces@ietf.org]=  On Behalf Of lionel.morand@orange.com
Sent: Tuesday, Oct= ober 13, 2015 10:55 AM
To: Shaikh, Viqar = A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; <= a href=3D"mailto:dime@ietf.org">dime@ietf.org; Pollini, Gregory P
Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 

=B7     &nbs= p; 1) ULR with Prio-0

=B7     &nbs= p; 2) ULR with Prio-1

=B7     &nbs= p; 3) ULR with Prio-2

=B7     &nbs= p; 4) ULR with no priority AVP

De :<= /span> Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] 
Envoy=E9 : sa= medi 3 octobre 2015 01:21
=C0 : MORAND = Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; dime= @ietf.org; Pollini, Gregory P
Objet : RE: [= Dime] [dime] #92 (drmp): Range of priority levels

 

Hello all,

 =

Note tha= t the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 t= akes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined.

 =

Having 15 rat= her than 16 would be useful from an interworking point of view on Diameter = interfaces connecting to the EPS.  

 =

Also, my unde= rstanding has been that the default value is per local policy. 

 =

My 2 cents....

Viqar 

<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">From: DiME [<= span lang=3D"EN-US" style=3D"color:purple">dime-bounces@ietf.org= ] on behalf of lionel.morand@orange.com [lionel.morand@orange.com<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">]
Sent: Thursday, Oc= tober 01, 2015 3:36 AM
To: Janet P Gunn; = DOLLY, MARTIN C
Cc: DiME; dime@ietf.= org
Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 

 

 

Regards,

 <= o:p>

Lionel

 <= o:p>

 <= o:p>

De : DiME [mai= lto:dime-bounces@ietf.org]=  De la part de&nbs= p;Janet P Gunn
Envoy=E9 : me= rcredi 30 septembre 2015 22:53
=C0 : DOLLY, = MARTIN C
Cc : DiME; dime@ietf.org<= span lang=3D"FR" style=3D"font-size:10.0pt;font-family:"Tahoma",&= quot;sans-serif"">
Objet : Re: [= Dime] [dime] #92 (drmp): Range of priority levels<= o:p>

 <= o:p>

Same here. &nb= sp;The "default priority" should be a matter of local policy. 

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose. 



From:        &= quot;DOLLY, MARTIN C" <md3135@att.com<= /a>> =
To:        S= teve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org>&nbs= p;
Date:        0= 9/30/2015 04:40 PM 
Subject:        Re: [Dime] [dime] #92 (drmp): Range of priority levels 
Sent by:        "DiME" <dime-bounces@ietf.org>




Me as well 
  
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Dono= van
Sent: Wednesday, Sept= ember 30, 2015 4:38 PM
To: dime@ietf.org
Subject: = ;Re: [Dime] [dime] #92 (drmp): Range of priority= levels 
  
I'm okay with Jay's proposal on not specifying a default value= .

Steve 
On 9/30/15 3:27 PM, Lee, Jay wrote: 
Hi Steve and all,=  
  
For the first proposal, as I indicated, I support increasing t= he number of priority levels up to 16. 
  
I am also fine with the second proposal. My question is: do we= need to mandate this feature, as individual operators have different situa= tions? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that when there is no DRMP A= VP, this correspond to ‘normal traffic’ without a particular hi= gh or low priority. Then each operator can map this default to a value (e.g= ., 8 or something else) that they feel appropriate. 
  
Thanks, 
  
Jay <= br>


__________________________________________= _____ 
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= 

_____________________________________=
___________________________________________________________________________=
_________
 <=
/o:p>
Ce message et ses pieces jointes peuv=
ent contenir des informations confidentielles ou privilegiees et ne doivent=
 donc
pas etre diffuses, exploites ou copie=
s sans autorisation. Si vous avez recu ce message par erreur, veuillez le s=
ignaler
a l'expediteur et le detruire ainsi q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration,
Orange decline toute responsabilite s=
i ce message a ete altere, deforme ou falsifie. Merci.

 


This message and its attachments may contain conf=
idential or privileged information that may be protected by law;


they should not be distributed, used or copied wi=
thout authorisation.


If you have received this email in error, please =
notify the sender and delete this message and its attachments.<=
/o:p>


As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=



Thank you.


_____________________________________=
___________________________________________________________________________=
_________
 <=
/o:p>
Ce message et ses pieces jointes peuv=
ent contenir des informations confidentielles ou privilegiees et ne doivent=
 donc
pas etre diffuses, exploites ou copie=
s sans autorisation. Si vous avez recu ce message par erreur, veuillez le s=
ignaler
a l'expediteur et le detruire ainsi q=
ue les pieces jointes. Les messages electroniques etant susceptibles d'alte=
ration,
Orange decline toute responsabilite s=
i ce message a ete altere, deforme ou falsifie. Merci.

 


This message and its attachments may contain conf=
idential or privileged information that may be protected by law;


they should not be distributed, used or copied wi=
thout authorisation.


If you have received this email in error, please =
notify the sender and delete this message and its attachments.<=
/o:p>


As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=



Thank you.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.ietf.org/mailman/listinfo/di=
me





__________________________________________=
_____

DiME mailing list

DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime=

 

 

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

 

--_000_C026C31E3CD6CA43953D6D95AB480480047A6ECASAC1EXP009uswin_-- From nobody Wed Oct 28 13:15:36 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418631ACD43 for ; Wed, 28 Oct 2015 13:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Wy4o9N3NEjb for ; Wed, 28 Oct 2015 13:15:18 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5915E1ACE4E for ; Wed, 28 Oct 2015 13:06:26 -0700 (PDT) Received: from 190.sub-70-196-8.myvzw.com ([70.196.8.190]:4566 helo=[100.67.181.49]) by biz131.inmotionhosting.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.85) (envelope-from ) id 1ZrWzA-003F0O-Tx; Wed, 28 Oct 2015 13:06:25 -0700 From: Steve Donovan To: "Lee, Jay" , Date: Wed, 28 Oct 2015 15:06:16 -0500 Message-ID: <150b00ed6f0.277f.0301301ad371d4c21d5a2092e0e442f2@usdonovans.com> In-Reply-To: <20151028183455.88E9E1A899A@ietfa.amsl.com> References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> <20151014075941.062E21B2C1F@ietfa.amsl.com> <561E62C9.20500@usdonovans.com> <1431d0b2-5ae7-426e-b5ff-42b23fecbee5@CASAC1EXH002.uswin.ad.vzwcorp.com> <20151015101558.111761ACD5C@ietfa.amsl.com> <3e7a25c8-5eea-49a5-9905-3009c4dc45b8@NYORA1HUB001.uswin.ad.vzwcorp.com> <20151023055927.9223C1B3292@ietfa.amsl.com> <20151023165728.7D0E01A874F@ietfa.amsl.com> <20151028183455.88E9E1A899A@ietfa.amsl.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.7.29 (build: 21070094) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------150b00edfc36848277f42e0bff0" X-OutGoing-Spam-Status: No, score=0.6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 28 Oct 2015 20:15:34 -0000 This is a multi-part message in MIME format. ------------150b00edfc36848277f42e0bff0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Ten is acceptable to me. Steve On October 28, 2015 1:36:00 PM "Lee, Jay" wrote: > I also think that we agree on all different points for the finalization, > except one point: the value for the default case. Use of the default case > as discussed here is rather in the future than in the present for us, so I > do not have strong opinion, especially when the default value can be > overwritten. > > Looking at this objectively and also for the sake of progress, however, it > would be prudent to have more than one lower priority cases. In the near > future, we may identify additional use cases for lower priority case. Even > with one use case identified, this does not necessarily mean one priority > level per use case. One use case may require multiple lower priority > levels, depending on applications. > > Any value from 9 to 12 seems reasonable to me. But, without all use cases > identified at the present time, I propose 10 (JJacques' proposal) or 11. > > Thanks, > > Jay > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, > JEAN-JACQUES (JEAN-JACQUES) > Sent: Monday, October 26, 2015 8:11 AM > To: dime@ietf.org > Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 > (drmp): Range of priority levels) > > Hi > > Please see my comments also in line. I think we are close to finalise our > choice on the different points of this thread > > Best regards > > JJacques > > De : DiME [mailto:dime-bounces@ietf.org] De la part de Lee, Jay > Envoyé : vendredi 23 octobre 2015 18:57 > À : dime@ietf.org > Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 > (drmp): Range of priority levels) > > Please see my comments inline. > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: Friday, October 23, 2015 8:02 AM > To: dime@ietf.org > Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 > (drmp): Range of priority levels) > > Please see my comments inline. > > Steve > On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote: > See inline > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay > Sent: Friday, October 23, 2015 1:59 AM > To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) > ; > dime@ietf.org > Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 > (drmp): Range of priority levels) > > Some further comments from my side: > > */ If we need to assign (but not specify) a value to the default case, we > need to make it clear that this value can be overwritten by operators, and > the value is for some use cases like e.g., equipment having the same value > when leaving the factory, so that there would be no misunderstanding. > mcd- ok > SRD> I think the current proposed text makes this clear. > [JL] Agree that the current text is OK especially when we use 'May' in > place of 'Should' > [JJ] OK > . > > */ Since we agree that the default value is per local policy, 'May' is > preferred to 'Should' in order not to cause confusion. > mcd-ok > SRD> I'm okay with making this a MAY. > [JL] Agreed > [JJ] Also in favor of a MAY > > */ For assignment of the default value, I am quite open. But any value > between 9 - 12 seems reasonable to me. > mcd- value should allow for assigning lower values, though a carrier can > assign what they want in their network, there needs to be a common meaning > at the interconnection point > SRD> I'm open to any value we decide on. If there are real use cases that > require pushing the default value more to the middle then we should do so. > At this point I've heard one use case for the default being something other > then the lowest value, thus the proposal to use priority_14 as the default. > [JJ] Regarding use cases, there may be > > - The case where for "normal" users, an application use the > default value for most of its requests except some which have a lower priority > > - the case where besides "normal" user (and high priority users), > some users have lower priorities, e.g. Some Machine type Communications > (MTC) devices. > So potentially more than one low priority level would be needed. > We also have chosen a rather large range of values (16) , allowing > flexibility for an operator when they define the number of priorities they > want , leaving possibility to future additions. If PRIORITY _14 is the > default, it leaves only one lower priority and an operator cannot add a > second one except by choosing a default value other than the 14 value. > Then as, in practice, we may expect a range of low priority smaller than > the range of high priority values, this is why the default value was > proposed to be in the range 9-12 . Then I proposed 10 so to do a proposal > but I am open on another value. > > */ Current proposal of 16 values may be enough now, but I am fine with > having an extensibility bit to be future proof. > mcd-ok > SRD> I don't see a compelling argument to move beyond 16. > In addition, it isn't clear to me that there is value in defining an > extensibility mechanism beyond what is already supported by Diameter. > Doing so would add significant complexity to the DRMP mechanism for > something that, in my view, has a low probability of being used. > > I propose that we not allow extending the DRMP AVP. Rather we require that > any extension require a new AVP. We can then leave it to the document that > proposes the extension to deal with determining whether send the DRMP AVP > or the newly defined DRMPv2 AVP. > [JL] When we proposed that the range be extended to 16, we thought that > '16' was large enough and future proof. > I am okay with having an extensibility bit, if other companies want it. > That said, I agree that it has a low probability of being used and added > complexity. > [JJ] JJ I also agree that with 16 values , the offered range is large > enough in practice. This point is only to check if it would be easy to do > an extension, if we have this requirement in the future. I agree with > Steve that for an extensibility, it will require a new AVP in a new > document rather than to define a set of reserved values in the DRMP AVP. A > point is that it will require an additional parsing effort for a node to > look for this second AVP even if it is not present most of the time. > > */ I am not sure of alternative encoding method (say, +9 to -9 per > JJacques' proposal) compared to the current enumerated type of DRMP. It > offers a logical way of assigning a value 0 to the default case. But it > offers less flexibility to operators, since the default value may not be > easily moved to have more higher/lower priority values. Also, we are used > to the enumerated type of DRMP and just want to have extension from 5 to > 16, but this may require more deviation from the current design and > thinking. For this, I would like to see more on qualitative pros/cons, but, > given its little benefit, I am reluctant to accept this alternative. > SRD> I agree that I don't see value in the +9 to -9 proposal. > [JL] Agreed > [J] I presented this second approach so to review the possible > alternatives as we usually do before selecting the solution, this > alternative being already used in a recent RFC. That being said, I am > fine with the enumerated DRMP AVP. > > Best regards > > JJacques > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, > JEAN-JACQUES (JEAN-JACQUES) > Sent: Thursday, October 22, 2015 9:39 AM > To: dime@ietf.org > Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 > (drmp): Range of priority levels) > > Hi > > > 1. PRIORITY_14 as default priority value only allows one level of > lower priority (PRIORITY_15) than the default one; this seems not enough. > As use cases, we may have some Machine type Communication (LTC) devices > that may have lower priorities that normal communications without priority. > Even within a Diameter application, some commands may have a lower > priority as having a secundary importance. > > > Then which default value ? > > - it could be PRIORITY_8 in the middle, or if we prefer to have a > larger range for higher priorities than for lower priorities, the default > value could be e.g. PRIORITY_10, giving 9 higher priorities and 5 lower > priorities than the default one. I would have a preference for this value > PRIORITY_10. > > > 2. About extensibility, the current range of 16 values is already > large, but we can have a reserved value to indicate a further extension. > With an enumerated AVP, there is no possibility to add new values. > > > 3. I also had a look to some other IETF RFCs addressing priorities > that Ken mentioned, so to see if we can benefit from these approaches > although done for different contexts. > > - in RFC 4412 (Resource-Priority Header in SIP), wps and ets > namespaces have a range of 5 values (0 to 4) with 0 as the highest priority > . But I have not found some indication (I may have missed it) about the > default priority (I mean a SIP request without Resource-Priority Header > compared to a SIP request with the Header). Implicitly, I would assume a > SIP request without Resource-Priority Header corresponds to the lowest > priority. DRMP has a similar approach but with a larger range and also > lower priorities. > > > - RFC 6710 (priority for SMTP), uses another encoding of the > priority values with an integer between -9 and +9. Lower priorities are > negative an higher priority being positive. When a value increases, it > means a higher priority, so the opposite to DRMP, wps or ets. But the > value 0 is here naturally the default value. So this is an encoding > alternative to the Enumerated type of the DRMP AVP which avoids the > question of the default value. > > Note: RFC 6710 also defines some Priority Assignment Policies using a > subset of the range. > > RFC 6710 has also this guideline : > SMTP servers compliant with this specification are not > required to support all 19 distinct priority levels (i.e., to treat > each priority value as a separate priority), .... That is, an > implementation that only supports N priority levels (where N < 19) > will internally round up a syntactically valid priority value that > isn't supported to the next higher supported number (or to the > highest supported priority, if the value is higher than any supported > priority). > > - This raises the question to have this type of guideline if > considered useful. > > So to have your feedback > > Best regards > > JJacques > > De : DiME [mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C > Envoyé : jeudi 15 octobre 2015 12:33 > À : Lee, Jay; ken carlberg; Steve Donovan > Cc : dime@ietf.org > Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 > (drmp): Range of priority levels) > > A couple thoughts: > > 1. There needs to be a default value defined by the standard, so that > equipment have the same value leaving the factory > > 2. This value can be over written based on local policy > > 3. Should have an extensibility bit in order to and more values in the > future > > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay > Sent: Thursday, October 15, 2015 6:16 AM > To: ken carlberg >; Steve > Donovan > > Cc: dime@ietf.org > Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 > (drmp): Range of priority levels) > > >From my side, some more discussion on Steve's mail may be needed. > > 'Should' vs. 'Must': > One can say that 'Should' is not mandatory. But, in practice, this is a > fairly strong statement, and often taken as required. So in this sense, the > proposed Note is certainly helpful. But, since we allow operators to > override the value, I don't see the reason why we use 'Should'. My > suggestion is using 'May'. > > PRIORITY_14 priority: > Since operators can overwrite it, I was not too concerned about it. But if > we want to put some value, why '14'? A value lower than 14 is suggested in > order to allow more rooms for lower priorities. > > Jay > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg > Sent: Wednesday, October 14, 2015 8:40 AM > To: Steve Donovan > Cc: dime@ietf.org > Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): > Range of priority levels) > > with respect to the diff-serv example brought up below, some thing to add > to that discussion is that it starts off with separate and distinct > forwarding behavior whose marked packets provide segmentation of other IP > traffic. The availability of only 6 bits to play with (along with the > headaches of transitive trust) also discouraged a line of thought to define > end-to-end priority handling versus a per diff-serv domain treatment. > RFC-4594 did provide configuration guidelines, but that's a different story. > > So back to a couple of ideas to consider. > > 1) reserved space. if we go back to the diff-serv model, the diff-serv > working group agreed to set aside a set of values that was reserved for > experimental use that could be re-assigned some time in the future. I'm > not suggesting that there should be space set side for experiments, but > rather it may be prudent to set aside a reserved set of bits/values so that > one doesn't need to define a new AVP if in the future there was a need to > define added values beyond the 5 (plus some fudge factor) already mentioned > on the list. > > 2) sets of users. previous work (e.g., rfc-4412, rfc-6710) recognized that > there can be several sets of users/services that are distinct from each > other and yet need to prioritize the traffic. I bring this up because the > draft already identifies two sets of users in sections 5.1 and 5.2 (note: > I'm assuming that the latter is aimed at the general public and related to > 911/112/999 type calls, which should probably be more specific in the > draft). And there is also the potential of Firstnet users in the US. > > As a side note, the distinction and separation of general public and other > prioritized users in public phone infrastructures is not exclusive to the > US, so the group should not be concerned that this is a US centric effort. > There has been GTPS in the UK, as well as other systems in other countries. > The RFC is a bit dated, but feel free to go over rfc-4190 for added > background. > > and just to reiterate. I'm not making recommendations in the above - just > bringing up some food for thought. > > -ken > > > On Oct 14, 2015, at 10:12 AM, Steve Donovan > > wrote: > > Jay, > > The current text is a SHOULD level requirement: > > When there is a mix of transactions specifying priority in request > messages and transactions that do not have the priority specified, > transactions that do not have a specified priority SHOULD be treated > as having the PRIORITY_14 priority. > > As such, operators can choose to either not implement a priority or define > a different value for their network. > > I propose adding the following note after this paragraph to further explain > why it is a SHOULD and not a MUST: > > Note: There are scenarios where operators might want to > specify a different default value for transactions that do not > have an explicit priority. In this case, the operator defined > local policy would override the use of PRIORITY_14 as > the default priority. > > This leaves the ability for there to be deterministic behavior in Diameter > networks that require a default to be defined and are happy with the > specified default. It also gives operators the ability to define a > different behavior, most likely with some priority handling/mapping at the > edge of the network. > > Does this address your concerns? > > Regards, > > Steve > On 10/14/15 2:59 AM, Lee, Jay wrote: > Regarding the issue of whether we need to specify a default value or not, > there are pros and cons. > > If we specify a value for the default case, we can see the benefits in > scenarios between different operator networks, but we take away important > options on what operators can do with priority values. On the other hand, > if we do not specify the default value, operators may have more options, > but there is a question of what to do for this inter-PLMN cases when the > networks may use different default values. > > In practice, this issue can be addressed at the edge of the network, where > Diameter edge agent (DEA) can perform some priority mapping based on > bilateral roaming agreement (or SLA (service level agreement)) and other > means to insure the proper handling. One may argue that this is not as good > as the 'deterministic' case, but operator should be able handle this in a > reasonable way. We are fully aware of the fact that, in case of this > 'non-deterministic' case, the default value can differ from one operator > network to another, and it becomes difficult to guarantee the intended > priority handling. Despite this, we still prefer giving options to > operators by not specifying the default value. > > What we are saying here, however, is not anything new. This is the typical > way of handling priority levels. If anything, specifying the default value > would be something new. As already mentioned in CT discussion, there is a > good example of this - Internet QoS, more specifically DiffServ. > > In order to guarantee end-to-end QoS for a specific service, IETF could > have specified a value (DiffServ codepoint) for the specific service to > have predetermined handling of the traffic, but IETF did not. Instead, > DiffServ simply provided a framework for operators to have its own > classification and differentiated treatment of the services. To guarantee > end-to-end QoS across different networks, then, operators need to do packet > inspection, (re)classification, QoS mapping, use of SLA and possibly others > at the edge of network (edge router). Therefore, in the DiffServ > architecture, intelligence was pushed to the edge of the network. While the > end results may not be guaranteed as well as in the case of predetermined > handling, it was still a preferred way to give flexibility to operators. My > point is that we went through all these troubles to give options of > priority handling to operators. > > By the way, if we are thinking of possibility of specifying the default > value, are we assuming that all operators are interested in this feature > (default value in the middle, and high and low priorities at other ends)? > Aren't there other operators who are not interested in this feature? I know > that at least there is one - Verizon. We have no interest in this feature, > and no plan for implementing it. We are OK, if other operators are > interested in this feature, and the default value is NOT specified. But we > are certainly not happy if DIME is trying to impose this on us. > > Jay > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of > lionel.morand@orange.com > Sent: Tuesday, October 13, 2015 10:55 AM > To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C > Cc: DiME; dime@ietf.org; Pollini, Gregory P > Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels > > Assuming that we define a range of 3 values, > Assuming that 0 is the lowest priority and 2 the highest, > Assuming that an agent receives 4 messages at the same time while being in > overload control: > * 1) ULR with Prio-0 > * 2) ULR with Prio-1 > * 3) ULR with Prio-2 > * 4) ULR with no priority AVP > > Assuming that the default is locally defined as proposed below, > > How do you know that the ULR with priority 2 will be handled with a higher > priority than the request without priority indication? > And what about ULR message with priority 1 with two levels of highest > priority e.g. emergency/Important and government/very important? > > Sorry if the answer is obvious but I fail to understand. > > Lionel > > > > De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] > Envoyé : samedi 3 octobre 2015 01:21 > À : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C > Cc : DiME; dime@ietf.org; Pollini, Gregory P > Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels > > Hello all, > > Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS > 29.212 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not > defined. > > Having 15 rather than 16 would be useful from an interworking point of view > on Diameter interfaces connecting to the EPS. > > Also, my understanding has been that the default value is per local policy. > > My 2 cents.... > Viqar > ________________________________ > From: DiME [dime-bounces@ietf.org] on behalf > of lionel.morand@orange.com > [lionel.morand@orange.com] > Sent: Thursday, October 01, 2015 3:36 AM > To: Janet P Gunn; DOLLY, MARTIN C > Cc: DiME; dime@ietf.org > Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels > Hi, > > I think that the case "no Priority indication in request" is the default > situation today. > So if we agree that it should be possible to explicitly indicate a request > with a lower priority, we should divide the range of priority values in > three sub-ranges: [lower priorities][no priority indication][higher > priorities], e.g. with 17 values: [0-7][8][9-16]. > If any operator can freely fix the default value, there would be no way to > ensure the sender that a request with a specific priority value (e.g. 6) > will be handled with a lower or higher priority than a request with no > priority indication. > > Therefore, for a deterministic handling mechanism, I think that it is then > more relevant to define a standard value for the default value. > > Regards, > > Lionel > > > De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn > Envoyé : mercredi 30 septembre 2015 22:53 > À : DOLLY, MARTIN C > Cc : DiME; dime@ietf.org > Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels > > Same here. The "default priority" should be a matter of local policy. > > Janet > > This is a PRIVATE message. If you are not the intended recipient, please > delete without copying and kindly advise us by e-mail of the mistake in > delivery. NOTE: Regardless of content, this e-mail shall not operate to > bind CSC to any order or other contract unless pursuant to explicit written > agreement or government initiative expressly permitting the use of e-mail > for such purpose. > > > > From: "DOLLY, MARTIN C" > > To: Steve Donovan > >, > "dime@ietf.org" > > Date: 09/30/2015 04:40 PM > Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels > Sent by: "DiME" > > ________________________________ > > > > Me as well > > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: Wednesday, September 30, 2015 4:38 PM > To: dime@ietf.org > Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels > > I'm okay with Jay's proposal on not specifying a default value. > > Steve > On 9/30/15 3:27 PM, Lee, Jay wrote: > Hi Steve and all, > > For the first proposal, as I indicated, I support increasing the number of > priority levels up to 16. > > I am also fine with the second proposal. My question is: do we need to > mandate this feature, as individual operators have different situations? > Perhaps some flexibility should be allowed? Instead of mandating it, we can > include the statement that when there is no DRMP AVP, this correspond to > 'normal traffic' without a particular high or low priority. Then each > operator can map this default to a value (e.g., 8 or something else) that > they feel appropriate. > > Thanks, > > Jay > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > _________________________________________________________________________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > > Thank you. > > _________________________________________________________________________________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > > Thank you. > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www.ietf.org/mailman/listinfo/dime > > > > > ---------- > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > ------------150b00edfc36848277f42e0bff0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit

Ten is acceptable to me.

Steve

On October 28, 2015 1:36:00 PM "Lee, Jay" <Jay.Lee@VerizonWireless.com> wrote:

I also think that we agree on all different points for the finalization, except one point: the value for the default case. Use of the default case as discussed here is rather in the future than in the present for us, so I do not have strong opinion, especially when the default value can be overwritten.

 

Looking at this objectively and also for the sake of progress, however, it would be prudent to have more than one lower priority cases. In the near future, we may identify additional use cases for lower priority case. Even with one use case identified, this does not necessarily mean one priority level per use case. One use case may require multiple lower priority levels, depending on applications.

 

Any value from 9 to 12 seems reasonable to me. But, without all use cases identified at the present time, I propose 10 (JJacques’ proposal) or 11.

 

Thanks,

 

Jay

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Monday, October 26, 2015 8:11 AM
To: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

 

Hi

 

Please see my comments also in line. I think we are close to finalise our choice on the different points  of this thread

 

Best regards

 

JJacques

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Lee, Jay
Envoyé : vendredi 23 octobre 2015 18:57
À : dime@ietf.org
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

 

Please see my comments inline.

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Friday, October 23, 2015 8:02 AM
To: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

 

Please see my comments inline.

Steve

On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote:

See inline

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay
Sent: Friday, October 23, 2015 1:59 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) <jean-jacques.trottin@alcatel-lucent.com>; dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

 

Some further comments from my side:

 

*/ If we need to assign (but not specify) a value to the default case, we need to make it clear that this value can be overwritten by operators, and the value is for some use cases like e.g., equipment having the same value when leaving the factory, so that there would be no misunderstanding.

mcd- ok

SRD> I think the current proposed text makes this clear.
[JL] Agree that the current text is OK especially when we use ‘May’ in place of ‘Should’

[JJ] OK

.

 

*/ Since we agree that the default value is per local policy, ‘May’ is preferred to ‘Should’ in order not to cause confusion.

mcd-ok

SRD> I'm okay with making this a MAY.

[JL]  Agreed

[JJ] Also in favor of a MAY

 

*/ For assignment of the default value, I am quite open. But any value between 9 – 12 seems reasonable to me.

mcd- value should allow for assigning lower values, though a carrier can assign what they want in their network, there needs to be a common meaning at the interconnection point

SRD> I'm open to any value we decide on.  If there are real use cases that require pushing the default value more to the middle then we should do so.  At this point I've heard one use case for the default being something other then the lowest value, thus the proposal to use priority_14 as the default. 

[JJ] Regarding use cases, there may be

-          The case where for “normal” users, an application use the default value for most of its requests except some which have a lower priority

-          the case where besides “normal” user (and high priority users), some users have lower priorities, e.g. Some Machine type Communications (MTC) devices.

So potentially more than one low priority level would be needed.

We also have chosen a rather large range of values (16) , allowing flexibility for an operator when they define the number of priorities they want , leaving possibility to future additions. If PRIORITY _14 is the default, it leaves only one lower priority and an operator  cannot add a second one  except by choosing  a default value other than the 14  value.

Then as, in practice, we may expect a range of low priority smaller than  the range of high priority values, this is why the default value was proposed to be in the range 9-12  . Then I proposed 10 so to do a proposal but I am open on another value.

                                                                                                                                                      &nbs p;                                                                                                 

*/  Current proposal of 16 values may be enough now, but I am fine with having an extensibility bit to be future proof.

mcd-ok

SRD> I don't see a compelling argument to move beyond 16. 
In addition, it isn't clear to me that there is value in defining an extensibility mechanism beyond what is already supported by Diameter.  Doing so would add significant complexity to the DRMP mechanism for something that, in my view, has a low probability of being used.

I propose that we not allow extending the DRMP AVP.  Rather we require that any extension require a new AVP.  We can then leave it to the document that proposes the extension to deal with determining whether send the DRMP AVP or the newly defined DRMPv2 AVP. 
[JL] When we proposed that the range be extended to 16, we thought that ‘16’ was large enough and future proof.

I am okay with having an extensibility bit, if other companies want it. That said, I agree that it has a low probability of being used and added complexity.

[JJ] JJ I also agree that with 16 values , the offered range is large enough in practice. This point is only to check if it would be easy to do an extension, if we have this requirement in the future.  I agree with Steve that for an extensibility, it will require a new AVP in a new document rather than to define a set of reserved values in the DRMP AVP.  A point is that it will require an additional parsing effort for a node to look for this second AVP even if it is not present most of the time.  

 

*/ I am not sure of alternative encoding method (say, +9 to -9 per JJacques’ proposal) compared to the current enumerated type of DRMP. It offers a logical way of assigning a value 0 to the default case. But it offers less flexibility to operators, since the default value may not be easily moved to have more higher/lower priority values. Also, we are used to the enumerated type of DRMP and just want to have extension from 5 to 16,  but this may require more deviation from the current design and thinking. For this, I would like to see more on qualitative pros/cons, but, given its little benefit, I am reluctant to accept this alternative.

SRD> I agree that I don't see value in the +9 to -9 proposal.

[JL] Agreed

[J] I presented this second  approach  so to review the possible alternatives as we usually do before selecting the solution, this alternative being already used in a recent RFC.   That being said, I am fine with the enumerated DRMP AVP.

 

Best regards

 

JJacques  

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Thursday, October 22, 2015 9:39 AM
To: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

 

Hi

 

1.      PRIORITY_14 as default priority value only allows one level of lower priority (PRIORITY_15)  than the default one; this seems not enough.  As use cases, we may have  some Machine type Communication (LTC) devices that may have lower priorities that normal communications without priority.  Even within a Diameter application, some commands may have a lower priority as having a secundary importance.

 

Then which default  value ?

-        it could be PRIORITY_8 in the middle, or if we prefer to have a  larger range for higher priorities  than for lower priorities,  the default value could be  e.g. PRIORITY_10,  giving 9 higher priorities and 5 lower priorities than the default one. I would have a preference for this value PRIORITY_10.

 

2.      About extensibility, the current range of 16 values is already large, but we can have  a reserved value to indicate a further extension. With  an enumerated AVP, there is no possibility to add new values. 

 

3.      I also had a look to some other IETF RFCs addressing priorities that Ken mentioned, so to see if we can benefit from these approaches although done for different contexts.

-        in RFC 4412 (Resource-Priority Header in SIP), wps and ets namespaces have a range of 5 values (0 to 4) with 0 as the highest priority  . But I have not found some indication  (I may have missed it) about the default priority  (I mean a SIP request without  Resource-Priority Header compared  to a SIP request with the Header). Implicitly, I would assume a SIP request without  Resource-Priority Header corresponds to  the lowest priority.  DRMP has a similar approach but with  a larger range and also lower priorities.

 

-        RFC  6710 (priority for SMTP),  uses another encoding of the priority values with an integer between -9 and +9. Lower priorities  are negative an higher priority being positive. When a value increases, it means a higher priority, so the opposite  to DRMP, wps or ets.  But the value 0 is here naturally the default value. So this is an encoding alternative  to the  Enumerated type of the DRMP AVP which avoids the question of the default value.

Note: RFC  6710 also defines some Priority Assignment Policies using a subset of the range.

 

RFC 6710 has also this guideline :

   SMTP servers compliant with this specification are not

   required to support all 19 distinct priority levels (i.e., to treat

   each priority value as a separate priority), ….  That is, an

   implementation that only supports N priority levels (where N < 19)

   will internally round up a syntactically valid priority value that

   isn't supported to the next higher supported number (or to the

   highest supported priority, if the value is higher than any supported priority).

-        This raises the question to have this type of  guideline if considered useful.

 

So to have your feedback

 

Best regards

 

JJacques

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C
Envoyé : jeudi 15 octobre 2015 12:33
À : Lee, Jay; ken carlberg; Steve Donovan
Cc : dime@ietf.org
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

 

A couple thoughts:

1.      There needs to be a default value defined by the standard, so that equipment have the same value leaving the factory

2.      This value can be over written based on local policy

3.      Should have an extensibility bit in order to and more values in the future

 

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay
Sent: Thursday, October 15, 2015 6:16 AM
To: ken carlberg <carlberg@g11.org.uk>; Steve Donovan <srdonovan@usdonovans.com>
Cc: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

 

From my side, some more discussion on Steve’s mail may be needed.

 

‘Should’ vs. ‘Must’:

One can say that ‘Should’ is not mandatory. But, in practice, this is a fairly strong statement, and often taken as required. So in this sense, the proposed Note is certainly helpful. But, since we allow operators to override the value, I don’t see the reason why we use ‘Should’. My suggestion is using ‘May’.

 

PRIORITY_14 priority:

Since operators can overwrite it, I was not too concerned about it. But if we want to put some value, why ‘14’? A value lower than 14 is suggested in order to allow more rooms for lower priorities.

 

Jay

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg
Sent: Wednesday, October 14, 2015 8:40 AM
To: Steve Donovan
Cc: dime@ietf.org
Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels)

 

with respect to the diff-serv example brought up below, some thing to add to that discussion is that it starts off with separate and distinct forwarding behavior whose marked packets provide segmentation of other IP traffic.  The availability of only 6 bits to play with (along with the headaches of transitive trust) also discouraged a line of thought to define end-to-end priority handling versus a per diff-serv domain treatment.  RFC-4594 did provide configuration guidelines, but that’s a different story.

 

So back to a couple of ideas to consider.

 

1) reserved space.  if we go back to the diff-serv model, the diff-serv working group agreed to set aside a set of values that was reserved for experimental use that could be re-assigned some time in the future.  I’m not suggesting that there should be space set side for experiments, but rather it may be prudent to set aside a reserved set of bits/values so that one doesn't need to define a new AVP if in the future there was a need to define added values beyond the 5 (plus some fudge factor) already mentioned on the list. 

 

2) sets of users.  previous work (e.g., rfc-4412, rfc-6710) recognized that there can be several sets of users/services that are distinct from each other and yet need to prioritize the traffic.  I bring this up because the draft already identifies two sets of users in sections 5.1 and 5.2 (note: I’m assuming that the latter is aimed at the general public and related to 911/112/999 type calls, which should probably be more specific in the draft).  And there is also the potential of Firstnet users in the US.

 

As a side note, the distinction and separation of general public and other prioritized users in public phone infrastructures is not exclusive to the US, so the group should not be concerned that this is a US centric effort.  There has been GTPS in the UK, as well as other systems in other countries.  The RFC is a bit dated, but feel free to go over rfc-4190 for added background.

 

and just to reiterate.  I’m not making recommendations in the above — just bringing up some food for thought.

 

-ken

 

 

On Oct 14, 2015, at 10:12 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 

Jay,

The current text is a SHOULD level requirement:

   When there is a mix of transactions specifying priority in request
   messages and transactions that do not have the priority specified,
   transactions that do not have a specified priority SHOULD be treated
   as having the PRIORITY_14 priority.

As such, operators can choose to either not implement a priority or define a different value for their network.

I propose adding the following note after this paragraph to further explain why it is a SHOULD and not a MUST:

      Note: There are scenarios where operators might want to 
      specify a different default value for transactions that do not
      have an explicit priority.  In this case, the operator defined
      local policy would override the use of PRIORITY_14 as
      the default priority.

This leaves the ability for there to be deterministic behavior in Diameter networks that require a default to be defined and are happy with the specified default.  It also gives operators the ability to define a different behavior, most likely with some priority handling/mapping at the edge of the network.

Does this address your concerns?

Regards,

Steve

On 10/14/15 2:59 AM, Lee, Jay wrote:

Regarding the issue of whether we need to specify a default value or not, there are pros and cons.

 

If we specify a value for the default case, we can see the benefits in scenarios between different operator networks, but we take away important options on what operators can do with priority values. On the other hand, if we do not specify the default value, operators may have more options, but there is a question of what to do for this inter-PLMN cases when the networks may use different default values.

 

In practice, this issue can be addressed at the edge of the network, where Diameter edge agent (DEA) can perform some priority mapping based on bilateral roaming agreement (or SLA (service level agreement)) and other means to insure the proper handling. One may argue that this is not as good as the ‘deterministic’ case, but operator should be able handle this in a reasonable way. We are fully aware of the fact that, in case of this ‘non-deterministic’ case, the default value can differ from one operator network to another, and it becomes difficult to guarantee the intended priority handling. Despite this, we still prefer giving options to operators by not specifying the default value.

 

What we are saying here, however, is not anything new. This is the typical way of handling priority levels. If anything, specifying the default value would be something new. As already mentioned in CT discussion, there is a good example of this – Internet QoS, more specifically DiffServ.

 

In order to guarantee end-to-end QoS for a specific service, IETF could have specified a value (DiffServ codepoint) for the specific service to have predetermined handling of the traffic, but IETF did not. Instead, DiffServ simply provided a framework for operators to have its own  classification and differentiated treatment of the services. To guarantee end-to-end QoS across different networks, then, operators need to do packet inspection, (re)classification, QoS mapping, use of SLA and possibly others at the edge of network (edge router). Therefore, in the DiffServ architecture, intelligence was pushed to the edge of the network. While the end results may not be guaranteed as well as in the case of predetermined handling, it was still a preferred way to give flexibility to operators. My point is that we went through all these troubles to give options of priority handling to operators.

 

By the way, if we are thinking of possibility of specifying the default value, are we assuming that all operators are interested in this feature (default value in the middle, and high and low priorities at other ends)? Aren’t there other operators who are not interested in this feature? I know that at least there is one – Verizon. We have no interest in this feature, and no plan for implementing it. We are OK, if other operators are interested in this feature, and the default value is NOT specified. But we are certainly not happy if DIME is trying to impose this on us.

 

Jay

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Tuesday, October 13, 2015 10:55 AM
To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; dime@ietf.org; Pollini, Gregory P
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels

 

Assuming that we define a range of 3 values,

Assuming that 0 is the lowest priority and 2 the highest,

Assuming that an agent receives 4 messages at the same time while being in overload control:

·       1) ULR with Prio-0

·       2) ULR with Prio-1

·       3) ULR with Prio-2

·       4) ULR with no priority AVP

 

Assuming that the default is locally defined as proposed below,

 

How do you know that the ULR with priority 2 will be handled with a higher priority  than the request without priority indication?

And what about ULR message with priority 1 with two levels of highest priority e.g. emergency/Important and government/very important?

 

Sorry if the answer is obvious but I fail to understand.

 

Lionel

 

 

                                          

De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] 
Envoyé : samedi 3 octobre 2015 01:21
À : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; dime@ietf.org; Pollini, Gregory P
Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels

 

Hello all,

 

Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined.

 

Having 15 rather than 16 would be useful from an interworking point of view on Diameter interfaces connecting to the EPS.  

 

Also, my understanding has been that the default value is per local policy. 

 

My 2 cents....

Viqar 

From: DiME [dime-bounces@ietf.org] on behalf of lionel.morand@orange.com [lionel.morand@orange.com]
Sent: Thursday, October 01, 2015 3:36 AM
To: Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels

Hi,

 

I think that the case "no Priority indication in request" is the default situation today.

So if we agree that it should be possible to explicitly indicate a request with a lower priority, we should divide the range of priority values in three sub-ranges: [lower priorities][no priority indication][higher priorities], e.g. with 17 values: [0-7][8][9-16].

If any operator can freely fix the default value, there would be no way to ensure the sender that a request with a specific priority value (e.g. 6) will be handled with a lower or higher priority than a request with no priority indication.

 

Therefore, for a deterministic handling mechanism, I think that it is then more relevant to define a standard value for the default value.

 

Regards,

 

Lionel

 

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn
Envoyé : mercredi 30 septembre 2015 22:53
À : DOLLY, MARTIN C
Cc : DiME; dime@ietf.org
Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels

 

Same here.  The "default priority" should be a matter of local policy. 

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. 



From:        "DOLLY, MARTIN C" <md3135@att.com> 
To:        Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org> 
Date:        09/30/2015 04:40 PM 
Subject:        Re: [Dime] [dime] #92 (drmp): Range of priority levels 
Sent by:        "DiME" <dime-bounces@ietf.org>




Me as well 
  
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Wednesday, September 30, 2015 4:38 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels 
  
I'm okay with Jay's proposal on not specifying a default value.

Steve 
On 9/30/15 3:27 PM, Lee, Jay wrote: 
Hi Steve and all, 
  
For the first proposal, as I indicated, I support increasing the number of priority levels up to 16. 
  
I am also fine with the second proposal. My question is: do we need to mandate this feature, as individual operators have different situations? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that when there is no DRMP AVP, this correspond to ‘normal traffic’ without a particular high or low priority. Then each operator can map this default to a value (e.g., 8 or something else) that they feel appropriate. 
  
Thanks, 
  
Jay 



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

_________________________________________________________________________________________________________________________
 
Ce message et
ses pieces jointes peuvent contenir des informations confidentielles ou
privilegiees et ne doivent donc
pas etre
diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur
et le detruire ainsi que les pieces jointes. Les messages electroniques
etant susceptibles d'alteration,
Orange decline
toute responsabilite si ce message a ete altere, deforme ou falsifie.
Merci.
 
This message
and its attachments may contain confidential or privileged information that
may be protected by law;
they should
not be distributed, used or copied without
authorisation.
If you have
received this email in error, please notify the sender and delete this
message and its attachments.
As emails may
be altered, Orange is not liable for messages that have been modified,
changed or falsified.
Thank
you.
_________________________________________________________________________________________________________________________
 
Ce message et
ses pieces jointes peuvent contenir des informations confidentielles ou
privilegiees et ne doivent donc
pas etre
diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur
et le detruire ainsi que les pieces jointes. Les messages electroniques
etant susceptibles d'alteration,
Orange decline
toute responsabilite si ce message a ete altere, deforme ou falsifie.
Merci.
 
This message
and its attachments may contain confidential or privileged information that
may be protected by law;
they should
not be distributed, used or copied without
authorisation.
If you have
received this email in error, please notify the sender and delete this
message and its attachments.
As emails may
be altered, Orange is not liable for messages that have been modified,
changed or falsified.
Thank
you.

 

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


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

 

 

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

 

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

------------150b00edfc36848277f42e0bff0-- From nobody Thu Oct 29 12:59:23 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8421A908F for ; Thu, 29 Oct 2015 12:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLRYFVIXNX3I for ; Thu, 29 Oct 2015 12:59:12 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2716E1A908C for ; Thu, 29 Oct 2015 12:59:12 -0700 (PDT) Received: from thumper.appcomsci.com (localhost [127.0.0.1]) by thumper.appcomsci.com (Postfix) with ESMTP id 19FEA60C20A; Thu, 29 Oct 2015 15:59:19 -0400 (EDT) X-Virus-Scanned: by SpamTitan at appcomsci.com Received: from thumper.appcomsci.com (localhost [127.0.0.1]) by thumper.appcomsci.com (Postfix) with ESMTP id 779C960C1FA; Thu, 29 Oct 2015 15:59:18 -0400 (EDT) Received: from bambi.appcomsci.com (bambi.appcomsci.com [192.4.5.54]) by thumper.appcomsci.com (Postfix) with ESMTPS id 6255960C1D6; Thu, 29 Oct 2015 15:59:18 -0400 (EDT) Received: from brg-ats-exhb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.112]) by bambi.appcomsci.com (8.14.4/8.13.4) with ESMTP id t9TJx9et031712; Thu, 29 Oct 2015 15:59:10 -0400 Received: from RRC-ATS-EXMB2.ats.atsinnovate.com ([2002:c004:56a::c004:56a]) by brg-ats-exhb1.ats.atsinnovate.com ([2002:c004:570::c004:570]) with mapi; Thu, 29 Oct 2015 15:59:09 -0400 From: "Shaikh, Viqar A" To: Steve Donovan , "Lee, Jay" , "dime@ietf.org" Thread-Topic: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) Thread-Index: AQHRBzKFz39No2HXxkqoFRsdQWEXvZ5sOcGAgAtoZjCAAZc3ZYAAEqiAgASJrNCAA3T5QIAAYjIAgAFJtOw= Date: Thu, 29 Oct 2015 19:59:07 +0000 Message-ID: <341B32B15901F94185C9E67CAAE133030E26E0FE@rrc-ats-exmb2.ats.atsinnovate.com> References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> <20151014075941.062E21B2C1F@ietfa.amsl.com> <561E62C9.20500@usdonovans.com> <1431d0b2-5ae7-426e-b5ff-42b23fecbee5@CASAC1EXH002.uswin.ad.vzwcorp.com> <20151015101558.111761ACD5C@ietfa.amsl.com> <3e7a25c8-5eea-49a5-9905-3009c4dc45b8@NYORA1HUB001.uswin.ad.vzwcorp.com> <20151023055927.9223C1B3292@ietfa.amsl.com> <20151023165728.7D0E01A874F@ietfa.amsl.com> <20151028183455.88E9E1A899A@ietfa.amsl.com>, <150b00ed6f0.277f.0301301ad371d4c21d5a2092e0e442f2@usdonovans.com> In-Reply-To: <150b00ed6f0.277f.0301301ad371d4c21d5a2092e0e442f2@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_341B32B15901F94185C9E67CAAE133030E26E0FErrcatsexmb2atsa_" MIME-Version: 1.0 Archived-At: Cc: "Singh, Ray P" , "Lukacs, Donald R" , "Pollini, Gregory P" Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 29 Oct 2015 19:59:22 -0000 --_000_341B32B15901F94185C9E67CAAE133030E26E0FErrcatsexmb2atsa_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello all, My 2 cents: Greater than 5 values for DRMP AVP is justified and it appears there is agr= eement for 16. However, note that the 3GPP priority, e.g., Priority-Level = AVP (ARP AVP) in TS 29.212 takes 15 values, value 1 the highest, 15 the low= est, and value 0 not defined. Having 15 rather than 16 for DRMP AVP would b= e useful from an interworking point of view on Diameter interfaces connecti= ng to the EPS. Regarding the default value - it is based on operator policy and can be ove= rwritten by an operator. Therefore, we support use of "may" and not "shoul= d". We feel that 15 or 16 values should suffice and there is no need to define = an extension bit. However, I am ok if there is consensus to do so. We feel there is no need to specify a default as it is per local policy and= can be overwritten. But, if there is consensus to do so, we suggest value= 10 or 11 with a note that it can be overwritten based on operator policy. Thoughts? Thanks, Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf of Steve Donovan [srdonovan@us= donovans.com] Sent: Wednesday, October 28, 2015 4:06 PM To: Lee, Jay; dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Ten is acceptable to me. Steve On October 28, 2015 1:36:00 PM "Lee, Jay" wro= te: I also think that we agree on all different points for the finalization, ex= cept one point: the value for the default case. Use of the default case as = discussed here is rather in the future than in the present for us, so I do = not have strong opinion, especially when the default value can be overwritt= en. Looking at this objectively and also for the sake of progress, however, it = would be prudent to have more than one lower priority cases. In the near fu= ture, we may identify additional use cases for lower priority case. Even wi= th one use case identified, this does not necessarily mean one priority lev= el per use case. One use case may require multiple lower priority levels, d= epending on applications. Any value from 9 to 12 seems reasonable to me. But, without all use cases i= dentified at the present time, I propose 10 (JJacques=92 proposal) or 11. Thanks, Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: Monday, October 26, 2015 8:11 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Hi Please see my comments also in line. I think we are close to finalise our c= hoice on the different points of this thread Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de Lee, Jay Envoy=E9 : vendredi 23 octobre 2015 18:57 =C0 : dime@ietf.org Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp)= : Range of priority levels) Please see my comments inline. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Friday, October 23, 2015 8:02 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Please see my comments inline. Steve On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote: See inline From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay Sent: Friday, October 23, 2015 1:59 AM To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) ; dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Some further comments from my side: */ If we need to assign (but not specify) a value to the default case, we n= eed to make it clear that this value can be overwritten by operators, and t= he value is for some use cases like e.g., equipment having the same value w= hen leaving the factory, so that there would be no misunderstanding. mcd- ok SRD> I think the current proposed text makes this clear. [JL] Agree that the current text is OK especially when we use =91May=92 in = place of =91Should=92 [JJ] OK . */ Since we agree that the default value is per local policy, =91May=92 is = preferred to =91Should=92 in order not to cause confusion. mcd-ok SRD> I'm okay with making this a MAY. [JL] Agreed [JJ] Also in favor of a MAY */ For assignment of the default value, I am quite open. But any value betw= een 9 =96 12 seems reasonable to me. mcd- value should allow for assigning lower values, though a carrier can as= sign what they want in their network, there needs to be a common meaning at= the interconnection point SRD> I'm open to any value we decide on. If there are real use cases that = require pushing the default value more to the middle then we should do so. = At this point I've heard one use case for the default being something othe= r then the lowest value, thus the proposal to use priority_14 as the defaul= t. [JJ] Regarding use cases, there may be - The case where for =93normal=94 users, an application use the de= fault value for most of its requests except some which have a lower priorit= y - the case where besides =93normal=94 user (and high priority user= s), some users have lower priorities, e.g. Some Machine type Communications= (MTC) devices. So potentially more than one low priority level would be needed. We also have chosen a rather large range of values (16) , allowing flexibil= ity for an operator when they define the number of priorities they want , l= eaving possibility to future additions. If PRIORITY _14 is the default, it = leaves only one lower priority and an operator cannot add a second one ex= cept by choosing a default value other than the 14 value. Then as, in practice, we may expect a range of low priority smaller than t= he range of high priority values, this is why the default value was propose= d to be in the range 9-12 . Then I proposed 10 so to do a proposal but I a= m open on another value. = &= ! nbsp;&nbs p; */ Current proposal of 16 values may be enough now, but I am fine with hav= ing an extensibility bit to be future proof. mcd-ok SRD> I don't see a compelling argument to move beyond 16. In addition, it isn't clear to me that there is value in defining an extens= ibility mechanism beyond what is already supported by Diameter. Doing so w= ould add significant complexity to the DRMP mechanism for something that, i= n my view, has a low probability of being used. I propose that we not allow extending the DRMP AVP. Rather we require that= any extension require a new AVP. We can then leave it to the document tha= t proposes the extension to deal with determining whether send the DRMP AVP= or the newly defined DRMPv2 AVP. [JL] When we proposed that the range be extended to 16, we thought that =91= 16=92 was large enough and future proof. I am okay with having an extensibility bit, if other companies want it. Tha= t said, I agree that it has a low probability of being used and added compl= exity. [JJ] JJ I also agree that with 16 values , the offered range is large enoug= h in practice. This point is only to check if it would be easy to do an ext= ension, if we have this requirement in the future. I agree with Steve that= for an extensibility, it will require a new AVP in a new document rather t= han to define a set of reserved values in the DRMP AVP. A point is that it= will require an additional parsing effort for a node to look for this seco= nd AVP even if it is not present most of the time. */ I am not sure of alternative encoding method (say, +9 to -9 per JJacques= =92 proposal) compared to the current enumerated type of DRMP. It offers a = logical way of assigning a value 0 to the default case. But it offers less = flexibility to operators, since the default value may not be easily moved t= o have more higher/lower priority values. Also, we are used to the enumerat= ed type of DRMP and just want to have extension from 5 to 16, but this may= require more deviation from the current design and thinking. For this, I w= ould like to see more on qualitative pros/cons, but, given its little benef= it, I am reluctant to accept this alternative. SRD> I agree that I don't see value in the +9 to -9 proposal. [JL] Agreed [J] I presented this second approach so to review the possible alternativ= es as we usually do before selecting the solution, this alternative being a= lready used in a recent RFC. That being said, I am fine with the enumerat= ed DRMP AVP. Best regards JJacques From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: Thursday, October 22, 2015 9:39 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Hi 1. PRIORITY_14 as default priority value only allows one level of lowe= r priority (PRIORITY_15) than the default one; this seems not enough. As = use cases, we may have some Machine type Communication (LTC) devices that = may have lower priorities that normal communications without priority. Eve= n within a Diameter application, some commands may have a lower priority as= having a secundary importance. Then which default value ? - it could be PRIORITY_8 in the middle, or if we prefer to have a l= arger range for higher priorities than for lower priorities, the default = value could be e.g. PRIORITY_10, giving 9 higher priorities and 5 lower p= riorities than the default one. I would have a preference for this value PR= IORITY_10. 2. About extensibility, the current range of 16 values is already larg= e, but we can have a reserved value to indicate a further extension. With = an enumerated AVP, there is no possibility to add new values. 3. I also had a look to some other IETF RFCs addressing priorities tha= t Ken mentioned, so to see if we can benefit from these approaches although= done for different contexts. - in RFC 4412 (Resource-Priority Header in SIP), wps and ets namespa= ces have a range of 5 values (0 to 4) with 0 as the highest priority . But= I have not found some indication (I may have missed it) about the default= priority (I mean a SIP request without Resource-Priority Header compared= to a SIP request with the Header). Implicitly, I would assume a SIP reque= st without Resource-Priority Header corresponds to the lowest priority. = DRMP has a similar approach but with a larger range and also lower priorit= ies. - RFC 6710 (priority for SMTP), uses another encoding of the prior= ity values with an integer between -9 and +9. Lower priorities are negativ= e an higher priority being positive. When a value increases, it means a hig= her priority, so the opposite to DRMP, wps or ets. But the value 0 is her= e naturally the default value. So this is an encoding alternative to the = Enumerated type of the DRMP AVP which avoids the question of the default va= lue. Note: RFC 6710 also defines some Priority Assignment Policies using a subs= et of the range. RFC 6710 has also this guideline : SMTP servers compliant with this specification are not required to support all 19 distinct priority levels (i.e., to treat each priority value as a separate priority), =85. That is, an implementation that only supports N priority levels (where N < 19) will internally round up a syntactically valid priority value that isn't supported to the next higher supported number (or to the highest supported priority, if the value is higher than any supported pr= iority). - This raises the question to have this type of guideline if consid= ered useful. So to have your feedback Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C Envoy=E9 : jeudi 15 octobre 2015 12:33 =C0 : Lee, Jay; ken carlberg; Steve Donovan Cc : dime@ietf.org Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp)= : Range of priority levels) A couple thoughts: 1. There needs to be a default value defined by the standard, so that = equipment have the same value leaving the factory 2. This value can be over written based on local policy 3. Should have an extensibility bit in order to and more values in the= future From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay Sent: Thursday, October 15, 2015 6:16 AM To: ken carlberg >; Steve D= onovan > Cc: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) >From my side, some more discussion on Steve=92s mail may be needed. =91Should=92 vs. =91Must=92: One can say that =91Should=92 is not mandatory. But, in practice, this is a= fairly strong statement, and often taken as required. So in this sense, th= e proposed Note is certainly helpful. But, since we allow operators to over= ride the value, I don=92t see the reason why we use =91Should=92. My sugges= tion is using =91May=92. PRIORITY_14 priority: Since operators can overwrite it, I was not too concerned about it. But if = we want to put some value, why =9114=92? A value lower than 14 is suggested= in order to allow more rooms for lower priorities. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg Sent: Wednesday, October 14, 2015 8:40 AM To: Steve Donovan Cc: dime@ietf.org Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): R= ange of priority levels) with respect to the diff-serv example brought up below, some thing to add t= o that discussion is that it starts off with separate and distinct forwardi= ng behavior whose marked packets provide segmentation of other IP traffic. = The availability of only 6 bits to play with (along with the headaches of = transitive trust) also discouraged a line of thought to define end-to-end p= riority handling versus a per diff-serv domain treatment. RFC-4594 did pro= vide configuration guidelines, but that=92s a different story. So back to a couple of ideas to consider. 1) reserved space. if we go back to the diff-serv model, the diff-serv wor= king group agreed to set aside a set of values that was reserved for experi= mental use that could be re-assigned some time in the future. I=92m not su= ggesting that there should be space set side for experiments, but rather it= may be prudent to set aside a reserved set of bits/values so that one does= n't need to define a new AVP if in the future there was a need to define ad= ded values beyond the 5 (plus some fudge factor) already mentioned on the l= ist. 2) sets of users. previous work (e.g., rfc-4412, rfc-6710) recognized that= there can be several sets of users/services that are distinct from each ot= her and yet need to prioritize the traffic. I bring this up because the dr= aft already identifies two sets of users in sections 5.1 and 5.2 (note: I= =92m assuming that the latter is aimed at the general public and related to= 911/112/999 type calls, which should probably be more specific in the draf= t). And there is also the potential of Firstnet users in the US. As a side note, the distinction and separation of general public and other = prioritized users in public phone infrastructures is not exclusive to the U= S, so the group should not be concerned that this is a US centric effort. = There has been GTPS in the UK, as well as other systems in other countries.= The RFC is a bit dated, but feel free to go over rfc-4190 for added backg= round. and just to reiterate. I=92m not making recommendations in the above =97 j= ust bringing up some food for thought. -ken On Oct 14, 2015, at 10:12 AM, Steve Donovan > wrote: Jay, The current text is a SHOULD level requirement: When there is a mix of transactions specifying priority in request messages and transactions that do not have the priority specified, transactions that do not have a specified priority SHOULD be treated as having the PRIORITY_14 priority. As such, operators can choose to either not implement a priority or define = a different value for their network. I propose adding the following note after this paragraph to further explain= why it is a SHOULD and not a MUST: Note: There are scenarios where operators might want to specify a different default value for transactions that do not have an explicit priority. In this case, the operator defined local policy would override the use of PRIORITY_14 as the default priority. This leaves the ability for there to be deterministic behavior in Diameter = networks that require a default to be defined and are happy with the specif= ied default. It also gives operators the ability to define a different beh= avior, most likely with some priority handling/mapping at the edge of the n= etwork. Does this address your concerns? Regards, Steve On 10/14/15 2:59 AM, Lee, Jay wrote: Regarding the issue of whether we need to specify a default value or not, t= here are pros and cons. If we specify a value for the default case, we can see the benefits in scen= arios between different operator networks, but we take away important optio= ns on what operators can do with priority values. On the other hand, if we = do not specify the default value, operators may have more options, but ther= e is a question of what to do for this inter-PLMN cases when the networks m= ay use different default values. In practice, this issue can be addressed at the edge of the network, where = Diameter edge agent (DEA) can perform some priority mapping based on bilate= ral roaming agreement (or SLA (service level agreement)) and other means to= insure the proper handling. One may argue that this is not as good as the = =91deterministic=92 case, but operator should be able handle this in a reas= onable way. We are fully aware of the fact that, in case of this =91non-det= erministic=92 case, the default value can differ from one operator network = to another, and it becomes difficult to guarantee the intended priority han= dling. Despite this, we still prefer giving options to operators by not spe= cifying the default value. What we are saying here, however, is not anything new. This is the typical = way of handling priority levels. If anything, specifying the default value = would be something new. As already mentioned in CT discussion, there is a g= ood example of this =96 Internet QoS, more specifically DiffServ. In order to guarantee end-to-end QoS for a specific service, IETF could hav= e specified a value (DiffServ codepoint) for the specific service to have p= redetermined handling of the traffic, but IETF did not. Instead, DiffServ s= imply provided a framework for operators to have its own classification an= d differentiated treatment of the services. To guarantee end-to-end QoS acr= oss different networks, then, operators need to do packet inspection, (re)c= lassification, QoS mapping, use of SLA and possibly others at the edge of n= etwork (edge router). Therefore, in the DiffServ architecture, intelligence= was pushed to the edge of the network. While the end results may not be gu= aranteed as well as in the case of predetermined handling, it was still a p= referred way to give flexibility to operators. My point is that we went thr= ough all these troubles to give options of priority handling to operators. By the way, if we are thinking of possibility of specifying the default val= ue, are we assuming that all operators are interested in this feature (defa= ult value in the middle, and high and low priorities at other ends)? Aren= =92t there other operators who are not interested in this feature? I know t= hat at least there is one =96 Verizon. We have no interest in this feature,= and no plan for implementing it. We are OK, if other operators are interes= ted in this feature, and the default value is NOT specified. But we are cer= tainly not happy if DIME is trying to impose this on us. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, October 13, 2015 10:55 AM To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org; Pollini, Gregory P Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Assuming that we define a range of 3 values, Assuming that 0 is the lowest priority and 2 the highest, Assuming that an agent receives 4 messages at the same time while being in = overload control: =95 1) ULR with Prio-0 =95 2) ULR with Prio-1 =95 3) ULR with Prio-2 =95 4) ULR with no priority AVP Assuming that the default is locally defined as proposed below, How do you know that the ULR with priority 2 will be handled with a higher = priority than the request without priority indication? And what about ULR message with priority 1 with two levels of highest prior= ity e.g. emergency/Important and government/very important? Sorry if the answer is obvious but I fail to understand. Lionel De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] Envoy=E9 : samedi 3 octobre 2015 01:21 =C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C Cc : DiME; dime@ietf.org; Pollini, Gregory P Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels Hello all, Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.21= 2 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defi= ned. Having 15 rather than 16 would be useful from an interworking point of view= on Diameter interfaces connecting to the EPS. Also, my understanding has been that the default value is per local policy. My 2 cents.... Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf = of lionel.morand@orange.com [lionel.morand= @orange.com] Sent: Thursday, October 01, 2015 3:36 AM To: Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Hi, I think that the case "no Priority indication in request" is the default si= tuation today. So if we agree that it should be possible to explicitly indicate a request = with a lower priority, we should divide the range of priority values in thr= ee sub-ranges: [lower priorities][no priority indication][higher priorities= ], e.g. with 17 values: [0-7][8][9-16]. If any operator can freely fix the default value, there would be no way to = ensure the sender that a request with a specific priority value (e.g. 6) wi= ll be handled with a lower or higher priority than a request with no priori= ty indication. Therefore, for a deterministic handling mechanism, I think that it is then = more relevant to define a standard value for the default value. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn Envoy=E9 : mercredi 30 septembre 2015 22:53 =C0 : DOLLY, MARTIN C Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels Same here. The "default priority" should be a matter of local policy. Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "DOLLY, MARTIN C" > To: Steve Donovan >, "dime@ietf.org" > Date: 09/30/2015 04:40 PM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" = > ________________________________ Me as well From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, September 30, 2015 4:38 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels I'm okay with Jay's proposal on not specifying a default value. Steve On 9/30/15 3:27 PM, Lee, Jay wrote: Hi Steve and all, For the first proposal, as I indicated, I support increasing the number of = priority levels up to 16. I am also fine with the second proposal. My question is: do we need to mand= ate this feature, as individual operators have different situations? Perhap= s some flexibility should be allowed? Instead of mandating it, we can inclu= de the statement that when there is no DRMP AVP, this correspond to =91norm= al traffic=92 without a particular high or low priority. Then each operator= can map this default to a value (e.g., 8 or something else) that they feel= appropriate. Thanks, Jay _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_341B32B15901F94185C9E67CAAE133030E26E0FErrcatsexmb2atsa_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello all,

 

My 2 cents:

 

Greater than 5 values f= or DRMP AVP is justified and it appears there is agreement for 16.&nbs= p; However, note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 takes 15 values, value 1 the highest, 15 the l= owest, and value 0 not defined. Having 15 rather than 16 for DRMP AVP would= be useful from an interworking point of view on Diameter interfaces connec= ting to the EPS.

 

Regarding the default v= alue - it is based on operator policy and can be overwritten by an ope= rator.  Therefore, we support use of "may" and not "sho= uld". 

 

We feel that 15 or 16 v= alues should suffice and there is no need to define an extension bit.&= nbsp; However, I am ok if there is consensus to do so.

 

We feel there is no&nbs= p;need to specify a default as it is per local policy and can be overwritte= n.  But, if there is consensus to do so, we suggest value 10 or 11 with a note that it can be overwritten based on operator policy.

 

Thoughts?=

 

Thanks,

Viqar

 

From: DiME [dime-bounces@ietf.org] on beha= lf of Steve Donovan [srdonovan@usdonovans.com]
Sent: Wednesday, October 28, 2015 4:06 PM
To: Lee, Jay; dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

Ten is acceptable to me.

Steve

On October 28, 2015 1:36:00 PM "Lee, Jay" <Jay.Lee@VerizonWire= less.com> wrote:

I also think that we a= gree on all different points for the finalization, except one point: the va= lue for the default case. Use of the default case as discussed here is rather in the future than in the present for us, so I do not have = strong opinion, especially when the default value can be overwritten.

 

Looking at this object= ively and also for the sake of progress, however, it would be prudent to ha= ve more than one lower priority cases. In the near future, we may identify additional use cases for lower priority case. Even with on= e use case identified, this does not necessarily mean one priority level pe= r use case. One use case may require multiple lower priority levels, depend= ing on applications.

 

Any value from 9 to 12= seems reasonable to me. But, without all use cases identified at the prese= nt time, I propose 10 (JJacques=92 proposal) or 11.

 

Thanks,

 

Jay

 

From:<= span style=3D"FONT-SIZE: 10pt; FONT-FAMILY: "Tahoma","sans-s= erif"; COLOR: windowtext"> DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Monday, October 26, 2015 8:11 AM
To: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Hi

 

Please see my comments= also in line. I think we are close to finalise our choice on the different= points  of this thread

 

Best regards

 

JJacques

 

De :<= /b> DiME [mailto:dime-bounces@ietf.org] De la part de Lee, Jay
Envoy=E9 : vendredi 23 octobre 2015 18:57
=C0 : dime@ietf= .org
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime= ] #92 (drmp): Range of priority levels)

 

Please see my comments= inline.

 

From:<= span style=3D"FONT-SIZE: 10pt; FONT-FAMILY: "Tahoma","sans-s= erif"; COLOR: windowtext"> DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Friday, October 23, 2015 8:02 AM
To: dime@ietf.org=
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Please see my comments= inline.

Steve

On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote:

See inline

 

From: DiME= [mailto:dime-bo= unces@ietf.org] On Behalf Of Lee, Jay
Sent: Friday, October 23, 2015 1:59 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) <jean-jacques.trottin@alcatel-lucent.com>; dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Some further comments = from my side:

 

*/ If we need to assig= n (but not specify) a value to the default case, we need to make it clear t= hat this value can be overwritten by operators, and the value is for some use cases like e.g., equipment having the same value whe= n leaving the factory, so that there would be no misunderstanding.

mcd- ok

SRD> I think the current proposed text makes this= clear.
[JL] Agree that the current text is OK espec= ially when we use =91May=92 in place of =91Should=92

[JJ] OK

.

 

*/ Since we agree that the default value is per local policy, =91May= =92 is preferred to =91Should=92 in order not to cause confusion.

mcd-ok

SRD> I'm okay with making this a MAY.

[JL]  Agreed

[JJ] Also in favor of = a MAY

 

*/ For assignment of the default value, I am quite open. But any val= ue between 9 =96 12 seems reasonable to me.

mcd- value should allo= w for assigning lower values, though a carrier can assign what they want in= their network, there needs to be a common meaning at the interconnection point

SRD> I'm open to any value we decide on.  If= there are real use cases that require pushing the default value more to th= e middle then we should do so.  At this point I've heard one use case = for the default being something other then the lowest value, thus the proposal to use priority_14 as the default.  <= /p>

[JJ] Regarding use cas= es, there may be

-The case where for =93no= rmal=94 users, an application use the default value for most of its request= s except some which have a lower priority

-the case where besides = =93normal=94 user (and high priority users), some users have lower prioriti= es, e.g. Some Machine type Communications (MTC) devices.

So potentially more th= an one low priority level would be needed.

We also have chosen a = rather large range of values (16) , allowing flexibility for an operator wh= en they define the number of priorities they want , leaving possibility to future additions. If PRIORITY _14 is the default, it leaves= only one lower priority and an operator  cannot add a second one &nbs= p;except by choosing  a default value other than the 14  value.

Then as, in practice, = we may expect a range of low priority smaller than  the range of high = priority values, this is why the default value was proposed to be in the range 9-12  . Then I proposed 10 so to do a proposal but I = am open on another value.

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       &! nbsp;&nbs p;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =           

*/  Current proposal of 16 values may be enough now, but I am f= ine with having an extensibility bit to be future proof.

mcd-ok

SRD> I don't see a compelling argument to move be= yond 16. 
In addition, it isn't clear to me that there is value in defining an extens= ibility mechanism beyond what is already supported by Diameter.  Doing= so would add significant complexity to the DRMP mechanism for something th= at, in my view, has a low probability of being used.

I propose that we not allow extending the DRMP AVP.  Rather we require= that any extension require a new AVP.  We can then leave it to the do= cument that proposes the extension to deal with determining whether send th= e DRMP AVP or the newly defined DRMPv2 AVP. 
[JL] When we proposed that the range be exte= nded to 16, we thought that =9116=92 was large enough and future proof.

I am okay with having= an extensibility bit, if other companies want it. That said, I agree that = it has a low probability of being used and added complexity.

[JJ] JJ I also agree = that with 16 values , the offered range is large enough in practice. This p= oint is only to check if it would be easy to do an extension, if we have th= is requirement in the future.  I agree with Steve that for an extensibility, it will require a new AVP in a new d= ocument rather than to define a set of reserved values in the DRMP AVP. &nb= sp;A point is that it will require an additional parsing effort for a node = to look for this second AVP even if it is not present most of the time.  

 

*/ I am not sure of alternative encoding method (say, +9 to -9 p= er JJacques=92 proposal) compared to the current enumerated type of DRMP. It offers a logical way of assigning a value 0 to the default cas= e. But it offers less flexibility to operators, since the default value may= not be easily moved to have more higher/lower priority values. Also, we ar= e used to the enumerated type of DRMP and just want to have extension from 5 to 16,  but this may requ= ire more deviation from the current design and thinking. For this, I would = like to see more on qualitative pros/cons, but, given its little benefit, I= am reluctant to accept this alternative.

SRD> I agree that I don't see value in the +9= to -9 proposal.

[JL] Agreed

[J] I presented this s= econd  approach  so to review the possible alternatives as we usu= ally do before selecting the solution, this alternative being already used in a recent RFC.   That being said, I am fine with the enum= erated DRMP AVP.

 

Best regards

 

JJacques  =

 

From: DiME [= mailto:dime-boun= ces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Thursday, October 22, 2015 9:39 AM
To: dime@ietf.org=
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Hi

 

1.      PRIORITY_14 as default priority value = only allows one level of lower priority (PRIORITY_15)  than the defaul= t one; this seems not enough.  As use cases, we may have  some Machine type Communication (LTC) devices that may have lower priorities th= at normal communications without priority.  Even within a Diameter app= lication, some commands may have a lower priority as having a secundary imp= ortance.

 

Then which default  value ?

-&nbs= p;       it could be PRIORITY_8 in the middle, = or if we prefer to have a  larger range for higher priorities  th= an for lower priorities,  the default value could be  e.g. PRIORI= TY_10,  giving 9 higher priorities and 5 lower priorities than the default one. I = would have a preference for this value PRIORITY_10.

 

2.      About extensibility, the current range= of 16 values is already large, but we can have  a reserved value to i= ndicate a further extension. With  an enumerated AVP, there is no possibility to add new values. 

 

3.      I also had a look to some other IETF R= FCs addressing priorities that Ken mentioned, so to see if we can benefit f= rom these approaches although done for different contexts.

-&nbs= p;       in RFC 4412 (Resource-Priority Header = in SIP), wps and ets namespaces have a range of 5 values (0 to 4) with 0 as= the highest priority  . But I have not found some indication  (I may have missed it) about the default priority  (I mean a SIP requ= est without  Resource-Priority Header compared  to a SIP request = with the Header). Implicitly, I would assume a SIP request without  Re= source-Priority Header corresponds to  the lowest priority.  DRMP has a similar approach but with  a larger range and also l= ower priorities.

 

-&nbs= p;       RFC  6710 (priority for SMTP), &n= bsp;uses another encoding of the priority values with an integer between -9= and +9. Lower priorities  are negative an higher priority being positive. When a value increases, it means a higher priority, so the oppos= ite  to DRMP, wps or ets.  But the value 0 is here naturally the = default value. So this is an encoding alternative  to the  Enumer= ated type of the DRMP AVP which avoids the question of the default value.

Note: RFC  = ;6710 also defines some Priority Assignment Policies using a subset of the = range.

 

RFC 6710 has also this guideline :

   SMTP serv= ers compliant with this specification are not

   required to su= pport all 19 distinct priority levels (i.e., to treat

   each priority = value as a separate priority), =85.  That is, an

   implementation= that only supports N priority levels (where N < 19)

   will internall= y round up a syntactically valid priority value that

   isn't supporte= d to the next higher supported number (or to the

   highest suppor= ted priority, if the value is higher than any supported priority).

-&nbs= p;       This raises the question to have this = type of  guideline if considered useful.

 

So to have your feedba= ck

 

Best regards

 

JJacques

 

De : Di= ME [mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C
Envoy=E9 : jeudi 15 octobre 2015 12:33
=C0 : Lee, Jay; ken carlberg; Steve Donovan
Cc : dime@ietf.org
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime= ] #92 (drmp): Range of priority levels)

 

A couple thoughts:

1.&nb= sp;     There needs to be a default value defi= ned by the standard, so that equipment have the same value leaving the fact= ory

2.&nb= sp;     This value can be over written based o= n local policy

3.&nb= sp;     Should have an extensibility bit in or= der to and more values in the future

 

 

From: DiME= [mailto:dime-bo= unces@ietf.org] On Behalf Of Lee, Jay
Sent: Thursday, October 15, 2015 6:16 AM
To: ken carlberg <carlberg@g11.org.uk>; Steve Donovan <srdonovan@usdonovans.com&= gt;
Cc: dime@ietf.org=
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

From my side, some mor= e discussion on Steve=92s mail may be needed.

 

=91Should=92 vs. =91Mu= st=92:

One can say that =91Sh= ould=92 is not mandatory. But, in practice, this is a fairly strong stateme= nt, and often taken as required. So in this sense, the proposed Note is certainly helpful. But, since we allow operators to override the v= alue, I don=92t see the reason why we use =91Should=92. My suggestion is us= ing =91May=92.

 

PRIORITY_14 priority:<= /span>

Since operators can ov= erwrite it, I was not too concerned about it. But if we want to put some va= lue, why =9114=92? A value lower than 14 is suggested in order to allow more rooms for lower priorities.

 

Jay

 

From: DiME [= mailto:dime-boun= ces@ietf.org] On Behalf Of ken carlberg
Sent: Wednesday, October 14, 2015 8:40 AM
To: Steve Donovan
Cc: dime@ietf.org=
Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (d= rmp): Range of priority levels)

 

with respect to the diff-serv example brought up bel= ow, some thing to add to that discussion is that it starts off with separat= e and distinct forwarding behavior whose marked packets provide segmentatio= n of other IP traffic.  The availability of only 6 bits to play with (along with the headaches of transitive trust)= also discouraged a line of thought to define end-to-end priority handling = versus a per diff-serv domain treatment.  RFC-4594 did provide configu= ration guidelines, but that=92s a different story.

 

So back to a couple of ideas to consider.

 

1) reserved space.  if we go back to the diff-s= erv model, the diff-serv working group agreed to set aside a set of values = that was reserved for experimental use that could be re-assigned some time = in the future.  I=92m not suggesting that there should be space set side for experiments, but rather it may be prude= nt to set aside a reserved set of bits/values so that one doesn't need to d= efine a new AVP if in the future there was a need to define added values be= yond the 5 (plus some fudge factor) already mentioned on the list. 

 

2) sets of users.  previous work (e.g., rfc-441= 2, rfc-6710) recognized that there can be several sets of users/services th= at are distinct from each other and yet need to prioritize the traffic. &nb= sp;I bring this up because the draft already identifies two sets of users in sections 5.1 and 5.2 (note: I=92m assuming= that the latter is aimed at the general public and related to 911/112/999 = type calls, which should probably be more specific in the draft).  And= there is also the potential of Firstnet users in the US.

 

As a side note, the distinction and separation of ge= neral public and other prioritized users in public phone infrastructures is= not exclusive to the US, so the group should not be concerned that this is= a US centric effort.  There has been GTPS in the UK, as well as other systems in other countries.  The RFC= is a bit dated, but feel free to go over rfc-4190 for added background.

 

and just to reiterate.  I=92m not making recomm= endations in the above =97 just bringing up some food for thought.

 

-ken

 

 

On Oct 14, 2015, at 10:12 AM, Steve Donovan <srdonovan@usdonov= ans.com> wrote:

 

Jay,

The current text is a SHOULD level requir= ement:

   When there is a mix of trans= actions specifying priority in request
   messages and transactions th= at do not have the priority specified,
   transactions that do not hav= e a specified priority SHOULD be treated
   as having the PRIORITY_14 pr= iority.

As such, operators can choose to either n= ot implement a priority or define a different value for their network.

I propose adding the following note after= this paragraph to further explain why it is a SHOULD and not a MUST:

      Note: Ther= e are scenarios where operators might want to 
      specify a = different default value for transactions that do not
      have an ex= plicit priority.  In this case, the operator defined
      local poli= cy would override the use of PRIORITY_14 as
      the defaul= t priority.

This leaves the ability for there to be d= eterministic behavior in Diameter networks that require a default to be def= ined and are happy with the specified default.  It also gives operator= s the ability to define a different behavior, most likely with some priority handling/mapping at the edge of the network= .

Does this address your concerns?
Regards,

Steve

On 10/14/= 15 2:59 AM, Lee, Jay wrote:

Regarding the issue of whether we need to specify a default value or = not, there are pros and cons.

 

If we specify a value for the default case, we can see the benefits i= n scenarios between different operator networks, but we take away important options on what operators can do with priority values. On t= he other hand, if we do not specify the default value, operators may have m= ore options, but there is a question of what to do for this inter-PLMN case= s when the networks may use different default values.

 

In practice, this issue can be addressed at the edge of the network, = where Diameter edge agent (DEA) can perform some priority mapping based on bilateral roaming agreement (or SLA (service level agreem= ent)) and other means to insure the proper handling. One may argue that thi= s is not as good as the =91deterministic=92 case, but operator should be ab= le handle this in a reasonable way. We are fully aware of the fact that, in case of this =91non-deterministic= =92 case, the default value can differ from one operator network to another= , and it becomes difficult to guarantee the intended priority handling. Des= pite this, we still prefer giving options to operators by not specifying the default value.

 

What we are saying here, however, is not anything new. This is the ty= pical way of handling priority levels. If anything, specifying the default value would be something new. As already mentioned in CT discu= ssion, there is a good example of this =96 Internet QoS, more specifically = DiffServ.

 

In order to guarantee end-to-end QoS for a specific service, IETF cou= ld have specified a value (DiffServ codepoint) for the specific service to have predetermined handling of the traffic, but IETF did not. I= nstead, DiffServ simply provided a framework for operators to have its own =  classification and differentiated treatment of the services. To guara= ntee end-to-end QoS across different networks, then, operators need to do packet inspection, (re)classification= , QoS mapping, use of SLA and possibly others at the edge of network (edge = router). Therefore, in the DiffServ architecture, intelligence was pushed t= o the edge of the network. While the end results may not be guaranteed as well as in the case of predetermi= ned handling, it was still a preferred way to give flexibility to operators= . My point is that we went through all these troubles to give options of pr= iority handling to operators.

 

By the way, if we are thinking of possibility of specifying the defau= lt value, are we assuming that all operators are interested in this feature (default value in the middle, and high and low priorities = at other ends)? Aren=92t there other operators who are not interested in th= is feature? I know that at least there is one =96 Verizon. We have no inter= est in this feature, and no plan for implementing it. We are OK, if other operators are interested in this feat= ure, and the default value is NOT specified. But we are certainly not happy= if DIME is trying to impose this on us.

 

Jay

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Tuesday, Oct= ober 13, 2015 10:55 AM
To: Shaikh, Viqar = A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; dime@ietf.org; Pollini, Gregory P
Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 

Assuming that we define a range of 3 values,

Assuming that 0 is the lowest priority and 2 the highest,

Assuming that an agent receives 4 messages at the same time while bei= ng in overload control:

=B7    &n= bsp;  1) ULR with Prio-0

=B7    &n= bsp;  2) ULR with Prio-1

=B7    &n= bsp;  3) ULR with Prio-2

=B7    &n= bsp;  4) ULR with no priority AVP

 

Assuming that the default is locally defined as proposed below,

 

How do you know that the ULR with priority 2 will be handled with a h= igher priority  than the request without priority indication?

And what about ULR message with priority 1 with two levels of highest= priority e.g. emergency/Important and government/very important?

 

Sorry if the answer is obvious but I fail to understand.

 

Lionel

 

 

           &nb= sp;            =             &nb= sp;     

De = : Shaikh, Viqar A [mailto:vshaik= h@appcomsci.com] 
Envoy=E9 : sa= medi 3 octobre 2015 01:21
=C0 : MORAND = Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; dime@ietf.org; Pollini, Gregory P
Objet : RE: [= Dime] [dime] #92 (drmp): Range of priority levels

 

Hello all,<= /span>

&nbs= p;

Note t= hat the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 = ;takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined.

&nbs= p;

Having 15 r= ather than 16 would be useful from an interworking point of view on Diamete= r interfaces connecting to the EPS.  

&nbs= p;

Also, my un= derstanding has been that the default value is per local policy. =

&nbs= p;

= From: DiME [dime-bounces= @ietf.org] on behalf of lionel.morand@orange.com=  = [lionel.morand@orange.com]
Sent: Thursday, Oc= tober 01, 2015 3:36 AM
To: Janet P Gunn; = DOLLY, MARTIN C
Cc: DiME; dime@ietf.org
Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

Hi,

 

I think that the case "no Priority indication in request" i= s the default situation today.

So if we agree that it should be possible to explicitly indicate a re= quest with a lower priority, we should divide the range of priority values in three sub-ranges: [lower priorities][no priority indica= tion][higher priorities], e.g. with 17 values: [0-7][8][9-16].

If any operator can freely fix the default value, there would be no w= ay to ensure the sender that a request with a specific priority value (e.g. 6) will be handled with a lower or higher priority than a requ= est with no priority indication.

 

Therefore, for a deterministic handling mechanism, I think that it is= then more relevant to define a standard value for the default value.

 

Regards,

 

Lionel

 

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn
Envoy=E9 : me= rcredi 30 septembre 2015 22:53
=C0 : DOLLY, = MARTIN C
Cc : DiME; dime= @ietf.org
Objet : Re: [= Dime] [dime] #92 (drmp): Range of priority levels<= /span>

 

Same here. &= nbsp;The "default priority" should be a matter of local policy. 

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose. 



From:        "DOLLY, MARTIN C" <md3135@att.com> 
To:        Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org> 
Date:        09/30/2015 04:40 PM&nbs= p;
Subject:        Re: [Dime] [dime] #92 (drmp): Range of priority levels 
Sent by:        "DiME" <dime-bounces@ietf.org>



Me as well 
  
From: DiME [mailto:dime-bounces@= ietf.org] On Behalf Of Steve Dono= van
Sent: Wednesday, Sept= ember 30, 2015 4:38 PM
To: dime@ietf.org
Subject:&nbs= p;Re: [Dime] [dime] #92 (drmp): Range of priori= ty levels 
  
I'm okay with Jay's proposal on not specifying a default valu= e.

Steve 
On 9/30/15 3:27 PM, Lee, Jay wrote: 
Hi Steve and all, 
  
For the first proposal, as I indicated, I support increasing = the number of priority levels up to 16. 
  
I am also fine with the second proposal. My question is: do w= e need to mandate this feature, as individual operators have different situ= ations? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that when there is no DRMP A= VP, this correspond to =91normal traffic=92 without a particular high or lo= w priority. Then each operator can map this default to a value (e.g., 8 or = something else) that they feel appropriate. 
  
Thanks, 
  
Jay =



___________________________________________= ____ 
DiME mailing list 
DiME@ietf.org 
https://www.ietf.org/mailman/listinfo/dime 
 _________________________________= ______________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

___________________________________=
___________________________________________________________________________=
___________
 
Ce message et
ses pieces jointes peuvent contenir des informations confidentielles ou
privilegiees et ne doivent donc
pas etre
diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler

a l'expediteur
et le detruire ainsi que les pieces jointes. Les messages electroniques
etant susceptibles d'alteration,


Orange decline
toute responsabilite si ce message a ete altere, deforme ou falsifie.
 


This message
and its attachments may contain confidential or privileged information that
may be protected by law;


they should
not be distributed, used or copied without
authorisation.


If you have
received this email in error, please notify the sender and delete this
message and its attachments.


As emails may
be altered, Orange is not liable for messages that have been modified,
changed or falsified.


Thank
you.


___________________________________=
___________________________________________________________________________=
___________
 
Ce message et
ses pieces jointes peuvent contenir des informations confidentielles ou
privilegiees et ne doivent donc
pas etre
diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler

a l'expediteur
et le detruire ainsi que les pieces jointes. Les messages electroniques
etant susceptibles d'alteration,


Orange decline
toute responsabilite si ce message a ete altere, deforme ou falsifie.
 


This message
and its attachments may contain confidential or privileged information that
may be protected by law;


they should
not be distributed, used or copied without
authorisation.


If you have
received this email in error, please notify the sender and delete this
message and its attachments.


As emails may
be altered, Orange is not liable for messages that have been modified,
changed or falsified.


Thank
you.


 


_______________________________________________=



DiME mailing
list


DiME@ietf.org


https://www.ietf.or=
g/mailman/listinfo/dime


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

 

 

_______________________________________________
DiME mailing list
DiME@ietf.org

https://www.ietf.org/mailman/listinfo/dime


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

--_000_341B32B15901F94185C9E67CAAE133030E26E0FErrcatsexmb2atsa_-- From nobody Fri Oct 30 03:10:18 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F491B2AAC for ; Fri, 30 Oct 2015 03:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMAOGxPvo5ra for ; Fri, 30 Oct 2015 03:09:59 -0700 (PDT) Received: from eris.verizonwireless.com (eris.verizonwireless.com [137.188.99.119]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEBE1B2AAE for ; Fri, 30 Oct 2015 03:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizonwireless.com; i=@verizonwireless.com; q=dns/txt; s=prodmail; t=1446199798; x=1477735798; h=from:to:cc:subject:date:references:in-reply-to: mime-version; bh=wJv8cHS/uSdm085SDJv4vZSUmnZe9si37OJIoyKJaGs=; b=cSL5HrnSqpn703A2atP5wIM5dPgpe0oYVoWU8R2YNEkrW49ecOzKnUi1 Ry8dXr6uriDCUJz7OQmpBNbYGLAB1GVgsYNQaOLUEozQUUts7B+tU//5O PJiVr3TUsKnh+MZN+csP8W5fluQJdOhFl3j0iT/q83syEEPU6ijmmP+CA U=; X-Host: endeavour.tdc.vzwcorp.com Received: from casac1exh002.uswin.ad.vzwcorp.com ([10.11.218.44]) by eris.verizonwireless.com with ESMTP/TLS/AES128-SHA; 30 Oct 2015 06:09:56 -0400 Received: from CASAC1EXP009.uswin.ad.vzwcorp.com ([fe80::558c:d7cc:1a42:f4d6]) by CASAC1EXH002.uswin.ad.vzwcorp.com ([fe80::fc93:7690:c22f:38da%11]) with mapi id 14.03.0146.000; Fri, 30 Oct 2015 03:09:55 -0700 From: "Lee, Jay" To: "Shaikh, Viqar A" , Steve Donovan , "dime@ietf.org" Thread-Topic: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) Thread-Index: AQHRBzKIwn0SbO3rXUW/ebDof+lRcp5sOcGAgAtoZjCAAZc3ZYAAEqiAgASJrNCAA3T5QIAAYjIAgAFJtOyAANeskA== Date: Fri, 30 Oct 2015 10:09:54 +0000 References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> <20151014075941.062E21B2C1F@ietfa.amsl.com> <561E62C9.20500@usdonovans.com> <1431d0b2-5ae7-426e-b5ff-42b23fecbee5@CASAC1EXH002.uswin.ad.vzwcorp.com> <20151015101558.111761ACD5C@ietfa.amsl.com> <3e7a25c8-5eea-49a5-9905-3009c4dc45b8@NYORA1HUB001.uswin.ad.vzwcorp.com> <20151023055927.9223C1B3292@ietfa.amsl.com> <20151023165728.7D0E01A874F@ietfa.amsl.com> <20151028183455.88E9E1A899A@ietfa.amsl.com>, <150b00ed6f0.277f.0301301ad371d4c21d5a2092e0e442f2@usdonovans.com> <0c915451-c6b2-4644-80f8-f0cac6dff0b3@OHTWI1EXH001.uswin.ad.vzwcorp.com> In-Reply-To: <0c915451-c6b2-4644-80f8-f0cac6dff0b3@OHTWI1EXH001.uswin.ad.vzwcorp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.11.60.250] Content-Type: multipart/alternative; boundary="_000_C026C31E3CD6CA43953D6D95AB480480049979CASAC1EXP009uswin_" MIME-Version: 1.0 Message-Id: <20151030100958.4CEBE1B2AAE@ietfa.amsl.com> Archived-At: Cc: "Singh, Ray P" , "Lukacs, Donald R" , "Pollini, Gregory P" Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 30 Oct 2015 10:10:17 -0000 --_000_C026C31E3CD6CA43953D6D95AB480480049979CASAC1EXP009uswin_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please see my comments inline. Jay From: Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] Sent: Thursday, October 29, 2015 12:59 PM To: Steve Donovan; Lee, Jay; dime@ietf.org Cc: Singh, Ray P; Pollini, Gregory P; Lukacs, Donald R Subject: RE: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Hello all, My 2 cents: Greater than 5 values for DRMP AVP is justified and it appears there is agr= eement for 16. However, note that the 3GPP priority, e.g., Priority-Level = AVP (ARP AVP) in TS 29.212 takes 15 values, value 1 the highest, 15 the low= est, and value 0 not defined. Having 15 rather than 16 for DRMP AVP would b= e useful from an interworking point of view on Diameter interfaces connecti= ng to the EPS. [JL] I can see that, if the same number (i.e., 15) is used on both sides, t= here may be one-to-one mapping. This interworking/mapping should be done as= part of 3GPP DRMP WI, starting from next 3GPP CT4 meeting. But the mapping= can be both one-to-one and one-to-many (multiple). Even if the same number= is used, I don't know at the moment that we can exclude the possibility of= one-to-many mapping. So I am not sure that we need to have the same number= on both sides. Regarding the default value - it is based on operator policy and can be ove= rwritten by an operator. Therefore, we support use of "may" and not "shoul= d". [JL] Using 'May' is the consensus do far. We feel that 15 or 16 values should suffice and there is no need to define = an extension bit. However, I am ok if there is consensus to do so. [JL] The consensus so far is that it is better not to have the extension bi= t. We feel there is no need to specify a default as it is per local policy and= can be overwritten. But, if there is consensus to do so, we suggest value= 10 or 11 with a note that it can be overwritten based on operator policy. [JL] Initial assumption was that there is no need to specify or even assign= a default value, I believe. But then, there was a proposal to specify the = default value, making it mandatory. And then, there was also a proposal tha= t, even if the default value is not specified, we need to assign the defaul= t value that can be overwritten in order to have common understanding for s= ome reasons. My personal thought on this matter is that there is no need to specify or a= ssign the number, as you also mentioned, and this 'do nothing' may even be = a majority view, since it was the initial assumption. But I am not certain,= because not everyone voiced opinion. In this situation, a compromise had t= o be made. The compromise is that we will assign the value '10' to the defa= ult case with the statement that the default value can be overwritten per l= ocal policy, and 'May' must be used instead of 'Should' in the current text= . I think this compromise is consistent with your view. Thoughts? Thanks, Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf of Steve Donovan [srdonovan@us= donovans.com] Sent: Wednesday, October 28, 2015 4:06 PM To: Lee, Jay; dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Ten is acceptable to me. Steve On October 28, 2015 1:36:00 PM "Lee, Jay" > wrote: I also think that we agree on all different points for the finalization, ex= cept one point: the value for the default case. Use of the default case as = discussed here is rather in the future than in the present for us, so I do = not have strong opinion, especially when the default value can be overwritt= en. Looking at this objectively and also for the sake of progress, however, it = would be prudent to have more than one lower priority cases. In the near fu= ture, we may identify additional use cases for lower priority case. Even wi= th one use case identified, this does not necessarily mean one priority lev= el per use case. One use case may require multiple lower priority levels, d= epending on applications. Any value from 9 to 12 seems reasonable to me. But, without all use cases i= dentified at the present time, I propose 10 (JJacques' proposal) or 11. Thanks, Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: Monday, October 26, 2015 8:11 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Hi Please see my comments also in line. I think we are close to finalise our c= hoice on the different points of this thread Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de Lee, Jay Envoy=E9 : vendredi 23 octobre 2015 18:57 =C0 : dime@ietf.org Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp)= : Range of priority levels) Please see my comments inline. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Friday, October 23, 2015 8:02 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Please see my comments inline. Steve On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote: See inline From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay Sent: Friday, October 23, 2015 1:59 AM To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) ; dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Some further comments from my side: */ If we need to assign (but not specify) a value to the default case, we n= eed to make it clear that this value can be overwritten by operators, and t= he value is for some use cases like e.g., equipment having the same value w= hen leaving the factory, so that there would be no misunderstanding. mcd- ok SRD> I think the current proposed text makes this clear. [JL] Agree that the current text is OK especially when we use 'May' in plac= e of 'Should' [JJ] OK . */ Since we agree that the default value is per local policy, 'May' is pref= erred to 'Should' in order not to cause confusion. mcd-ok SRD> I'm okay with making this a MAY. [JL] Agreed [JJ] Also in favor of a MAY */ For assignment of the default value, I am quite open. But any value betw= een 9 - 12 seems reasonable to me. mcd- value should allow for assigning lower values, though a carrier can as= sign what they want in their network, there needs to be a common meaning at= the interconnection point SRD> I'm open to any value we decide on. If there are real use cases that = require pushing the default value more to the middle then we should do so. = At this point I've heard one use case for the default being something othe= r then the lowest value, thus the proposal to use priority_14 as the defaul= t. [JJ] Regarding use cases, there may be - The case where for "normal" users, an application use the defaul= t value for most of its requests except some which have a lower priority - the case where besides "normal" user (and high priority users), = some users have lower priorities, e.g. Some Machine type Communications (MT= C) devices. So potentially more than one low priority level would be needed. We also have chosen a rather large range of values (16) , allowing flexibil= ity for an operator when they define the number of priorities they want , l= eaving possibility to future additions. If PRIORITY _14 is the default, it = leaves only one lower priority and an operator cannot add a second one ex= cept by choosing a default value other than the 14 value. Then as, in practice, we may expect a range of low priority smaller than t= he range of high priority values, this is why the default value was propose= d to be in the range 9-12 . Then I proposed 10 so to do a proposal but I a= m open on another value. = &= ! nbsp;&nbs p; */ Current proposal of 16 values may be enough now, but I am fine with hav= ing an extensibility bit to be future proof. mcd-ok SRD> I don't see a compelling argument to move beyond 16. In addition, it isn't clear to me that there is value in defining an extens= ibility mechanism beyond what is already supported by Diameter. Doing so w= ould add significant complexity to the DRMP mechanism for something that, i= n my view, has a low probability of being used. I propose that we not allow extending the DRMP AVP. Rather we require that= any extension require a new AVP. We can then leave it to the document tha= t proposes the extension to deal with determining whether send the DRMP AVP= or the newly defined DRMPv2 AVP. [JL] When we proposed that the range be extended to 16, we thought that '16= ' was large enough and future proof. I am okay with having an extensibility bit, if other companies want it. Tha= t said, I agree that it has a low probability of being used and added compl= exity. [JJ] JJ I also agree that with 16 values , the offered range is large enoug= h in practice. This point is only to check if it would be easy to do an ext= ension, if we have this requirement in the future. I agree with Steve that= for an extensibility, it will require a new AVP in a new document rather t= han to define a set of reserved values in the DRMP AVP. A point is that it= will require an additional parsing effort for a node to look for this seco= nd AVP even if it is not present most of the time. */ I am not sure of alternative encoding method (say, +9 to -9 per JJacques= ' proposal) compared to the current enumerated type of DRMP. It offers a lo= gical way of assigning a value 0 to the default case. But it offers less fl= exibility to operators, since the default value may not be easily moved to = have more higher/lower priority values. Also, we are used to the enumerated= type of DRMP and just want to have extension from 5 to 16, but this may r= equire more deviation from the current design and thinking. For this, I wou= ld like to see more on qualitative pros/cons, but, given its little benefit= , I am reluctant to accept this alternative. SRD> I agree that I don't see value in the +9 to -9 proposal. [JL] Agreed [J] I presented this second approach so to review the possible alternativ= es as we usually do before selecting the solution, this alternative being a= lready used in a recent RFC. That being said, I am fine with the enumerat= ed DRMP AVP. Best regards JJacques From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: Thursday, October 22, 2015 9:39 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Hi 1. PRIORITY_14 as default priority value only allows one level of lowe= r priority (PRIORITY_15) than the default one; this seems not enough. As = use cases, we may have some Machine type Communication (LTC) devices that = may have lower priorities that normal communications without priority. Eve= n within a Diameter application, some commands may have a lower priority as= having a secundary importance. Then which default value ? - it could be PRIORITY_8 in the middle, or if we prefer to have a l= arger range for higher priorities than for lower priorities, the default = value could be e.g. PRIORITY_10, giving 9 higher priorities and 5 lower p= riorities than the default one. I would have a preference for this value PR= IORITY_10. 2. About extensibility, the current range of 16 values is already larg= e, but we can have a reserved value to indicate a further extension. With = an enumerated AVP, there is no possibility to add new values. 3. I also had a look to some other IETF RFCs addressing priorities tha= t Ken mentioned, so to see if we can benefit from these approaches although= done for different contexts. - in RFC 4412 (Resource-Priority Header in SIP), wps and ets namespa= ces have a range of 5 values (0 to 4) with 0 as the highest priority . But= I have not found some indication (I may have missed it) about the default= priority (I mean a SIP request without Resource-Priority Header compared= to a SIP request with the Header). Implicitly, I would assume a SIP reque= st without Resource-Priority Header corresponds to the lowest priority. = DRMP has a similar approach but with a larger range and also lower priorit= ies. - RFC 6710 (priority for SMTP), uses another encoding of the prior= ity values with an integer between -9 and +9. Lower priorities are negativ= e an higher priority being positive. When a value increases, it means a hig= her priority, so the opposite to DRMP, wps or ets. But the value 0 is her= e naturally the default value. So this is an encoding alternative to the = Enumerated type of the DRMP AVP which avoids the question of the default va= lue. Note: RFC 6710 also defines some Priority Assignment Policies using a subs= et of the range. RFC 6710 has also this guideline : SMTP servers compliant with this specification are not required to support all 19 distinct priority levels (i.e., to treat each priority value as a separate priority), .... That is, an implementation that only supports N priority levels (where N < 19) will internally round up a syntactically valid priority value that isn't supported to the next higher supported number (or to the highest supported priority, if the value is higher than any supported pr= iority). - This raises the question to have this type of guideline if consid= ered useful. So to have your feedback Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C Envoy=E9 : jeudi 15 octobre 2015 12:33 =C0 : Lee, Jay; ken carlberg; Steve Donovan Cc : dime@ietf.org Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp)= : Range of priority levels) A couple thoughts: 1. There needs to be a default value defined by the standard, so that = equipment have the same value leaving the factory 2. This value can be over written based on local policy 3. Should have an extensibility bit in order to and more values in the= future From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay Sent: Thursday, October 15, 2015 6:16 AM To: ken carlberg >; Steve D= onovan > Cc: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) >From my side, some more discussion on Steve's mail may be needed. 'Should' vs. 'Must': One can say that 'Should' is not mandatory. But, in practice, this is a fai= rly strong statement, and often taken as required. So in this sense, the pr= oposed Note is certainly helpful. But, since we allow operators to override= the value, I don't see the reason why we use 'Should'. My suggestion is us= ing 'May'. PRIORITY_14 priority: Since operators can overwrite it, I was not too concerned about it. But if = we want to put some value, why '14'? A value lower than 14 is suggested in = order to allow more rooms for lower priorities. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg Sent: Wednesday, October 14, 2015 8:40 AM To: Steve Donovan Cc: dime@ietf.org Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): R= ange of priority levels) with respect to the diff-serv example brought up below, some thing to add t= o that discussion is that it starts off with separate and distinct forwardi= ng behavior whose marked packets provide segmentation of other IP traffic. = The availability of only 6 bits to play with (along with the headaches of = transitive trust) also discouraged a line of thought to define end-to-end p= riority handling versus a per diff-serv domain treatment. RFC-4594 did pro= vide configuration guidelines, but that's a different story. So back to a couple of ideas to consider. 1) reserved space. if we go back to the diff-serv model, the diff-serv wor= king group agreed to set aside a set of values that was reserved for experi= mental use that could be re-assigned some time in the future. I'm not sugg= esting that there should be space set side for experiments, but rather it m= ay be prudent to set aside a reserved set of bits/values so that one doesn'= t need to define a new AVP if in the future there was a need to define adde= d values beyond the 5 (plus some fudge factor) already mentioned on the lis= t. 2) sets of users. previous work (e.g., rfc-4412, rfc-6710) recognized that= there can be several sets of users/services that are distinct from each ot= her and yet need to prioritize the traffic. I bring this up because the dr= aft already identifies two sets of users in sections 5.1 and 5.2 (note: I'm= assuming that the latter is aimed at the general public and related to 911= /112/999 type calls, which should probably be more specific in the draft). = And there is also the potential of Firstnet users in the US. As a side note, the distinction and separation of general public and other = prioritized users in public phone infrastructures is not exclusive to the U= S, so the group should not be concerned that this is a US centric effort. = There has been GTPS in the UK, as well as other systems in other countries.= The RFC is a bit dated, but feel free to go over rfc-4190 for added backg= round. and just to reiterate. I'm not making recommendations in the above - just = bringing up some food for thought. -ken On Oct 14, 2015, at 10:12 AM, Steve Donovan > wrote: Jay, The current text is a SHOULD level requirement: When there is a mix of transactions specifying priority in request messages and transactions that do not have the priority specified, transactions that do not have a specified priority SHOULD be treated as having the PRIORITY_14 priority. As such, operators can choose to either not implement a priority or define = a different value for their network. I propose adding the following note after this paragraph to further explain= why it is a SHOULD and not a MUST: Note: There are scenarios where operators might want to specify a different default value for transactions that do not have an explicit priority. In this case, the operator defined local policy would override the use of PRIORITY_14 as the default priority. This leaves the ability for there to be deterministic behavior in Diameter = networks that require a default to be defined and are happy with the specif= ied default. It also gives operators the ability to define a different beh= avior, most likely with some priority handling/mapping at the edge of the n= etwork. Does this address your concerns? Regards, Steve On 10/14/15 2:59 AM, Lee, Jay wrote: Regarding the issue of whether we need to specify a default value or not, t= here are pros and cons. If we specify a value for the default case, we can see the benefits in scen= arios between different operator networks, but we take away important optio= ns on what operators can do with priority values. On the other hand, if we = do not specify the default value, operators may have more options, but ther= e is a question of what to do for this inter-PLMN cases when the networks m= ay use different default values. In practice, this issue can be addressed at the edge of the network, where = Diameter edge agent (DEA) can perform some priority mapping based on bilate= ral roaming agreement (or SLA (service level agreement)) and other means to= insure the proper handling. One may argue that this is not as good as the = 'deterministic' case, but operator should be able handle this in a reasonab= le way. We are fully aware of the fact that, in case of this 'non-determini= stic' case, the default value can differ from one operator network to anoth= er, and it becomes difficult to guarantee the intended priority handling. D= espite this, we still prefer giving options to operators by not specifying = the default value. What we are saying here, however, is not anything new. This is the typical = way of handling priority levels. If anything, specifying the default value = would be something new. As already mentioned in CT discussion, there is a g= ood example of this - Internet QoS, more specifically DiffServ. In order to guarantee end-to-end QoS for a specific service, IETF could hav= e specified a value (DiffServ codepoint) for the specific service to have p= redetermined handling of the traffic, but IETF did not. Instead, DiffServ s= imply provided a framework for operators to have its own classification an= d differentiated treatment of the services. To guarantee end-to-end QoS acr= oss different networks, then, operators need to do packet inspection, (re)c= lassification, QoS mapping, use of SLA and possibly others at the edge of n= etwork (edge router). Therefore, in the DiffServ architecture, intelligence= was pushed to the edge of the network. While the end results may not be gu= aranteed as well as in the case of predetermined handling, it was still a p= referred way to give flexibility to operators. My point is that we went thr= ough all these troubles to give options of priority handling to operators. By the way, if we are thinking of possibility of specifying the default val= ue, are we assuming that all operators are interested in this feature (defa= ult value in the middle, and high and low priorities at other ends)? Aren't= there other operators who are not interested in this feature? I know that = at least there is one - Verizon. We have no interest in this feature, and n= o plan for implementing it. We are OK, if other operators are interested in= this feature, and the default value is NOT specified. But we are certainly= not happy if DIME is trying to impose this on us. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, October 13, 2015 10:55 AM To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org; Pollini, Gregory P Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Assuming that we define a range of 3 values, Assuming that 0 is the lowest priority and 2 the highest, Assuming that an agent receives 4 messages at the same time while being in = overload control: * 1) ULR with Prio-0 * 2) ULR with Prio-1 * 3) ULR with Prio-2 * 4) ULR with no priority AVP Assuming that the default is locally defined as proposed below, How do you know that the ULR with priority 2 will be handled with a higher = priority than the request without priority indication? And what about ULR message with priority 1 with two levels of highest prior= ity e.g. emergency/Important and government/very important? Sorry if the answer is obvious but I fail to understand. Lionel De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] Envoy=E9 : samedi 3 octobre 2015 01:21 =C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C Cc : DiME; dime@ietf.org; Pollini, Gregory P Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels Hello all, Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.21= 2 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defi= ned. Having 15 rather than 16 would be useful from an interworking point of view= on Diameter interfaces connecting to the EPS. Also, my understanding has been that the default value is per local policy. My 2 cents.... Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf = of lionel.morand@orange.com [lionel.morand= @orange.com] Sent: Thursday, October 01, 2015 3:36 AM To: Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Hi, I think that the case "no Priority indication in request" is the default si= tuation today. So if we agree that it should be possible to explicitly indicate a request = with a lower priority, we should divide the range of priority values in thr= ee sub-ranges: [lower priorities][no priority indication][higher priorities= ], e.g. with 17 values: [0-7][8][9-16]. If any operator can freely fix the default value, there would be no way to = ensure the sender that a request with a specific priority value (e.g. 6) wi= ll be handled with a lower or higher priority than a request with no priori= ty indication. Therefore, for a deterministic handling mechanism, I think that it is then = more relevant to define a standard value for the default value. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn Envoy=E9 : mercredi 30 septembre 2015 22:53 =C0 : DOLLY, MARTIN C Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels Same here. The "default priority" should be a matter of local policy. Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "DOLLY, MARTIN C" > To: Steve Donovan >, "dime@ietf.org" > Date: 09/30/2015 04:40 PM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" = > ________________________________ Me as well From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, September 30, 2015 4:38 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels I'm okay with Jay's proposal on not specifying a default value. Steve On 9/30/15 3:27 PM, Lee, Jay wrote: Hi Steve and all, For the first proposal, as I indicated, I support increasing the number of = priority levels up to 16. I am also fine with the second proposal. My question is: do we need to mand= ate this feature, as individual operators have different situations? Perhap= s some flexibility should be allowed? Instead of mandating it, we can inclu= de the statement that when there is no DRMP AVP, this correspond to 'normal= traffic' without a particular high or low priority. Then each operator can= map this default to a value (e.g., 8 or something else) that they feel app= ropriate. Thanks, Jay _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_C026C31E3CD6CA43953D6D95AB480480049979CASAC1EXP009uswin_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please see my comments in= line.

 <= /p>

Jay

 <= /p>

From: Shaikh, Viqar A [mailto:vshaikh@appcomsci.com]
Sent: Thursday, October 29, 2015 12:59 PM
To: Steve Donovan; Lee, Jay; dime@ietf.org
Cc: Singh, Ray P; Pollini, Gregory P; Lukacs, Donald R
Subject: RE: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Hello all,

 

My 2 cents:

 

Greater than 5 values for DRMP AVP is justified = and it appears there is agreement for 16.  However, note tha= t the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 t= akes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined. Ha= ving 15 rather than 16 for DRMP AVP would be useful from an interworking po= int of view on Diameter interfaces connecting to the EPS.

 

[JL] I can see that, if the same number (i.e.= , 15) is used on both sides, there may be one-to-one mapping. This interwor= king/mapping should be done as part of 3GPP DRMP WI, starting from next 3GPP CT4 meeting. But the mapping can be both one-to-one and one= -to-many (multiple). Even if the same number is used, I don’t know at= the moment that we can exclude the possibility of one-to-many mapping. So = I am not sure that we need to have the same number on both sides.

 

Regarding the default value - it is based on&nbs= p;operator policy and can be overwritten by an operator.  Therefore, w= e support use of "may" and not "should". 

 

[JL] Using ‘May’ is the consensus= do far.

 

We feel that 15 or 16 values should suffice and = there is no need to define an extension bit.  However, I am ok if= there is consensus to do so.

 

[JL] The consensus so far is that it is bette= r not to have the extension bit.

 

We feel there is no need to specify a defau= lt as it is per local policy and can be overwritten.  But, if there is= consensus to do so, we suggest value 10 or 11 with a note that it can be overwritten based on operator policy.

 

[JL] Initial assumption was that there is no = need to specify or even assign a default value, I believe. But then, there = was a proposal to specify the default value, making it mandatory. And then, there was also a proposal that, even if the default v= alue is not specified, we need to assign the default value that can be over= written in order to have common understanding for some reasons.

 

My personal thought on this matter is that th= ere is no need to specify or assign the number, as you also mentioned, and = this ‘do nothing’ may even be a majority view, since it was the initial assumption. But I am not certain, because not everyone voi= ced opinion. In this situation, a compromise had to be made. The compromise= is that we will assign the value ‘10’ to the default case with= the statement that the default value can be overwritten per local policy, and ‘May’ must be used instead o= f ‘Should’ in the current text. I think this compromise is cons= istent with your view.

 

Thoughts?

 

Thanks,

Viqar

 

From:<= /span> DiME [dime-bounces@ietf.org] on behalf of Steve Dono= van [srdonovan@usdonovans.com]
Sent: Wednesday, October 28, 2015 4:06 PM
To: Lee, Jay; dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

Ten is accept= able to me.

Steve

On October 28, 2015 1:36:00 PM "Lee, Jay" = <Jay.Lee@VerizonWireless.= com> wrote:

I also think that we agre= e on all different points for the finalization, except one point: the value= for the default case. Use of the default case as discussed here is rather in the future than in the present for us, so I do not have = strong opinion, especially when the default value can be overwritten.

 

Looking at this objective= ly and also for the sake of progress, however, it would be prudent to have = more than one lower priority cases. In the near future, we may identify additional use cases for lower priority case. Even with on= e use case identified, this does not necessarily mean one priority level pe= r use case. One use case may require multiple lower priority levels, depend= ing on applications.

 

Any value from 9 to 12 se= ems reasonable to me. But, without all use cases identified at the present = time, I propose 10 (JJacques’ proposal) or 11.

 

Thanks,=

 

Jay

 

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Monday, October 26, 2015 8:11 AM
To: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Hi

 

Please see my comments al= so in line. I think we are close to finalise our choice on the different po= ints  of this thread

 

Best regards<= /o:p>

 

JJacques

 

De := DiME [mailto:dime-bounces@ietf.org] De la part de Lee, Jay
Envoy=E9 : vendredi 23 octobre 2015 18:57
=C0 : dime@ietf.= org
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime= ] #92 (drmp): Range of priority levels)

 

Please see my comments in= line.

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Friday, October 23, 2015 8:02 AM
To: dime@ietf.org=
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Please see my comment= s inline.

Steve

On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote:

See inline

 

From: DiME [= mailto:dime-boun= ces@ietf.org] On Behalf Of Lee, Jay
Sent: Friday, October 23, 2015 1:59 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) <jean-jacques.trottin@alcatel-lucent.com>; dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Some further comments fro= m my side:

 

*/ If we need to assign (= but not specify) a value to the default case, we need to make it clear that= this value can be overwritten by operators, and the value is for some use cases like e.g., equipment having the same value when leav= ing the factory, so that there would be no misunderstanding.

mcd- ok=

SRD> I think the current proposed text makes this= clear.
[JL] Agree that the current text is OK especi= ally when we use ‘May’ in place of ‘Should’<= o:p>

[JJ] OK

.

 

mcd-ok

SRD> I'm okay with making this a MAY.<= /p>

[JL]  Agreed<= o:p>

[JJ] Also in favor of a M= AY

 

mcd- value should allow f= or assigning lower values, though a carrier can assign what they want in th= eir network, there needs to be a common meaning at the interconnection point

SRD> I'm open to any value we decide on.  If= there are real use cases that require pushing the default value more to th= e middle then we should do so.  At this point I've heard one use case = for the default being something other then the lowest value, thus the proposal to use priority_14 as the default.  <= o:p>

[JJ] Regarding use cases,= there may be

- &nbs= p;        The case where for “normal” u= sers, an application use the default value for most of its requests except = some which have a lower priority

- &nbs= p;        the case where besides “normal̶= 1; user (and high priority users), some users have lower priorities, e.g. S= ome Machine type Communications (MTC) devices.

So potentially more than = one low priority level would be needed.

We also have chosen a rat= her large range of values (16) , allowing flexibility for an operator when = they define the number of priorities they want , leaving possibility to future additions. If PRIORITY _14 is the default, it leaves= only one lower priority and an operator  cannot add a second one &nbs= p;except by choosing  a default value other than the 14  value.

Then as, in practice, we = may expect a range of low priority smaller than  the range of high pri= ority values, this is why the default value was proposed to be in the range 9-12  . Then I proposed 10 so to do a proposal but I am = open on another value.

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       &! nbsp;&nbs p;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =           

mcd-ok

SRD> I don't see a compelling argument to move be= yond 16. 
In addition, it isn't clear to me that there is value in defining an extens= ibility mechanism beyond what is already supported by Diameter.  Doing= so would add significant complexity to the DRMP mechanism for something th= at, in my view, has a low probability of being used.

I propose that we not allow extending the DRMP AVP.  Rather we require= that any extension require a new AVP.  We can then leave it to the do= cument that proposes the extension to deal with determining whether send th= e DRMP AVP or the newly defined DRMPv2 AVP. 
[JL] When we proposed that the range be exten= ded to 16, we thought that ‘16’ was large enough and future pro= of.

I am okay with having = an extensibility bit, if other companies want it. That said, I agree that i= t has a low probability of being used and added complexity.

[JJ] JJ I also agree t= hat with 16 values , the offered range is large enough in practice. This po= int is only to check if it would be easy to do an extension, if we have thi= s requirement in the future.  I agree with Steve that for an extensibility, it will require a new AVP in a new d= ocument rather than to define a set of reserved values in the DRMP AVP. &nb= sp;A point is that it will require an additional parsing effort for a node = to look for this second AVP even if it is not present most of the time.  

 

SRD> I agree that I don't see value in the +9= to -9 proposal.

[JL] Agreed

[J] I presented this seco= nd  approach  so to review the possible alternatives as we usuall= y do before selecting the solution, this alternative being already used in a recent RFC.   That being said, I am fine with the enum= erated DRMP AVP.

 

Best regards<= /o:p>

 

JJacques  

 

From: DiME [mailto:dime-bounce= s@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Thursday, October 22, 2015 9:39 AM
To: dime@ietf.org=
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Hi

 

1.      PRIORITY_14 as default priority value onl= y allows one level of lower priority (PRIORITY_15)  than the default o= ne; this seems not enough.  As use cases, we may have  some Machine type Communication (LTC) devices that may have lower priorities th= at normal communications without priority.  Even within a Diameter app= lication, some commands may have a lower priority as having a secundary imp= ortance.

 =

Then which default  value ?

- &nbs= p;      it could be PRIORITY_8 in the middle, or = if we prefer to have a  larger range for higher priorities  than = for lower priorities,  the default value could be  e.g. PRIORITY_= 10,  giving 9 higher priorities and 5 lower priorities than the default one. I = would have a preference for this value PRIORITY_10.

 

2.      About extensibility, the current range of= 16 values is already large, but we can have  a reserved value to indi= cate a further extension. With  an enumerated AVP, there is no possibility to add new values. 

 

3.      I also had a look to some other IETF RFCs= addressing priorities that Ken mentioned, so to see if we can benefit from= these approaches although done for different contexts.

- &nbs= p;      in RFC 4412 (Resource-Priority Header in = SIP), wps and ets namespaces have a range of 5 values (0 to 4) with 0 as th= e highest priority  . But I have not found some indication  (I may have missed it) about the default priority  (I mean a SIP requ= est without  Resource-Priority Header compared  to a SIP request = with the Header). Implicitly, I would assume a SIP request without  Re= source-Priority Header corresponds to  the lowest priority.  DRMP has a similar approach but with  a larger range and also l= ower priorities.

 

- &nbs= p;      RFC  6710 (priority for SMTP),  = ;uses another encoding of the priority values with an integer between -9 an= d +9. Lower priorities  are negative an higher priority being posi= tive. When a value increases, it means a higher priority, so the opposite  = to DRMP, wps or ets.  But the value 0 is here naturally the default va= lue. So this is an encoding alternative  to the  Enumerated type = of the DRMP AVP which avoids the question of the default value.

Note: RFC  67= 10 also defines some Priority Assignment Policies using a subset of the ran= ge.

 

   SMTP server= s compliant with this specification are not

   required to supp= ort all 19 distinct priority levels (i.e., to treat

   each priority va= lue as a separate priority), ….  That is, an

   implementation t= hat only supports N priority levels (where N < 19)

   will internally = round up a syntactically valid priority value that

   isn't supported = to the next higher supported number (or to the

   highest supporte= d priority, if the value is higher than any supported priority).

- &nbs= p;      This raises the question to have this typ= e of  guideline if considered useful.

 

So to have your feedback

 

Best regards<= /o:p>

 

JJacques

 

De : DiME= [mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C
Envoy=E9 : jeudi 15 octobre 2015 12:33
=C0 : Lee, Jay; ken carlberg; Steve Donovan
Cc : dime@ietf.org
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime= ] #92 (drmp): Range of priority levels)

 

A couple thoughts:=

1. &nb= sp;    There needs to be a default value defined= by the standard, so that equipment have the same value leaving the factory=

2. &nb= sp;    This value can be over written based on l= ocal policy

3. &nb= sp;    Should have an extensibility bit in order= to and more values in the future

 

 

From: DiME [= mailto:dime-boun= ces@ietf.org] On Behalf Of Lee, Jay
Sent: Thursday, October 15, 2015 6:16 AM
To: ken carlberg <carlberg@g11.org.uk>; Steve Donovan <srdonovan@usdonovans.com&= gt;
Cc: dime@ietf.org=
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

From my side, some more d= iscussion on Steve’s mail may be needed.

 

‘Should’ vs. = ‘Must’:

One can say that ‘S= hould’ is not mandatory. But, in practice, this is a fairly strong st= atement, and often taken as required. So in this sense, the proposed Note is certainly helpful. But, since we allow operators to override the v= alue, I don’t see the reason why we use ‘Should’. My sugg= estion is using ‘May’.

 

PRIORITY_14 priority:

Since operators can overw= rite it, I was not too concerned about it. But if we want to put some value= , why ‘14’? A value lower than 14 is suggested in order to allow more rooms for lower priorities.

 

Jay

 

From: DiME [mailto:dime-bounce= s@ietf.org] On Behalf Of ken carlberg
Sent: Wednesday, October 14, 2015 8:40 AM
To: Steve Donovan
Cc: dime@ietf.org=
Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (d= rmp): Range of priority levels)

 

with respect to the diff-serv example brought up bel= ow, some thing to add to that discussion is that it starts off with separat= e and distinct forwarding behavior whose marked packets provide segmentatio= n of other IP traffic.  The availability of only 6 bits to play with (along with the headaches of transitive trust)= also discouraged a line of thought to define end-to-end priority handling = versus a per diff-serv domain treatment.  RFC-4594 did provide configu= ration guidelines, but that’s a different story.

 

So back to a couple of ideas to consider.=

 

1) reserved space.  if we go back to the diff-s= erv model, the diff-serv working group agreed to set aside a set of values = that was reserved for experimental use that could be re-assigned some time = in the future.  I’m not suggesting that there should be space set side for experiments, but rather it may be prude= nt to set aside a reserved set of bits/values so that one doesn't need to d= efine a new AVP if in the future there was a need to define added values be= yond the 5 (plus some fudge factor) already mentioned on the list. 

 

2) sets of users.  previous work (e.g., rfc-441= 2, rfc-6710) recognized that there can be several sets of users/services th= at are distinct from each other and yet need to prioritize the traffic. &nb= sp;I bring this up because the draft already identifies two sets of users in sections 5.1 and 5.2 (note: I’m assu= ming that the latter is aimed at the general public and related to 911/112/= 999 type calls, which should probably be more specific in the draft).  = ;And there is also the potential of Firstnet users in the US.

 

As a side note, the distinction and separation of ge= neral public and other prioritized users in public phone infrastructures is= not exclusive to the US, so the group should not be concerned that this is= a US centric effort.  There has been GTPS in the UK, as well as other systems in other countries.  The RFC= is a bit dated, but feel free to go over rfc-4190 for added background.

 

and just to reiterate.  I’m not making re= commendations in the above — just bringing up some food for thought.<= o:p>

 

-ken

 

 

On Oct 14, 2015, at 10:12 AM, Steve Donovan <srdonovan@usdonov= ans.com> wrote:

 

Jay,

The current text is a SHOULD level require= ment:

   When there is a mix of transa= ctions specifying priority in request
   messages and transactions tha= t do not have the priority specified,
   transactions that do not have= a specified priority SHOULD be treated
   as having the PRIORITY_14 pri= ority.

As such, operators can choose to either no= t implement a priority or define a different value for their network.

I propose adding the following note after = this paragraph to further explain why it is a SHOULD and not a MUST:=

      Note: There= are scenarios where operators might want to 
      specify a d= ifferent default value for transactions that do not
      have an exp= licit priority.  In this case, the operator defined
      local polic= y would override the use of PRIORITY_14 as
      the default= priority.

This leaves the ability for there to be de= terministic behavior in Diameter networks that require a default to be defi= ned and are happy with the specified default.  It also gives operators= the ability to define a different behavior, most likely with some priority handling/mapping at the edge of the network= .

Does this address your concerns?
Regards,

Steve

On 10/14/15= 2:59 AM, Lee, Jay wrote:

 

 

 

 

 

 

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Tuesday, Oct= ober 13, 2015 10:55 AM
To: Shaikh, Viqar = A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; <= a href=3D"mailto:dime@ietf.org" target=3D"_blank">dime@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; Pollini, Gregory P
Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 

=B7     &nbs= p; 1) ULR with Prio-0

=B7     &nbs= p; 2) ULR with Prio-1

=B7     &nbs= p; 3) ULR with Prio-2

=B7     &nbs= p; 4) ULR with no priority AVP

 

 

 

 

 

 

De :<= /span> Shaikh, Viqar A [mailto:vshaikh@a= ppcomsci.com] 
Envoy=E9 : sa= medi 3 octobre 2015 01:21
=C0 : MORAND = Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; dime@ietf.org; Pollini, Gregory P
Objet : RE: [= Dime] [dime] #92 (drmp): Range of priority levels

 

Hello all,

 

Note tha= t the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 t= akes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined.

 

Having 15 rat= her than 16 would be useful from an interworking point of view on Diameter = interfaces connecting to the EPS.  

 

Also, my unde= rstanding has been that the default value is per local policy. 

 

My 2 cents....

Viqar 

<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">From: DiME [dime-bounces@i= etf.org] on behalf of lionel.morand@orange.com [lionel.= morand@orange.com]
Sent: Thursday, Oc= tober 01, 2015 3:36 AM
To: Janet P Gunn; = DOLLY, MARTIN C
Cc: DiME; dime@ietf.org
Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 

 

 

Regards,

 

Lionel

 

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn
Envoy=E9 : me= rcredi 30 septembre 2015 22:53
=C0 : DOLLY, = MARTIN C
Cc : DiME; dime@ie= tf.org
Objet : Re: [= Dime] [dime] #92 (drmp): Range of priority levels

 

Same here. &nb= sp;The "default priority" should be a matter of local policy. 

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose. 



From:        &= quot;DOLLY, MARTIN C" <md31= 35@att.com> 
To:        S= teve Donovan <srdonova= n@usdonovans.com>, "dime@ietf.org" <dime@ietf.org>&nbs= p;
Date:        0= 9/30/2015 04:40 PM 
Subject:        Re: [Dime] [dime] #92 (drmp): Range of priority levels 
Sent by:        "DiME" <dime-= bounces@ietf.org>




Me as well 
  
From: DiME [mailto:dime-bounces@iet= f.org]=  On Behalf Of Steve Dono= van
Sent: Wednesday, Sept= ember 30, 2015 4:38 PM
To: dime@ietf.org Subject: = ;Re: [Dime] [dime] #92 (drmp): Range of priority= levels 
  
I'm okay with Jay's proposal on not specifying a default value= .

Steve 
On 9/30/15 3:27 PM, Lee, Jay wrote: 
Hi Steve and all,=  
  
For the first proposal, as I indicated, I support increasing t= he number of priority levels up to 16. 
  
I am also fine with the second proposal. My question is: do we= need to mandate this feature, as individual operators have different situa= tions? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that when there is no DRMP A= VP, this correspond to ‘normal traffic’ without a particular hi= gh or low priority. Then each operator can map this default to a value (e.g= ., 8 or something else) that they feel appropriate. 
  
Thanks, 
  
Jay <= br>


__________________________________________= _____ 
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 d=
es informations confidentielles ou
privilegiees et ne doivent donc
pas etre
diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce
message par erreur, veuillez le signa=
ler
a l'expediteur

et le detruire ainsi que les pieces j=
ointes. Les messages electroniques


etant susceptibles d'alteration,


Orange decline

toute responsabilite si ce message a =
ete altere, deforme ou falsifie.


Merci.


 


This message


and its attachments may contain confidential or p=
rivileged 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 s=
ender and delete this


message and its attachments.

As emails may


be altered, Orange is not liable for messages tha=
t have been modified,


changed or falsified.


Thank


you.


_____________________________________=
___________________________________________________________________________=
_________
 
Ce message et
ses pieces jointes peuvent contenir d=
es informations confidentielles ou
privilegiees et ne doivent donc
pas etre
diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce
message par erreur, veuillez le signa=
ler
a l'expediteur

et le detruire ainsi que les pieces j=
ointes. Les messages electroniques


etant susceptibles d'alteration,


Orange decline

toute responsabilite si ce message a =
ete altere, deforme ou falsifie.


Merci.


 


This message


and its attachments may contain confidential or p=
rivileged 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 s=
ender and delete this


message and its attachments.

As emails may


be altered, Orange is not liable for messages tha=
t have been modified,


changed or falsified.


Thank


you.


&nbs=
p;


_______________________________________________


DiME mailing


list


DiME@ietf.org

https://www.ietf.org/m=
ailman/listinfo/dime


__________________________________________= _____
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailm= an/listinfo/dime

 

 

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

 

_____________________= __________________________
DiME mailing list
DiME@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dime

--_000_C026C31E3CD6CA43953D6D95AB480480049979CASAC1EXP009uswin_-- From nobody Fri Oct 30 10:16:06 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64EA1A88FF for ; Fri, 30 Oct 2015 10:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vc7v3DFa9QAY for ; Fri, 30 Oct 2015 10:14:57 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8241A8877 for ; Fri, 30 Oct 2015 10:14:48 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 31643D930ACAF; Fri, 30 Oct 2015 17:14:42 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t9UHEhFX013849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 Oct 2015 18:14:43 +0100 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.230]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 30 Oct 2015 18:14:43 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" , "Shaikh, Viqar A" Thread-Topic: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) Thread-Index: AQHRBzKIwn0SbO3rXUW/ebDof+lRcp5sOcGAgAtoZjCAAZc3ZYAAEqiAgASJrNCAA3T5QIAAYjIAgAFJtOyAANeskIAAWVAg Date: Fri, 30 Oct 2015 17:14:42 +0000 Message-ID: References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> <20151014075941.062E21B2C1F@ietfa.amsl.com> <561E62C9.20500@usdonovans.com> <1431d0b2-5ae7-426e-b5ff-42b23fecbee5@CASAC1EXH002.uswin.ad.vzwcorp.com> <20151015101558.111761ACD5C@ietfa.amsl.com> <3e7a25c8-5eea-49a5-9905-3009c4dc45b8@NYORA1HUB001.uswin.ad.vzwcorp.com> <20151023055927.9223C1B3292@ietfa.amsl.com> <20151023165728.7D0E01A874F@ietfa.amsl.com> <20151028183455.88E9E1A899A@ietfa.amsl.com>, <150b00ed6f0.277f.0301301ad371d4c21d5a2092e0e442f2@usdonovans.com> <0c915451-c6b2-4644-80f8-f0cac6dff0b3@OHTWI1EXH001.uswin.ad.vzwcorp.com> <20151030100958.4CEBE1B2AAE@ietfa.amsl.com> In-Reply-To: <20151030100958.4CEBE1B2AAE@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D29D46519FFR712WXCHMBA12z_" MIME-Version: 1.0 Archived-At: Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 30 Oct 2015 17:16:03 -0000 --_000_E194C2E18676714DACA9C3A2516265D29D46519FFR712WXCHMBA12z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi >From the email threads about draft-ietf-dime-drmp, I think we now conclude= d on the pending points with still a small discussion about a range of 15= or 16 values on which we should conclude. - On my side I was OK with the initial proposal of 16 values. For= a mapping between a list A with a range of 15 values and the DRMP range o= f 16 values , a simple one is to do 1 to 1 mapping except for the value 15t= h and 16 th (lowest priorities) of the DRMP range which would be mapped t= o the value 15 of the listA range. That being said, I have no issue to use= a DRMP range of 15 value if some of us prefer. Regarding the draft I think the unique Editor's note in version 1 can be = removed and after integration of the conclusions in new draft, I would be = in favour to go towards the last call step. - I hereafter give some information to Dime-list about the process= on 3GGP side. Diameter message Priority is an important requirement for 3GPP which agree= d on a Release 13 Work Item supported by many companies. 3GPP also decided = to use the draft-ietf-dime-drmp to fulfill this requirement and already ag= reed Change Requests to some specifications, with an editor's note assumi= ng that draft-ietf-dime-drmp is stable enough to do so. Further Change Req= uest for other specifications will be submitted in the upcoming 3GPP meetin= g in November which is the last meeting for the 3GPP Release 13. Our IETF dime work and conclusions drives me to consider that the draft has= become stable -so with my proposal that the updated version be submitted t= o the last call. I am not so much familiar with IETF process, I hope my pr= oposal follows the IETF procedures. Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de Lee, Jay Envoy=E9 : vendredi 30 octobre 2015 11:10 =C0 : Shaikh, Viqar A; Steve Donovan; dime@ietf.org Cc : Singh, Ray P; Lukacs, Donald R; Pollini, Gregory P Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp)= : Range of priority levels) Please see my comments inline. Jay From: Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] Sent: Thursday, October 29, 2015 12:59 PM To: Steve Donovan; Lee, Jay; dime@ietf.org Cc: Singh, Ray P; Pollini, Gregory P; Lukacs, Donald R Subject: RE: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Hello all, My 2 cents: Greater than 5 values for DRMP AVP is justified and it appears there is agr= eement for 16. However, note that the 3GPP priority, e.g., Priority-Level = AVP (ARP AVP) in TS 29.212 takes 15 values, value 1 the highest, 15 the low= est, and value 0 not defined. Having 15 rather than 16 for DRMP AVP would b= e useful from an interworking point of view on Diameter interfaces connecti= ng to the EPS. [JL] I can see that, if the same number (i.e., 15) is used on both sides, t= here may be one-to-one mapping. This interworking/mapping should be done as= part of 3GPP DRMP WI, starting from next 3GPP CT4 meeting. But the mapping= can be both one-to-one and one-to-many (multiple). Even if the same number= is used, I don't know at the moment that we can exclude the possibility of= one-to-many mapping. So I am not sure that we need to have the same number= on both sides. Regarding the default value - it is based on operator policy and can be ove= rwritten by an operator. Therefore, we support use of "may" and not "shoul= d". [JL] Using 'May' is the consensus do far. We feel that 15 or 16 values should suffice and there is no need to define = an extension bit. However, I am ok if there is consensus to do so. [JL] The consensus so far is that it is better not to have the extension bi= t. We feel there is no need to specify a default as it is per local policy and= can be overwritten. But, if there is consensus to do so, we suggest value= 10 or 11 with a note that it can be overwritten based on operator policy. [JL] Initial assumption was that there is no need to specify or even assign= a default value, I believe. But then, there was a proposal to specify the = default value, making it mandatory. And then, there was also a proposal tha= t, even if the default value is not specified, we need to assign the defaul= t value that can be overwritten in order to have common understanding for s= ome reasons. My personal thought on this matter is that there is no need to specify or a= ssign the number, as you also mentioned, and this 'do nothing' may even be = a majority view, since it was the initial assumption. But I am not certain,= because not everyone voiced opinion. In this situation, a compromise had t= o be made. The compromise is that we will assign the value '10' to the defa= ult case with the statement that the default value can be overwritten per l= ocal policy, and 'May' must be used instead of 'Should' in the current text= . I think this compromise is consistent with your view. Thoughts? Thanks, Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf of Steve Donovan [srdonovan@us= donovans.com] Sent: Wednesday, October 28, 2015 4:06 PM To: Lee, Jay; dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Ten is acceptable to me. Steve On October 28, 2015 1:36:00 PM "Lee, Jay" > wrote: I also think that we agree on all different points for the finalization, ex= cept one point: the value for the default case. Use of the default case as = discussed here is rather in the future than in the present for us, so I do = not have strong opinion, especially when the default value can be overwritt= en. Looking at this objectively and also for the sake of progress, however, it = would be prudent to have more than one lower priority cases. In the near fu= ture, we may identify additional use cases for lower priority case. Even wi= th one use case identified, this does not necessarily mean one priority lev= el per use case. One use case may require multiple lower priority levels, d= epending on applications. Any value from 9 to 12 seems reasonable to me. But, without all use cases i= dentified at the present time, I propose 10 (JJacques' proposal) or 11. Thanks, Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: Monday, October 26, 2015 8:11 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Hi Please see my comments also in line. I think we are close to finalise our c= hoice on the different points of this thread Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de Lee, Jay Envoy=E9 : vendredi 23 octobre 2015 18:57 =C0 : dime@ietf.org Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp)= : Range of priority levels) Please see my comments inline. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Friday, October 23, 2015 8:02 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Please see my comments inline. Steve On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote: See inline From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay Sent: Friday, October 23, 2015 1:59 AM To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) ; dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Some further comments from my side: */ If we need to assign (but not specify) a value to the default case, we n= eed to make it clear that this value can be overwritten by operators, and t= he value is for some use cases like e.g., equipment having the same value w= hen leaving the factory, so that there would be no misunderstanding. mcd- ok SRD> I think the current proposed text makes this clear. [JL] Agree that the current text is OK especially when we use 'May' in plac= e of 'Should' [JJ] OK . */ Since we agree that the default value is per local policy, 'May' is pref= erred to 'Should' in order not to cause confusion. mcd-ok SRD> I'm okay with making this a MAY. [JL] Agreed [JJ] Also in favor of a MAY */ For assignment of the default value, I am quite open. But any value betw= een 9 - 12 seems reasonable to me. mcd- value should allow for assigning lower values, though a carrier can as= sign what they want in their network, there needs to be a common meaning at= the interconnection point SRD> I'm open to any value we decide on. If there are real use cases that = require pushing the default value more to the middle then we should do so. = At this point I've heard one use case for the default being something othe= r then the lowest value, thus the proposal to use priority_14 as the defaul= t. [JJ] Regarding use cases, there may be - The case where for "normal" users, an application use the defaul= t value for most of its requests except some which have a lower priority - the case where besides "normal" user (and high priority users), = some users have lower priorities, e.g. Some Machine type Communications (MT= C) devices. So potentially more than one low priority level would be needed. We also have chosen a rather large range of values (16) , allowing flexibil= ity for an operator when they define the number of priorities they want , l= eaving possibility to future additions. If PRIORITY _14 is the default, it = leaves only one lower priority and an operator cannot add a second one ex= cept by choosing a default value other than the 14 value. Then as, in practice, we may expect a range of low priority smaller than t= he range of high priority values, this is why the default value was propose= d to be in the range 9-12 . Then I proposed 10 so to do a proposal but I a= m open on another value. = &= ! nbsp;&nbs p; */ Current proposal of 16 values may be enough now, but I am fine with hav= ing an extensibility bit to be future proof. mcd-ok SRD> I don't see a compelling argument to move beyond 16. In addition, it isn't clear to me that there is value in defining an extens= ibility mechanism beyond what is already supported by Diameter. Doing so w= ould add significant complexity to the DRMP mechanism for something that, i= n my view, has a low probability of being used. I propose that we not allow extending the DRMP AVP. Rather we require that= any extension require a new AVP. We can then leave it to the document tha= t proposes the extension to deal with determining whether send the DRMP AVP= or the newly defined DRMPv2 AVP. [JL] When we proposed that the range be extended to 16, we thought that '16= ' was large enough and future proof. I am okay with having an extensibility bit, if other companies want it. Tha= t said, I agree that it has a low probability of being used and added compl= exity. [JJ] JJ I also agree that with 16 values , the offered range is large enoug= h in practice. This point is only to check if it would be easy to do an ext= ension, if we have this requirement in the future. I agree with Steve that= for an extensibility, it will require a new AVP in a new document rather t= han to define a set of reserved values in the DRMP AVP. A point is that it= will require an additional parsing effort for a node to look for this seco= nd AVP even if it is not present most of the time. */ I am not sure of alternative encoding method (say, +9 to -9 per JJacques= ' proposal) compared to the current enumerated type of DRMP. It offers a lo= gical way of assigning a value 0 to the default case. But it offers less fl= exibility to operators, since the default value may not be easily moved to = have more higher/lower priority values. Also, we are used to the enumerated= type of DRMP and just want to have extension from 5 to 16, but this may r= equire more deviation from the current design and thinking. For this, I wou= ld like to see more on qualitative pros/cons, but, given its little benefit= , I am reluctant to accept this alternative. SRD> I agree that I don't see value in the +9 to -9 proposal. [JL] Agreed [J] I presented this second approach so to review the possible alternativ= es as we usually do before selecting the solution, this alternative being a= lready used in a recent RFC. That being said, I am fine with the enumerat= ed DRMP AVP. Best regards JJacques From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: Thursday, October 22, 2015 9:39 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Hi 1. PRIORITY_14 as default priority value only allows one level of lowe= r priority (PRIORITY_15) than the default one; this seems not enough. As = use cases, we may have some Machine type Communication (LTC) devices that = may have lower priorities that normal communications without priority. Eve= n within a Diameter application, some commands may have a lower priority as= having a secundary importance. Then which default value ? - it could be PRIORITY_8 in the middle, or if we prefer to have a l= arger range for higher priorities than for lower priorities, the default = value could be e.g. PRIORITY_10, giving 9 higher priorities and 5 lower p= riorities than the default one. I would have a preference for this value PR= IORITY_10. 2. About extensibility, the current range of 16 values is already larg= e, but we can have a reserved value to indicate a further extension. With = an enumerated AVP, there is no possibility to add new values. 3. I also had a look to some other IETF RFCs addressing priorities tha= t Ken mentioned, so to see if we can benefit from these approaches although= done for different contexts. - in RFC 4412 (Resource-Priority Header in SIP), wps and ets namespa= ces have a range of 5 values (0 to 4) with 0 as the highest priority . But= I have not found some indication (I may have missed it) about the default= priority (I mean a SIP request without Resource-Priority Header compared= to a SIP request with the Header). Implicitly, I would assume a SIP reque= st without Resource-Priority Header corresponds to the lowest priority. = DRMP has a similar approach but with a larger range and also lower priorit= ies. - RFC 6710 (priority for SMTP), uses another encoding of the prior= ity values with an integer between -9 and +9. Lower priorities are negativ= e an higher priority being positive. When a value increases, it means a hig= her priority, so the opposite to DRMP, wps or ets. But the value 0 is her= e naturally the default value. So this is an encoding alternative to the = Enumerated type of the DRMP AVP which avoids the question of the default va= lue. Note: RFC 6710 also defines some Priority Assignment Policies using a subs= et of the range. RFC 6710 has also this guideline : SMTP servers compliant with this specification are not required to support all 19 distinct priority levels (i.e., to treat each priority value as a separate priority), .... That is, an implementation that only supports N priority levels (where N < 19) will internally round up a syntactically valid priority value that isn't supported to the next higher supported number (or to the highest supported priority, if the value is higher than any supported pr= iority). - This raises the question to have this type of guideline if consid= ered useful. So to have your feedback Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C Envoy=E9 : jeudi 15 octobre 2015 12:33 =C0 : Lee, Jay; ken carlberg; Steve Donovan Cc : dime@ietf.org Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp)= : Range of priority levels) A couple thoughts: 1. There needs to be a default value defined by the standard, so that = equipment have the same value leaving the factory 2. This value can be over written based on local policy 3. Should have an extensibility bit in order to and more values in the= future From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay Sent: Thursday, October 15, 2015 6:16 AM To: ken carlberg >; Steve D= onovan > Cc: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) >From my side, some more discussion on Steve's mail may be needed. 'Should' vs. 'Must': One can say that 'Should' is not mandatory. But, in practice, this is a fai= rly strong statement, and often taken as required. So in this sense, the pr= oposed Note is certainly helpful. But, since we allow operators to override= the value, I don't see the reason why we use 'Should'. My suggestion is us= ing 'May'. PRIORITY_14 priority: Since operators can overwrite it, I was not too concerned about it. But if = we want to put some value, why '14'? A value lower than 14 is suggested in = order to allow more rooms for lower priorities. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg Sent: Wednesday, October 14, 2015 8:40 AM To: Steve Donovan Cc: dime@ietf.org Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): R= ange of priority levels) with respect to the diff-serv example brought up below, some thing to add t= o that discussion is that it starts off with separate and distinct forwardi= ng behavior whose marked packets provide segmentation of other IP traffic. = The availability of only 6 bits to play with (along with the headaches of = transitive trust) also discouraged a line of thought to define end-to-end p= riority handling versus a per diff-serv domain treatment. RFC-4594 did pro= vide configuration guidelines, but that's a different story. So back to a couple of ideas to consider. 1) reserved space. if we go back to the diff-serv model, the diff-serv wor= king group agreed to set aside a set of values that was reserved for experi= mental use that could be re-assigned some time in the future. I'm not sugg= esting that there should be space set side for experiments, but rather it m= ay be prudent to set aside a reserved set of bits/values so that one doesn'= t need to define a new AVP if in the future there was a need to define adde= d values beyond the 5 (plus some fudge factor) already mentioned on the lis= t. 2) sets of users. previous work (e.g., rfc-4412, rfc-6710) recognized that= there can be several sets of users/services that are distinct from each ot= her and yet need to prioritize the traffic. I bring this up because the dr= aft already identifies two sets of users in sections 5.1 and 5.2 (note: I'm= assuming that the latter is aimed at the general public and related to 911= /112/999 type calls, which should probably be more specific in the draft). = And there is also the potential of Firstnet users in the US. As a side note, the distinction and separation of general public and other = prioritized users in public phone infrastructures is not exclusive to the U= S, so the group should not be concerned that this is a US centric effort. = There has been GTPS in the UK, as well as other systems in other countries.= The RFC is a bit dated, but feel free to go over rfc-4190 for added backg= round. and just to reiterate. I'm not making recommendations in the above - just = bringing up some food for thought. -ken On Oct 14, 2015, at 10:12 AM, Steve Donovan > wrote: Jay, The current text is a SHOULD level requirement: When there is a mix of transactions specifying priority in request messages and transactions that do not have the priority specified, transactions that do not have a specified priority SHOULD be treated as having the PRIORITY_14 priority. As such, operators can choose to either not implement a priority or define = a different value for their network. I propose adding the following note after this paragraph to further explain= why it is a SHOULD and not a MUST: Note: There are scenarios where operators might want to specify a different default value for transactions that do not have an explicit priority. In this case, the operator defined local policy would override the use of PRIORITY_14 as the default priority. This leaves the ability for there to be deterministic behavior in Diameter = networks that require a default to be defined and are happy with the specif= ied default. It also gives operators the ability to define a different beh= avior, most likely with some priority handling/mapping at the edge of the n= etwork. Does this address your concerns? Regards, Steve On 10/14/15 2:59 AM, Lee, Jay wrote: Regarding the issue of whether we need to specify a default value or not, t= here are pros and cons. If we specify a value for the default case, we can see the benefits in scen= arios between different operator networks, but we take away important optio= ns on what operators can do with priority values. On the other hand, if we = do not specify the default value, operators may have more options, but ther= e is a question of what to do for this inter-PLMN cases when the networks m= ay use different default values. In practice, this issue can be addressed at the edge of the network, where = Diameter edge agent (DEA) can perform some priority mapping based on bilate= ral roaming agreement (or SLA (service level agreement)) and other means to= insure the proper handling. One may argue that this is not as good as the = 'deterministic' case, but operator should be able handle this in a reasonab= le way. We are fully aware of the fact that, in case of this 'non-determini= stic' case, the default value can differ from one operator network to anoth= er, and it becomes difficult to guarantee the intended priority handling. D= espite this, we still prefer giving options to operators by not specifying = the default value. What we are saying here, however, is not anything new. This is the typical = way of handling priority levels. If anything, specifying the default value = would be something new. As already mentioned in CT discussion, there is a g= ood example of this - Internet QoS, more specifically DiffServ. In order to guarantee end-to-end QoS for a specific service, IETF could hav= e specified a value (DiffServ codepoint) for the specific service to have p= redetermined handling of the traffic, but IETF did not. Instead, DiffServ s= imply provided a framework for operators to have its own classification an= d differentiated treatment of the services. To guarantee end-to-end QoS acr= oss different networks, then, operators need to do packet inspection, (re)c= lassification, QoS mapping, use of SLA and possibly others at the edge of n= etwork (edge router). Therefore, in the DiffServ architecture, intelligence= was pushed to the edge of the network. While the end results may not be gu= aranteed as well as in the case of predetermined handling, it was still a p= referred way to give flexibility to operators. My point is that we went thr= ough all these troubles to give options of priority handling to operators. By the way, if we are thinking of possibility of specifying the default val= ue, are we assuming that all operators are interested in this feature (defa= ult value in the middle, and high and low priorities at other ends)? Aren't= there other operators who are not interested in this feature? I know that = at least there is one - Verizon. We have no interest in this feature, and n= o plan for implementing it. We are OK, if other operators are interested in= this feature, and the default value is NOT specified. But we are certainly= not happy if DIME is trying to impose this on us. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, October 13, 2015 10:55 AM To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org; Pollini, Gregory P Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Assuming that we define a range of 3 values, Assuming that 0 is the lowest priority and 2 the highest, Assuming that an agent receives 4 messages at the same time while being in = overload control: * 1) ULR with Prio-0 * 2) ULR with Prio-1 * 3) ULR with Prio-2 * 4) ULR with no priority AVP Assuming that the default is locally defined as proposed below, How do you know that the ULR with priority 2 will be handled with a higher = priority than the request without priority indication? And what about ULR message with priority 1 with two levels of highest prior= ity e.g. emergency/Important and government/very important? Sorry if the answer is obvious but I fail to understand. Lionel De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] Envoy=E9 : samedi 3 octobre 2015 01:21 =C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C Cc : DiME; dime@ietf.org; Pollini, Gregory P Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels Hello all, Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.21= 2 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defi= ned. Having 15 rather than 16 would be useful from an interworking point of view= on Diameter interfaces connecting to the EPS. Also, my understanding has been that the default value is per local policy. My 2 cents.... Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf = of lionel.morand@orange.com [lionel.morand= @orange.com] Sent: Thursday, October 01, 2015 3:36 AM To: Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Hi, I think that the case "no Priority indication in request" is the default si= tuation today. So if we agree that it should be possible to explicitly indicate a request = with a lower priority, we should divide the range of priority values in thr= ee sub-ranges: [lower priorities][no priority indication][higher priorities= ], e.g. with 17 values: [0-7][8][9-16]. If any operator can freely fix the default value, there would be no way to = ensure the sender that a request with a specific priority value (e.g. 6) wi= ll be handled with a lower or higher priority than a request with no priori= ty indication. Therefore, for a deterministic handling mechanism, I think that it is then = more relevant to define a standard value for the default value. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn Envoy=E9 : mercredi 30 septembre 2015 22:53 =C0 : DOLLY, MARTIN C Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels Same here. The "default priority" should be a matter of local policy. Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "DOLLY, MARTIN C" > To: Steve Donovan >, "dime@ietf.org" > Date: 09/30/2015 04:40 PM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" = > ________________________________ Me as well From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, September 30, 2015 4:38 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels I'm okay with Jay's proposal on not specifying a default value. Steve On 9/30/15 3:27 PM, Lee, Jay wrote: Hi Steve and all, For the first proposal, as I indicated, I support increasing the number of = priority levels up to 16. I am also fine with the second proposal. My question is: do we need to mand= ate this feature, as individual operators have different situations? Perhap= s some flexibility should be allowed? Instead of mandating it, we can inclu= de the statement that when there is no DRMP AVP, this correspond to 'normal= traffic' without a particular high or low priority. Then each operator can= map this default to a value (e.g., 8 or something else) that they feel app= ropriate. Thanks, Jay _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_E194C2E18676714DACA9C3A2516265D29D46519FFR712WXCHMBA12z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 <= /p>

From the email threads ab= out draft-ietf-dime-drmp,  I think we now concluded  on the pendi= ng points with still a small  discussion about a range of 15 or 16 values on  which we should conclude.

 <= /p>

- = ;         On my side I was = OK with the initial  proposal of 16 values. For a mapping between a li= st A with a range of 15 values and  the DRMP range of 16 values , a simple one is to do 1 to 1 mapping except for the value 15th  and 16 th (lowest priorities) of the DRMP range  which would b= e mapped to the value  15 of the listA range. That being said, I have = no issue to use a  DRMP range of 15 value if some of us prefer.

 <= /p>

Regarding the draft  = ;I think  the unique Editor’s note in version 1 can be removed a= nd after integration of the conclusions in  new draft, I would be in f= avour to go towards the last call step.

 <= /p>

-  &n= bsp;       I hereafter give = some information to Dime-list about the process on 3GGP side.

Diameter  message Pr= iority is an important requirement for 3GPP which agreed on a Release 13 Wo= rk Item supported by many companies. 3GPP also decided  to use the draft-ietf-dime-drmp to fulfill this requirement and already agreed Ch= ange Requests to some specifications,  with an editor’s note &nb= sp;assuming that  draft-ietf-dime-drmp is stable enough to do so. Furt= her Change Request for other specifications will be submitted in the upcoming 3GPP meeting in November which is the last meeting for the= 3GPP Release 13.

 <= /p>

Our IETF dime work and co= nclusions drives me to consider that the draft has become stable –so = with my proposal that the updated version be submitted to the last call.  I am not so much familiar with IETF process, I hope my pr= oposal  follows the IETF procedures.

 <= /p>

Best regards

 <= /p>

JJacques

 <= /p>

 <= /p>

 <= /p>

De := DiME [mailto:dime-bounces@ietf.org] De la part de Lee, Jay
Envoy=E9 : vendredi 30 octobre 2015 11:10
=C0 : Shaikh, Viqar A; Steve Donovan; dime@ietf.org
Cc : Singh, Ray P; Lukacs, Donald R; Pollini, Gregory P
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime= ] #92 (drmp): Range of priority levels)

 

Please see my comments in= line.

 <= /p>

Jay

 <= /p>

From: Shaikh, Viqar A [mailto:vshaikh@appcomsci.com]
Sent: Thursday, October 29, 2015 12:59 PM
To: Steve Donovan; Lee, Jay; dime@i= etf.org
Cc: Singh, Ray P; Pollini, Gregory P; Lukacs, Donald R
Subject: RE: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Hello all,

 

My 2 cents:

 

Greater than 5 values for DRMP AVP is justified = and it appears there is agreement for 16.  However, note tha= t the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 t= akes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined. Ha= ving 15 rather than 16 for DRMP AVP would be useful from an interworking po= int of view on Diameter interfaces connecting to the EPS.

 

[JL] I can see that, if the same number (i.e.= , 15) is used on both sides, there may be one-to-one mapping. This interwor= king/mapping should be done as part of 3GPP DRMP WI, starting from next 3GPP CT4 meeting. But the mapping can be both one-to-one and one= -to-many (multiple). Even if the same number is used, I don’t know at= the moment that we can exclude the possibility of one-to-many mapping. So = I am not sure that we need to have the same number on both sides.

 

Regarding the default value - it is based on&nbs= p;operator policy and can be overwritten by an operator.  Therefore, w= e support use of "may" and not "should". 

 

[JL] Using ‘May’ is the consensus= do far.

 

We feel that 15 or 16 values should suffice and = there is no need to define an extension bit.  However, I am ok if= there is consensus to do so.

 

[JL] The consensus so far is that it is bette= r not to have the extension bit.

 

We feel there is no need to specify a defau= lt as it is per local policy and can be overwritten.  But, if there is= consensus to do so, we suggest value 10 or 11 with a note that it can be overwritten based on operator policy.

 

[JL] Initial assumption was that there is no = need to specify or even assign a default value, I believe. But then, there = was a proposal to specify the default value, making it mandatory. And then, there was also a proposal that, even if the default v= alue is not specified, we need to assign the default value that can be over= written in order to have common understanding for some reasons.

 

My personal thought on this matter is that th= ere is no need to specify or assign the number, as you also mentioned, and = this ‘do nothing’ may even be a majority view, since it was the initial assumption. But I am not certain, because not everyone voi= ced opinion. In this situation, a compromise had to be made. The compromise= is that we will assign the value ‘10’ to the default case with= the statement that the default value can be overwritten per local policy, and ‘May’ must be used instead o= f ‘Should’ in the current text. I think this compromise is cons= istent with your view.

 

Thoughts?

 

Thanks,

Viqar

 

From:<= /span> DiME [dime-bounces@ietf.org] on behalf of Steve Dono= van [srdonovan@usdonovans.com]
Sent: Wednesday, October 28, 2015 4:06 PM
To: Lee, Jay; dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

Ten is accept= able to me.

Steve

On October 28, 2015 1:36:00 PM "Lee, Jay" = <Jay.Lee@VerizonWireless.= com> wrote:

I also think that we agre= e on all different points for the finalization, except one point: the value= for the default case. Use of the default case as discussed here is rather in the future than in the present for us, so I do not have = strong opinion, especially when the default value can be overwritten.

 

Looking at this objective= ly and also for the sake of progress, however, it would be prudent to have = more than one lower priority cases. In the near future, we may identify additional use cases for lower priority case. Even with on= e use case identified, this does not necessarily mean one priority level pe= r use case. One use case may require multiple lower priority levels, depend= ing on applications.

 

Any value from 9 to 12 se= ems reasonable to me. But, without all use cases identified at the present = time, I propose 10 (JJacques’ proposal) or 11.

 

Thanks,=

 

Jay

 

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Monday, October 26, 2015 8:11 AM
To: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Hi

 

Please see my comments al= so in line. I think we are close to finalise our choice on the different po= ints  of this thread

 

Best regards<= /o:p>

 

JJacques

 

De := DiME [mailto:dime-bounces@ietf.org] De la part de Lee, Jay
Envoy=E9 : vendredi 23 octobre 2015 18:57
=C0 : dime@ietf.= org
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime= ] #92 (drmp): Range of priority levels)

 

Please see my comments in= line.

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Friday, October 23, 2015 8:02 AM
To: dime@ietf.org=
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Please see my comment= s inline.

Steve

On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote:

See inline

 

From: DiME [= mailto:dime-boun= ces@ietf.org] On Behalf Of Lee, Jay
Sent: Friday, October 23, 2015 1:59 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) <jean-jacques.trottin@alcatel-lucent.com>; dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Some further comments fro= m my side:

 

*/ If we need to assign (= but not specify) a value to the default case, we need to make it clear that= this value can be overwritten by operators, and the value is for some use cases like e.g., equipment having the same value when leav= ing the factory, so that there would be no misunderstanding.

mcd- ok=

SRD> I think the current proposed text makes this= clear.
[JL] Agree that the current text is OK especi= ally when we use ‘May’ in place of ‘Should’<= o:p>

[JJ] OK

.

 

*/ Since we agree that the default value is per local policy, ‘Ma= y’ is preferred to ‘Should’ in order not to cause confusi= on.

mcd-ok

SRD> I'm okay with making this a MAY.<= /p>

[JL]  Agreed<= o:p>

[JJ] Also in favor of a M= AY

 

*/ For assignment of the default value, I am quite open. But any value = between 9 – 12 seems reasonable to me.

mcd- value should allow f= or assigning lower values, though a carrier can assign what they want in th= eir network, there needs to be a common meaning at the interconnection point

SRD> I'm open to any value we decide on.  If= there are real use cases that require pushing the default value more to th= e middle then we should do so.  At this point I've heard one use case = for the default being something other then the lowest value, thus the proposal to use priority_14 as the default.  <= o:p>

[JJ] Regarding use cases,= there may be

- &nb= sp;        The case where for “normal” u= sers, an application use the default value for most of its requests except = some which have a lower priority

- &nb= sp;        the case where besides “normal̶= 1; user (and high priority users), some users have lower priorities, e.g. S= ome Machine type Communications (MTC) devices.

So potentially more than = one low priority level would be needed.

We also have chosen a rat= her large range of values (16) , allowing flexibility for an operator when = they define the number of priorities they want , leaving possibility to future additions. If PRIORITY _14 is the default, it leaves= only one lower priority and an operator  cannot add a second one &nbs= p;except by choosing  a default value other than the 14  value.

Then as, in practice, we = may expect a range of low priority smaller than  the range of high pri= ority values, this is why the default value was proposed to be in the range 9-12  . Then I proposed 10 so to do a proposal but I am = open on another value.

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       &! nbsp;&nbs p;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =           

*/  Current proposal of 16 values may be enough now, but I am fine= with having an extensibility bit to be future proof.

mcd-ok

SRD> I don't see a compelling argument to move be= yond 16. 
In addition, it isn't clear to me that there is value in defining an extens= ibility mechanism beyond what is already supported by Diameter.  Doing= so would add significant complexity to the DRMP mechanism for something th= at, in my view, has a low probability of being used.

I propose that we not allow extending the DRMP AVP.  Rather we require= that any extension require a new AVP.  We can then leave it to the do= cument that proposes the extension to deal with determining whether send th= e DRMP AVP or the newly defined DRMPv2 AVP. 
[JL] When we proposed that the range be exten= ded to 16, we thought that ‘16’ was large enough and future pro= of.

I am okay with having = an extensibility bit, if other companies want it. That said, I agree that i= t has a low probability of being used and added complexity.

[JJ] JJ I also agree t= hat with 16 values , the offered range is large enough in practice. This po= int is only to check if it would be easy to do an extension, if we have thi= s requirement in the future.  I agree with Steve that for an extensibility, it will require a new AVP in a new d= ocument rather than to define a set of reserved values in the DRMP AVP. &nb= sp;A point is that it will require an additional parsing effort for a node = to look for this second AVP even if it is not present most of the time.  

 

*/ I am not sure of alternative encoding method (say, +9 to -9 per = JJacques’ proposal) compared to the current enumerated type of DRMP. It offers a logical way of assigning a value 0 to the default case. = But it offers less flexibility to operators, since the default value may no= t be easily moved to have more higher/lower priority values. Also, we are u= sed to the enumerated type of DRMP and just want to have extension from 5 to 16,  but this may require m= ore deviation from the current design and thinking. For this, I would like = to see more on qualitative pros/cons, but, given its little benefit, I am r= eluctant to accept this alternative.

SRD> I agree that I don't see value in the +9= to -9 proposal.

[JL] Agreed

[J] I presented this seco= nd  approach  so to review the possible alternatives as we usuall= y do before selecting the solution, this alternative being already used in a recent RFC.   That being said, I am fine with the enum= erated DRMP AVP.

 

Best regards<= /o:p>

 

JJacques  

 

From: DiME [mailto:dime-bounce= s@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Thursday, October 22, 2015 9:39 AM
To: dime@ietf.org=
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Hi

 

1.      PRIORITY_14 as default priority value onl= y allows one level of lower priority (PRIORITY_15)  than the default o= ne; this seems not enough.  As use cases, we may have  some Machine type Communication (LTC) devices that may have lower priorities th= at normal communications without priority.  Even within a Diameter app= lication, some commands may have a lower priority as having a secundary imp= ortance.

 

Then which default  value ?

- &nb= sp;      it could be PRIORITY_8 in the middle, or = if we prefer to have a  larger range for higher priorities  than = for lower priorities,  the default value could be  e.g. PRIORITY_= 10,  giving 9 higher priorities and 5 lower priorities than the default one. I = would have a preference for this value PRIORITY_10.

 

2.      About extensibility, the current range of= 16 values is already large, but we can have  a reserved value to indi= cate a further extension. With  an enumerated AVP, there is no possibility to add new values. 

 

3.      I also had a look to some other IETF RFCs= addressing priorities that Ken mentioned, so to see if we can benefit from= these approaches although done for different contexts.

- &nb= sp;      in RFC 4412 (Resource-Priority Header in = SIP), wps and ets namespaces have a range of 5 values (0 to 4) with 0 as th= e highest priority  . But I have not found some indication  (I may have missed it) about the default priority  (I mean a SIP requ= est without  Resource-Priority Header compared  to a SIP request = with the Header). Implicitly, I would assume a SIP request without  Re= source-Priority Header corresponds to  the lowest priority.  DRMP has a similar approach but with  a larger range and also l= ower priorities.

 

- &nb= sp;      RFC  6710 (priority for SMTP),  = ;uses another encoding of the priority values with an integer between -9 an= d +9. Lower priorities  are negative an higher priority being posi= tive. When a value increases, it means a higher priority, so the opposite  = to DRMP, wps or ets.  But the value 0 is here naturally the default va= lue. So this is an encoding alternative  to the  Enumerated type = of the DRMP AVP which avoids the question of the default value.

Note: RFC  67= 10 also defines some Priority Assignment Policies using a subset of the ran= ge.

 

RFC 6710 has also this guideline :

   SMTP server= s compliant with this specification are not

   required to supp= ort all 19 distinct priority levels (i.e., to treat

   each priority va= lue as a separate priority), ….  That is, an

   implementation t= hat only supports N priority levels (where N < 19)

   will internally = round up a syntactically valid priority value that

   isn't supported = to the next higher supported number (or to the

   highest supporte= d priority, if the value is higher than any supported priority).

- &nb= sp;      This raises the question to have this typ= e of  guideline if considered useful.

 

So to have your feedback

 

Best regards<= /o:p>

 

JJacques

 

De : DiME= [mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C
Envoy=E9 : jeudi 15 octobre 2015 12:33
=C0 : Lee, Jay; ken carlberg; Steve Donovan
Cc : dime@ietf.org
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime= ] #92 (drmp): Range of priority levels)

 

A couple thoughts:=

1. &n= bsp;    There needs to be a default value defined= by the standard, so that equipment have the same value leaving the factory=

2. &n= bsp;    This value can be over written based on l= ocal policy

3. &n= bsp;    Should have an extensibility bit in order= to and more values in the future

 

 

From: DiME [= mailto:dime-boun= ces@ietf.org] On Behalf Of Lee, Jay
Sent: Thursday, October 15, 2015 6:16 AM
To: ken carlberg <carlberg@g11.org.uk>; Steve Donovan <srdonovan@usdonovans.com&= gt;
Cc: dime@ietf.org=
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

From my side, some more d= iscussion on Steve’s mail may be needed.

 

‘Should’ vs. = ‘Must’:

One can say that ‘S= hould’ is not mandatory. But, in practice, this is a fairly strong st= atement, and often taken as required. So in this sense, the proposed Note is certainly helpful. But, since we allow operators to override the v= alue, I don’t see the reason why we use ‘Should’. My sugg= estion is using ‘May’.

 

PRIORITY_14 priority:

Since operators can overw= rite it, I was not too concerned about it. But if we want to put some value= , why ‘14’? A value lower than 14 is suggested in order to allow more rooms for lower priorities.

 

Jay

 

From: DiME [mailto:dime-bounce= s@ietf.org] On Behalf Of ken carlberg
Sent: Wednesday, October 14, 2015 8:40 AM
To: Steve Donovan
Cc: dime@ietf.org=
Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (d= rmp): Range of priority levels)

 

with respect to the diff-serv example brought up bel= ow, some thing to add to that discussion is that it starts off with separat= e and distinct forwarding behavior whose marked packets provide segmentatio= n of other IP traffic.  The availability of only 6 bits to play with (along with the headaches of transitive trust)= also discouraged a line of thought to define end-to-end priority handling = versus a per diff-serv domain treatment.  RFC-4594 did provide configu= ration guidelines, but that’s a different story.

 

So back to a couple of ideas to consider.=

 

1) reserved space.  if we go back to the diff-s= erv model, the diff-serv working group agreed to set aside a set of values = that was reserved for experimental use that could be re-assigned some time = in the future.  I’m not suggesting that there should be space set side for experiments, but rather it may be prude= nt to set aside a reserved set of bits/values so that one doesn't need to d= efine a new AVP if in the future there was a need to define added values be= yond the 5 (plus some fudge factor) already mentioned on the list. 

 

2) sets of users.  previous work (e.g., rfc-441= 2, rfc-6710) recognized that there can be several sets of users/services th= at are distinct from each other and yet need to prioritize the traffic. &nb= sp;I bring this up because the draft already identifies two sets of users in sections 5.1 and 5.2 (note: I’m assu= ming that the latter is aimed at the general public and related to 911/112/= 999 type calls, which should probably be more specific in the draft).  = ;And there is also the potential of Firstnet users in the US.

 

As a side note, the distinction and separation of ge= neral public and other prioritized users in public phone infrastructures is= not exclusive to the US, so the group should not be concerned that this is= a US centric effort.  There has been GTPS in the UK, as well as other systems in other countries.  The RFC= is a bit dated, but feel free to go over rfc-4190 for added background.

 

and just to reiterate.  I’m not making re= commendations in the above — just bringing up some food for thought.<= o:p>

 

-ken

 

 

On Oct 14, 2015, at 10:12 AM, Steve Donovan <srdonovan@usdonov= ans.com> wrote:

 

Jay,

The current text is a SHOULD level require= ment:

   When there is a mix of transa= ctions specifying priority in request
   messages and transactions tha= t do not have the priority specified,
   transactions that do not have= a specified priority SHOULD be treated
   as having the PRIORITY_14 pri= ority.

As such, operators can choose to either no= t implement a priority or define a different value for their network.

I propose adding the following note after = this paragraph to further explain why it is a SHOULD and not a MUST:=

      Note: There= are scenarios where operators might want to 
      specify a d= ifferent default value for transactions that do not
      have an exp= licit priority.  In this case, the operator defined
      local polic= y would override the use of PRIORITY_14 as
      the default= priority.

This leaves the ability for there to be de= terministic behavior in Diameter networks that require a default to be defi= ned and are happy with the specified default.  It also gives operators= the ability to define a different behavior, most likely with some priority handling/mapping at the edge of the network= .

Does this address your concerns?
Regards,

Steve

On 10/14/15= 2:59 AM, Lee, Jay wrote:

 

 

 

 

 

 

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Tuesday, Oct= ober 13, 2015 10:55 AM
To: Shaikh, Viqar = A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; <= a href=3D"mailto:dime@ietf.org" target=3D"_blank">dime@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; Pollini, Gregory P
Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 

=B7     &nb= sp; 1) ULR with Prio-0

=B7     &nb= sp; 2) ULR with Prio-1

=B7     &nb= sp; 3) ULR with Prio-2

=B7     &nb= sp; 4) ULR with no priority AVP

 

 

 

 

 

 

De :<= /span> Shaikh, Viqar A [mailto:vshaikh@a= ppcomsci.com] 
Envoy=E9 : sa= medi 3 octobre 2015 01:21
=C0 : MORAND = Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; dime@ietf.org; Pollini, Gregory P
Objet : RE: [= Dime] [dime] #92 (drmp): Range of priority levels

 

Hello all,

 

Note tha= t the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 t= akes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined.

 

Having 15 rat= her than 16 would be useful from an interworking point of view on Diameter = interfaces connecting to the EPS.  

 

Also, my unde= rstanding has been that the default value is per local policy. 

 

My 2 cents....

Viqar 

<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">From: DiME [dime-bounces@i= etf.org] on behalf of lionel.morand@orange.com [lionel.= morand@orange.com]
Sent: Thursday, Oc= tober 01, 2015 3:36 AM
To: Janet P Gunn; = DOLLY, MARTIN C
Cc: DiME; dime@ietf.org
Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 

 

 

Regards,

 

Lionel

 

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn
Envoy=E9 : me= rcredi 30 septembre 2015 22:53
=C0 : DOLLY, = MARTIN C
Cc : DiME; dime@ie= tf.org
Objet : Re: [= Dime] [dime] #92 (drmp): Range of priority levels

 

Same here. &nb= sp;The "default priority" should be a matter of local policy. 

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose. 



From:        &= quot;DOLLY, MARTIN C" <md31= 35@att.com> 
To:        S= teve Donovan <srdonova= n@usdonovans.com>, "dime@ietf.org" <dime@ietf.org>&nbs= p;
Date:        0= 9/30/2015 04:40 PM 
Subject:        Re: [Dime] [dime] #92 (drmp): Range of priority levels 
Sent by:        "DiME" <dime-= bounces@ietf.org>




Me as well 
  
From: DiME [mailto:dime-bounces@iet= f.org]=  On Behalf Of Steve Dono= van
Sent: Wednesday, Sept= ember 30, 2015 4:38 PM
To: dime@ietf.org Subject: = ;Re: [Dime] [dime] #92 (drmp): Range of priority= levels 
  
I'm okay with Jay's proposal on not specifying a default value= .

Steve 
On 9/30/15 3:27 PM, Lee, Jay wrote: 
Hi Steve and all,=  
  
For the first proposal, as I indicated, I support increasing t= he number of priority levels up to 16. 
  
I am also fine with the second proposal. My question is: do we= need to mandate this feature, as individual operators have different situa= tions? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that when there is no DRMP A= VP, this correspond to ‘normal traffic’ without a particular hi= gh or low priority. Then each operator can map this default to a value (e.g= ., 8 or something else) that they feel appropriate. 
  
Thanks, 
  
Jay <= br>


__________________________________________= _____ 
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 d=
es informations confidentielles ou
privilegiees et ne doivent donc
pas etre
diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce
message par erreur, veuillez le signa=
ler
a l'expediteur

et le detruire ainsi que les pieces j=
ointes. Les messages electroniques


etant susceptibles d'alteration,


Orange decline

toute responsabilite si ce message a =
ete altere, deforme ou falsifie.


Merci.


 


This message


and its attachments may contain confidential or p=
rivileged 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 s=
ender and delete this


message and its attachments.

As emails may


be altered, Orange is not liable for messages tha=
t have been modified,


changed or falsified.


Thank


you.


_____________________________________=
___________________________________________________________________________=
_________
 
Ce message et
ses pieces jointes peuvent contenir d=
es informations confidentielles ou
privilegiees et ne doivent donc
pas etre
diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce
message par erreur, veuillez le signa=
ler
a l'expediteur

et le detruire ainsi que les pieces j=
ointes. Les messages electroniques


etant susceptibles d'alteration,


Orange decline

toute responsabilite si ce message a =
ete altere, deforme ou falsifie.


Merci.


 


This message


and its attachments may contain confidential or p=
rivileged 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 s=
ender and delete this


message and its attachments.

As emails may


be altered, Orange is not liable for messages tha=
t have been modified,


changed or falsified.


Thank


you.


&nbs=
p;


_______________________________________________


DiME mailing


list


DiME@ietf.org

https://www.ietf.org/m=
ailman/listinfo/dime


__________________________________________= _____
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailm= an/listinfo/dime

 

 

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

 

_____________________= __________________________
DiME mailing list
DiME@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dime

--_000_E194C2E18676714DACA9C3A2516265D29D46519FFR712WXCHMBA12z_-- From nobody Fri Oct 30 11:09:46 2015 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848391B2E84 for ; Fri, 30 Oct 2015 11:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkdreL3Hy2co for ; Fri, 30 Oct 2015 11:09:25 -0700 (PDT) Received: from eris.verizonwireless.com (eris.verizonwireless.com [137.188.99.119]) by ietfa.amsl.com (Postfix) with ESMTP id 30AD01B2EB2 for ; Fri, 30 Oct 2015 11:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizonwireless.com; i=@verizonwireless.com; q=dns/txt; s=prodmail; t=1446228551; x=1477764551; h=from:to:subject:date:references:in-reply-to:mime-version; bh=EoPyblcj3BxZ1PB1G64jq02kQO3qvIqDiyW4PlT7qxk=; b=LOyJpmZ+9VFKJPMQdMk06Y1Z71R83x7SwHW3TdZH72d4ZBYt0/oryCzc ESGTSic1H5mu5+Is3fO5xva9qGJ7R3IZ5FWZyfnwm8fe4HdlYY/cg47OA XAdWROo/Akve8VVoyaapAU1iU9ApVqbdhHzczigswoc3cq+FjQdkZiPai E=; X-Host: mariner.tdc.vzwcorp.com Received: from casac1exh003.uswin.ad.vzwcorp.com ([10.11.218.45]) by eris.verizonwireless.com with ESMTP/TLS/AES128-SHA; 30 Oct 2015 14:09:08 -0400 Received: from CASAC1EXP009.uswin.ad.vzwcorp.com ([fe80::558c:d7cc:1a42:f4d6]) by CASAC1EXH003.uswin.ad.vzwcorp.com ([fe80::ac7a:86c8:a3d2:d734%11]) with mapi id 14.03.0146.000; Fri, 30 Oct 2015 11:08:29 -0700 From: "Lee, Jay" To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" , "Shaikh, Viqar A" Thread-Topic: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) Thread-Index: AQHRBzKIwn0SbO3rXUW/ebDof+lRcp5sOcGAgAtoZjCAAZc3ZYAAEqiAgASJrNCAA3T5QIAAYjIAgAFJtOyAANeskIAAWVAggAA/5yA= Date: Fri, 30 Oct 2015 18:08:28 +0000 References: <20150930202736.3FFF61A8A56@ietfa.amsl.com> <560C4841.2090005@usdonovans.com> <2095_1443685006_560CE28E_2095_4215_1_6B7134B31289DC4FAF731D844122B36E01D3889E@OPEXCLILM43.corporate.adroot.infra.ftgroup> <341B32B15901F94185C9E67CAAE133030E252A9B@rrc-ats-exmb2.ats.atsinnovate.com> <20151014075941.062E21B2C1F@ietfa.amsl.com> <561E62C9.20500@usdonovans.com> <1431d0b2-5ae7-426e-b5ff-42b23fecbee5@CASAC1EXH002.uswin.ad.vzwcorp.com> <20151015101558.111761ACD5C@ietfa.amsl.com> <3e7a25c8-5eea-49a5-9905-3009c4dc45b8@NYORA1HUB001.uswin.ad.vzwcorp.com> <20151023055927.9223C1B3292@ietfa.amsl.com> <20151023165728.7D0E01A874F@ietfa.amsl.com> <20151028183455.88E9E1A899A@ietfa.amsl.com>, <150b00ed6f0.277f.0301301ad371d4c21d5a2092e0e442f2@usdonovans.com> <0c915451-c6b2-4644-80f8-f0cac6dff0b3@OHTWI1EXH001.uswin.ad.vzwcorp.com> <20151030100958.4CEBE1B2AAE@ietfa.amsl.com> <2069bb2d-b78d-41ff-adc7-903f6addb290@NYORA1HUB001.uswin.ad.vzwcorp.com> In-Reply-To: <2069bb2d-b78d-41ff-adc7-903f6addb290@NYORA1HUB001.uswin.ad.vzwcorp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.11.60.250] Content-Type: multipart/alternative; boundary="_000_C026C31E3CD6CA43953D6D95AB48048004A38CCASAC1EXP009uswin_" MIME-Version: 1.0 Message-Id: <20151030180911.30AD01B2EB2@ietfa.amsl.com> Archived-At: Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): Range of priority levels) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 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, 30 Oct 2015 18:09:45 -0000 --_000_C026C31E3CD6CA43953D6D95AB48048004A38CCASAC1EXP009uswin_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In the case of mapping, one-to many is common, so I have no issues with hav= ing the range of 16. The range of 15 is also OK, but with default value of = 10, we will have one less lower priority levels. >From practical point of view, this discussion may not be all that relevant.= 15 or 16 is a very large number, which were intended to be future proof. I= n the foreseeable future, we will not be using all 15 or 16 levels. If exac= t one-to-one mapping is preferred, it can be achieved without any issues, a= s only DRMP 3-8 levels would be used in practice. I prefer 16, but 15 is OK= , as it will not make any difference to us. Not sure if this point is even = worth debating or should be a pending point. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: Friday, October 30, 2015 10:15 AM To: dime@ietf.org; Shaikh, Viqar A Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): R= ange of priority levels) Hi >From the email threads about draft-ietf-dime-drmp, I think we now conclude= d on the pending points with still a small discussion about a range of 15= or 16 values on which we should conclude. - On my side I was OK with the initial proposal of 16 values. For= a mapping between a list A with a range of 15 values and the DRMP range o= f 16 values , a simple one is to do 1 to 1 mapping except for the value 15t= h and 16 th (lowest priorities) of the DRMP range which would be mapped t= o the value 15 of the listA range. That being said, I have no issue to use= a DRMP range of 15 value if some of us prefer. Regarding the draft I think the unique Editor's note in version 1 can be = removed and after integration of the conclusions in new draft, I would be = in favour to go towards the last call step. - I hereafter give some information to Dime-list about the process= on 3GGP side. Diameter message Priority is an important requirement for 3GPP which agree= d on a Release 13 Work Item supported by many companies. 3GPP also decided = to use the draft-ietf-dime-drmp to fulfill this requirement and already ag= reed Change Requests to some specifications, with an editor's note assumi= ng that draft-ietf-dime-drmp is stable enough to do so. Further Change Req= uest for other specifications will be submitted in the upcoming 3GPP meetin= g in November which is the last meeting for the 3GPP Release 13. Our IETF dime work and conclusions drives me to consider that the draft has= become stable -so with my proposal that the updated version be submitted t= o the last call. I am not so much familiar with IETF process, I hope my pr= oposal follows the IETF procedures. Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de Lee, Jay Envoy=E9 : vendredi 30 octobre 2015 11:10 =C0 : Shaikh, Viqar A; Steve Donovan; dime@ietf.org Cc : Singh, Ray P; Lukacs, Donald R; Pollini, Gregory P Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp)= : Range of priority levels) Please see my comments inline. Jay From: Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] Sent: Thursday, October 29, 2015 12:59 PM To: Steve Donovan; Lee, Jay; dime@ietf.org Cc: Singh, Ray P; Pollini, Gregory P; Lukacs, Donald R Subject: RE: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Hello all, My 2 cents: Greater than 5 values for DRMP AVP is justified and it appears there is agr= eement for 16. However, note that the 3GPP priority, e.g., Priority-Level = AVP (ARP AVP) in TS 29.212 takes 15 values, value 1 the highest, 15 the low= est, and value 0 not defined. Having 15 rather than 16 for DRMP AVP would b= e useful from an interworking point of view on Diameter interfaces connecti= ng to the EPS. [JL] I can see that, if the same number (i.e., 15) is used on both sides, t= here may be one-to-one mapping. This interworking/mapping should be done as= part of 3GPP DRMP WI, starting from next 3GPP CT4 meeting. But the mapping= can be both one-to-one and one-to-many (multiple). Even if the same number= is used, I don't know at the moment that we can exclude the possibility of= one-to-many mapping. So I am not sure that we need to have the same number= on both sides. Regarding the default value - it is based on operator policy and can be ove= rwritten by an operator. Therefore, we support use of "may" and not "shoul= d". [JL] Using 'May' is the consensus do far. We feel that 15 or 16 values should suffice and there is no need to define = an extension bit. However, I am ok if there is consensus to do so. [JL] The consensus so far is that it is better not to have the extension bi= t. We feel there is no need to specify a default as it is per local policy and= can be overwritten. But, if there is consensus to do so, we suggest value= 10 or 11 with a note that it can be overwritten based on operator policy. [JL] Initial assumption was that there is no need to specify or even assign= a default value, I believe. But then, there was a proposal to specify the = default value, making it mandatory. And then, there was also a proposal tha= t, even if the default value is not specified, we need to assign the defaul= t value that can be overwritten in order to have common understanding for s= ome reasons. My personal thought on this matter is that there is no need to specify or a= ssign the number, as you also mentioned, and this 'do nothing' may even be = a majority view, since it was the initial assumption. But I am not certain,= because not everyone voiced opinion. In this situation, a compromise had t= o be made. The compromise is that we will assign the value '10' to the defa= ult case with the statement that the default value can be overwritten per l= ocal policy, and 'May' must be used instead of 'Should' in the current text= . I think this compromise is consistent with your view. Thoughts? Thanks, Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf of Steve Donovan [srdonovan@us= donovans.com] Sent: Wednesday, October 28, 2015 4:06 PM To: Lee, Jay; dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Ten is acceptable to me. Steve On October 28, 2015 1:36:00 PM "Lee, Jay" > wrote: I also think that we agree on all different points for the finalization, ex= cept one point: the value for the default case. Use of the default case as = discussed here is rather in the future than in the present for us, so I do = not have strong opinion, especially when the default value can be overwritt= en. Looking at this objectively and also for the sake of progress, however, it = would be prudent to have more than one lower priority cases. In the near fu= ture, we may identify additional use cases for lower priority case. Even wi= th one use case identified, this does not necessarily mean one priority lev= el per use case. One use case may require multiple lower priority levels, d= epending on applications. Any value from 9 to 12 seems reasonable to me. But, without all use cases i= dentified at the present time, I propose 10 (JJacques' proposal) or 11. Thanks, Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: Monday, October 26, 2015 8:11 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Hi Please see my comments also in line. I think we are close to finalise our c= hoice on the different points of this thread Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de Lee, Jay Envoy=E9 : vendredi 23 octobre 2015 18:57 =C0 : dime@ietf.org Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp)= : Range of priority levels) Please see my comments inline. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Friday, October 23, 2015 8:02 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Please see my comments inline. Steve On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote: See inline From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay Sent: Friday, October 23, 2015 1:59 AM To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) ; dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Some further comments from my side: */ If we need to assign (but not specify) a value to the default case, we n= eed to make it clear that this value can be overwritten by operators, and t= he value is for some use cases like e.g., equipment having the same value w= hen leaving the factory, so that there would be no misunderstanding. mcd- ok SRD> I think the current proposed text makes this clear. [JL] Agree that the current text is OK especially when we use 'May' in plac= e of 'Should' [JJ] OK . */ Since we agree that the default value is per local policy, 'May' is pref= erred to 'Should' in order not to cause confusion. mcd-ok SRD> I'm okay with making this a MAY. [JL] Agreed [JJ] Also in favor of a MAY */ For assignment of the default value, I am quite open. But any value betw= een 9 - 12 seems reasonable to me. mcd- value should allow for assigning lower values, though a carrier can as= sign what they want in their network, there needs to be a common meaning at= the interconnection point SRD> I'm open to any value we decide on. If there are real use cases that = require pushing the default value more to the middle then we should do so. = At this point I've heard one use case for the default being something othe= r then the lowest value, thus the proposal to use priority_14 as the defaul= t. [JJ] Regarding use cases, there may be - The case where for "normal" users, an application use the defaul= t value for most of its requests except some which have a lower priority - the case where besides "normal" user (and high priority users), = some users have lower priorities, e.g. Some Machine type Communications (MT= C) devices. So potentially more than one low priority level would be needed. We also have chosen a rather large range of values (16) , allowing flexibil= ity for an operator when they define the number of priorities they want , l= eaving possibility to future additions. If PRIORITY _14 is the default, it = leaves only one lower priority and an operator cannot add a second one ex= cept by choosing a default value other than the 14 value. Then as, in practice, we may expect a range of low priority smaller than t= he range of high priority values, this is why the default value was propose= d to be in the range 9-12 . Then I proposed 10 so to do a proposal but I a= m open on another value. = &= ! nbsp;&nbs p; */ Current proposal of 16 values may be enough now, but I am fine with hav= ing an extensibility bit to be future proof. mcd-ok SRD> I don't see a compelling argument to move beyond 16. In addition, it isn't clear to me that there is value in defining an extens= ibility mechanism beyond what is already supported by Diameter. Doing so w= ould add significant complexity to the DRMP mechanism for something that, i= n my view, has a low probability of being used. I propose that we not allow extending the DRMP AVP. Rather we require that= any extension require a new AVP. We can then leave it to the document tha= t proposes the extension to deal with determining whether send the DRMP AVP= or the newly defined DRMPv2 AVP. [JL] When we proposed that the range be extended to 16, we thought that '16= ' was large enough and future proof. I am okay with having an extensibility bit, if other companies want it. Tha= t said, I agree that it has a low probability of being used and added compl= exity. [JJ] JJ I also agree that with 16 values , the offered range is large enoug= h in practice. This point is only to check if it would be easy to do an ext= ension, if we have this requirement in the future. I agree with Steve that= for an extensibility, it will require a new AVP in a new document rather t= han to define a set of reserved values in the DRMP AVP. A point is that it= will require an additional parsing effort for a node to look for this seco= nd AVP even if it is not present most of the time. */ I am not sure of alternative encoding method (say, +9 to -9 per JJacques= ' proposal) compared to the current enumerated type of DRMP. It offers a lo= gical way of assigning a value 0 to the default case. But it offers less fl= exibility to operators, since the default value may not be easily moved to = have more higher/lower priority values. Also, we are used to the enumerated= type of DRMP and just want to have extension from 5 to 16, but this may r= equire more deviation from the current design and thinking. For this, I wou= ld like to see more on qualitative pros/cons, but, given its little benefit= , I am reluctant to accept this alternative. SRD> I agree that I don't see value in the +9 to -9 proposal. [JL] Agreed [J] I presented this second approach so to review the possible alternativ= es as we usually do before selecting the solution, this alternative being a= lready used in a recent RFC. That being said, I am fine with the enumerat= ed DRMP AVP. Best regards JJacques From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: Thursday, October 22, 2015 9:39 AM To: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) Hi 1. PRIORITY_14 as default priority value only allows one level of lowe= r priority (PRIORITY_15) than the default one; this seems not enough. As = use cases, we may have some Machine type Communication (LTC) devices that = may have lower priorities that normal communications without priority. Eve= n within a Diameter application, some commands may have a lower priority as= having a secundary importance. Then which default value ? - it could be PRIORITY_8 in the middle, or if we prefer to have a l= arger range for higher priorities than for lower priorities, the default = value could be e.g. PRIORITY_10, giving 9 higher priorities and 5 lower p= riorities than the default one. I would have a preference for this value PR= IORITY_10. 2. About extensibility, the current range of 16 values is already larg= e, but we can have a reserved value to indicate a further extension. With = an enumerated AVP, there is no possibility to add new values. 3. I also had a look to some other IETF RFCs addressing priorities tha= t Ken mentioned, so to see if we can benefit from these approaches although= done for different contexts. - in RFC 4412 (Resource-Priority Header in SIP), wps and ets namespa= ces have a range of 5 values (0 to 4) with 0 as the highest priority . But= I have not found some indication (I may have missed it) about the default= priority (I mean a SIP request without Resource-Priority Header compared= to a SIP request with the Header). Implicitly, I would assume a SIP reque= st without Resource-Priority Header corresponds to the lowest priority. = DRMP has a similar approach but with a larger range and also lower priorit= ies. - RFC 6710 (priority for SMTP), uses another encoding of the prior= ity values with an integer between -9 and +9. Lower priorities are negativ= e an higher priority being positive. When a value increases, it means a hig= her priority, so the opposite to DRMP, wps or ets. But the value 0 is her= e naturally the default value. So this is an encoding alternative to the = Enumerated type of the DRMP AVP which avoids the question of the default va= lue. Note: RFC 6710 also defines some Priority Assignment Policies using a subs= et of the range. RFC 6710 has also this guideline : SMTP servers compliant with this specification are not required to support all 19 distinct priority levels (i.e., to treat each priority value as a separate priority), .... That is, an implementation that only supports N priority levels (where N < 19) will internally round up a syntactically valid priority value that isn't supported to the next higher supported number (or to the highest supported priority, if the value is higher than any supported pr= iority). - This raises the question to have this type of guideline if consid= ered useful. So to have your feedback Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C Envoy=E9 : jeudi 15 octobre 2015 12:33 =C0 : Lee, Jay; ken carlberg; Steve Donovan Cc : dime@ietf.org Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp)= : Range of priority levels) A couple thoughts: 1. There needs to be a default value defined by the standard, so that = equipment have the same value leaving the factory 2. This value can be over written based on local policy 3. Should have an extensibility bit in order to and more values in the= future From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Lee, Jay Sent: Thursday, October 15, 2015 6:16 AM To: ken carlberg >; Steve D= onovan > Cc: dime@ietf.org Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp= ): Range of priority levels) >From my side, some more discussion on Steve's mail may be needed. 'Should' vs. 'Must': One can say that 'Should' is not mandatory. But, in practice, this is a fai= rly strong statement, and often taken as required. So in this sense, the pr= oposed Note is certainly helpful. But, since we allow operators to override= the value, I don't see the reason why we use 'Should'. My suggestion is us= ing 'May'. PRIORITY_14 priority: Since operators can overwrite it, I was not too concerned about it. But if = we want to put some value, why '14'? A value lower than 14 is suggested in = order to allow more rooms for lower priorities. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ken carlberg Sent: Wednesday, October 14, 2015 8:40 AM To: Steve Donovan Cc: dime@ietf.org Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (drmp): R= ange of priority levels) with respect to the diff-serv example brought up below, some thing to add t= o that discussion is that it starts off with separate and distinct forwardi= ng behavior whose marked packets provide segmentation of other IP traffic. = The availability of only 6 bits to play with (along with the headaches of = transitive trust) also discouraged a line of thought to define end-to-end p= riority handling versus a per diff-serv domain treatment. RFC-4594 did pro= vide configuration guidelines, but that's a different story. So back to a couple of ideas to consider. 1) reserved space. if we go back to the diff-serv model, the diff-serv wor= king group agreed to set aside a set of values that was reserved for experi= mental use that could be re-assigned some time in the future. I'm not sugg= esting that there should be space set side for experiments, but rather it m= ay be prudent to set aside a reserved set of bits/values so that one doesn'= t need to define a new AVP if in the future there was a need to define adde= d values beyond the 5 (plus some fudge factor) already mentioned on the lis= t. 2) sets of users. previous work (e.g., rfc-4412, rfc-6710) recognized that= there can be several sets of users/services that are distinct from each ot= her and yet need to prioritize the traffic. I bring this up because the dr= aft already identifies two sets of users in sections 5.1 and 5.2 (note: I'm= assuming that the latter is aimed at the general public and related to 911= /112/999 type calls, which should probably be more specific in the draft). = And there is also the potential of Firstnet users in the US. As a side note, the distinction and separation of general public and other = prioritized users in public phone infrastructures is not exclusive to the U= S, so the group should not be concerned that this is a US centric effort. = There has been GTPS in the UK, as well as other systems in other countries.= The RFC is a bit dated, but feel free to go over rfc-4190 for added backg= round. and just to reiterate. I'm not making recommendations in the above - just = bringing up some food for thought. -ken On Oct 14, 2015, at 10:12 AM, Steve Donovan > wrote: Jay, The current text is a SHOULD level requirement: When there is a mix of transactions specifying priority in request messages and transactions that do not have the priority specified, transactions that do not have a specified priority SHOULD be treated as having the PRIORITY_14 priority. As such, operators can choose to either not implement a priority or define = a different value for their network. I propose adding the following note after this paragraph to further explain= why it is a SHOULD and not a MUST: Note: There are scenarios where operators might want to specify a different default value for transactions that do not have an explicit priority. In this case, the operator defined local policy would override the use of PRIORITY_14 as the default priority. This leaves the ability for there to be deterministic behavior in Diameter = networks that require a default to be defined and are happy with the specif= ied default. It also gives operators the ability to define a different beh= avior, most likely with some priority handling/mapping at the edge of the n= etwork. Does this address your concerns? Regards, Steve On 10/14/15 2:59 AM, Lee, Jay wrote: Regarding the issue of whether we need to specify a default value or not, t= here are pros and cons. If we specify a value for the default case, we can see the benefits in scen= arios between different operator networks, but we take away important optio= ns on what operators can do with priority values. On the other hand, if we = do not specify the default value, operators may have more options, but ther= e is a question of what to do for this inter-PLMN cases when the networks m= ay use different default values. In practice, this issue can be addressed at the edge of the network, where = Diameter edge agent (DEA) can perform some priority mapping based on bilate= ral roaming agreement (or SLA (service level agreement)) and other means to= insure the proper handling. One may argue that this is not as good as the = 'deterministic' case, but operator should be able handle this in a reasonab= le way. We are fully aware of the fact that, in case of this 'non-determini= stic' case, the default value can differ from one operator network to anoth= er, and it becomes difficult to guarantee the intended priority handling. D= espite this, we still prefer giving options to operators by not specifying = the default value. What we are saying here, however, is not anything new. This is the typical = way of handling priority levels. If anything, specifying the default value = would be something new. As already mentioned in CT discussion, there is a g= ood example of this - Internet QoS, more specifically DiffServ. In order to guarantee end-to-end QoS for a specific service, IETF could hav= e specified a value (DiffServ codepoint) for the specific service to have p= redetermined handling of the traffic, but IETF did not. Instead, DiffServ s= imply provided a framework for operators to have its own classification an= d differentiated treatment of the services. To guarantee end-to-end QoS acr= oss different networks, then, operators need to do packet inspection, (re)c= lassification, QoS mapping, use of SLA and possibly others at the edge of n= etwork (edge router). Therefore, in the DiffServ architecture, intelligence= was pushed to the edge of the network. While the end results may not be gu= aranteed as well as in the case of predetermined handling, it was still a p= referred way to give flexibility to operators. My point is that we went thr= ough all these troubles to give options of priority handling to operators. By the way, if we are thinking of possibility of specifying the default val= ue, are we assuming that all operators are interested in this feature (defa= ult value in the middle, and high and low priorities at other ends)? Aren't= there other operators who are not interested in this feature? I know that = at least there is one - Verizon. We have no interest in this feature, and n= o plan for implementing it. We are OK, if other operators are interested in= this feature, and the default value is NOT specified. But we are certainly= not happy if DIME is trying to impose this on us. Jay From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange= .com Sent: Tuesday, October 13, 2015 10:55 AM To: Shaikh, Viqar A; Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org; Pollini, Gregory P Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Assuming that we define a range of 3 values, Assuming that 0 is the lowest priority and 2 the highest, Assuming that an agent receives 4 messages at the same time while being in = overload control: * 1) ULR with Prio-0 * 2) ULR with Prio-1 * 3) ULR with Prio-2 * 4) ULR with no priority AVP Assuming that the default is locally defined as proposed below, How do you know that the ULR with priority 2 will be handled with a higher = priority than the request without priority indication? And what about ULR message with priority 1 with two levels of highest prior= ity e.g. emergency/Important and government/very important? Sorry if the answer is obvious but I fail to understand. Lionel De : Shaikh, Viqar A [mailto:vshaikh@appcomsci.com] Envoy=E9 : samedi 3 octobre 2015 01:21 =C0 : MORAND Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C Cc : DiME; dime@ietf.org; Pollini, Gregory P Objet : RE: [Dime] [dime] #92 (drmp): Range of priority levels Hello all, Note that the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.21= 2 takes 15 values, value 1 the highest, 15 the lowest, and value 0 not defi= ned. Having 15 rather than 16 would be useful from an interworking point of view= on Diameter interfaces connecting to the EPS. Also, my understanding has been that the default value is per local policy. My 2 cents.... Viqar ________________________________ From: DiME [dime-bounces@ietf.org] on behalf = of lionel.morand@orange.com [lionel.morand= @orange.com] Sent: Thursday, October 01, 2015 3:36 AM To: Janet P Gunn; DOLLY, MARTIN C Cc: DiME; dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Hi, I think that the case "no Priority indication in request" is the default si= tuation today. So if we agree that it should be possible to explicitly indicate a request = with a lower priority, we should divide the range of priority values in thr= ee sub-ranges: [lower priorities][no priority indication][higher priorities= ], e.g. with 17 values: [0-7][8][9-16]. If any operator can freely fix the default value, there would be no way to = ensure the sender that a request with a specific priority value (e.g. 6) wi= ll be handled with a lower or higher priority than a request with no priori= ty indication. Therefore, for a deterministic handling mechanism, I think that it is then = more relevant to define a standard value for the default value. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn Envoy=E9 : mercredi 30 septembre 2015 22:53 =C0 : DOLLY, MARTIN C Cc : DiME; dime@ietf.org Objet : Re: [Dime] [dime] #92 (drmp): Range of priority levels Same here. The "default priority" should be a matter of local policy. Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: "DOLLY, MARTIN C" > To: Steve Donovan >, "dime@ietf.org" > Date: 09/30/2015 04:40 PM Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels Sent by: "DiME" = > ________________________________ Me as well From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: Wednesday, September 30, 2015 4:38 PM To: dime@ietf.org Subject: Re: [Dime] [dime] #92 (drmp): Range of priority levels I'm okay with Jay's proposal on not specifying a default value. Steve On 9/30/15 3:27 PM, Lee, Jay wrote: Hi Steve and all, For the first proposal, as I indicated, I support increasing the number of = priority levels up to 16. I am also fine with the second proposal. My question is: do we need to mand= ate this feature, as individual operators have different situations? Perhap= s some flexibility should be allowed? Instead of mandating it, we can inclu= de the statement that when there is no DRMP AVP, this correspond to 'normal= traffic' without a particular high or low priority. Then each operator can= map this default to a value (e.g., 8 or something else) that they feel app= ropriate. Thanks, Jay _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_C026C31E3CD6CA43953D6D95AB48048004A38CCASAC1EXP009uswin_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

In the case of mapping, o= ne-to many is common, so I have no issues with having the range of 16. The = range of 15 is also OK, but with default value of 10, we will have one less lower priority levels.

 <= /p>

From practical point of v= iew, this discussion may not be all that relevant. 15 or 16 is a very large= number, which were intended to be future proof. In the foreseeable future, we will not be using all 15 or 16 levels. If exact one= -to-one mapping is preferred, it can be achieved without any issues, as onl= y DRMP 3-8 levels would be used in practice. I prefer 16, but 15 is OK, as = it will not make any difference to us. Not sure if this point is even worth debating or should be a pendin= g point.

 <= /p>

Jay

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Friday, October 30, 2015 10:15 AM
To: dime@ietf.org; Shaikh, Viqar A
Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (d= rmp): Range of priority levels)

 

Hi

 <= /p>

From the email threads ab= out draft-ietf-dime-drmp,  I think we now concluded  on the pendi= ng points with still a small  discussion about a range of 15 or 16 values on  which we should conclude.

 <= /p>

- =          On my side I was = OK with the initial  proposal of 16 values. For a mapping between a li= st A with a range of 15 values and  the DRMP range of 16 values , a simple one is to do 1 to 1 mapping except for the value 15th  and 16 th (lowest priorities) of the DRMP range  which would b= e mapped to the value  15 of the listA range. That being said, I have = no issue to use a  DRMP range of 15 value if some of us prefer.

 <= /p>

Regarding the draft  = ;I think  the unique Editor’s note in version 1 can be removed a= nd after integration of the conclusions in  new draft, I would be in f= avour to go towards the last call step.

 <= /p>

-  &n= bsp;       I hereafter give = some information to Dime-list about the process on 3GGP side.

Diameter  message Pr= iority is an important requirement for 3GPP which agreed on a Release 13 Wo= rk Item supported by many companies. 3GPP also decided  to use the draft-ietf-dime-drmp to fulfill this requirement and already agreed Ch= ange Requests to some specifications,  with an editor’s note &nb= sp;assuming that  draft-ietf-dime-drmp is stable enough to do so. Furt= her Change Request for other specifications will be submitted in the upcoming 3GPP meeting in November which is the last meeting for the= 3GPP Release 13.

 <= /p>

Our IETF dime work and co= nclusions drives me to consider that the draft has become stable –so = with my proposal that the updated version be submitted to the last call.  I am not so much familiar with IETF process, I hope my pr= oposal  follows the IETF procedures.

 <= /p>

Best regards

 <= /p>

JJacques

 <= /p>

 <= /p>

 <= /p>

De := DiME [mailto:dime-bounces@ietf.org] De la part de Lee, Jay
Envoy=E9 : vendredi 30 octobre 2015 11:10
=C0 : Shaikh, Viqar A; Steve Donovan; dime@ietf.org
Cc : Singh, Ray P; Lukacs, Donald R; Pollini, Gregory P
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime= ] #92 (drmp): Range of priority levels)

 

Please see my comments in= line.

 <= /p>

Jay

 <= /p>

From: Shaikh, Viqar A [mailto:vshaikh@appcomsci.com]
Sent: Thursday, October 29, 2015 12:59 PM
To: Steve Donovan; Lee, Jay; dime@i= etf.org
Cc: Singh, Ray P; Pollini, Gregory P; Lukacs, Donald R
Subject: RE: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Hello all,

 

My 2 cents:

 

Greater than 5 values for DRMP AVP is justified = and it appears there is agreement for 16.  However, note tha= t the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 t= akes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined. Ha= ving 15 rather than 16 for DRMP AVP would be useful from an interworking po= int of view on Diameter interfaces connecting to the EPS.

 

[JL] I can see that, if the same number (i.e.= , 15) is used on both sides, there may be one-to-one mapping. This interwor= king/mapping should be done as part of 3GPP DRMP WI, starting from next 3GPP CT4 meeting. But the mapping can be both one-to-one and one= -to-many (multiple). Even if the same number is used, I don’t know at= the moment that we can exclude the possibility of one-to-many mapping. So = I am not sure that we need to have the same number on both sides.

 

Regarding the default value - it is based on&nbs= p;operator policy and can be overwritten by an operator.  Therefore, w= e support use of "may" and not "should". 

 

[JL] Using ‘May’ is the consensus= do far.

 

We feel that 15 or 16 values should suffice and = there is no need to define an extension bit.  However, I am ok if= there is consensus to do so.

 

[JL] The consensus so far is that it is bette= r not to have the extension bit.

 

We feel there is no need to specify a defau= lt as it is per local policy and can be overwritten.  But, if there is= consensus to do so, we suggest value 10 or 11 with a note that it can be overwritten based on operator policy.

 

[JL] Initial assumption was that there is no = need to specify or even assign a default value, I believe. But then, there = was a proposal to specify the default value, making it mandatory. And then, there was also a proposal that, even if the default v= alue is not specified, we need to assign the default value that can be over= written in order to have common understanding for some reasons.

 

My personal thought on this matter is that th= ere is no need to specify or assign the number, as you also mentioned, and = this ‘do nothing’ may even be a majority view, since it was the initial assumption. But I am not certain, because not everyone voi= ced opinion. In this situation, a compromise had to be made. The compromise= is that we will assign the value ‘10’ to the default case with= the statement that the default value can be overwritten per local policy, and ‘May’ must be used instead o= f ‘Should’ in the current text. I think this compromise is cons= istent with your view.

 

Thoughts?

 

Thanks,

Viqar

 

From:<= /span> DiME [dime-bounces@ietf.org] on behalf of Steve Dono= van [srdonovan@usdonovans.com]
Sent: Wednesday, October 28, 2015 4:06 PM
To: Lee, Jay; dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

Ten is accept= able to me.

Steve

On October 28, 2015 1:36:00 PM "Lee, Jay" = <Jay.Lee@VerizonWireless.= com> wrote:

I also think that we agre= e on all different points for the finalization, except one point: the value= for the default case. Use of the default case as discussed here is rather in the future than in the present for us, so I do not have = strong opinion, especially when the default value can be overwritten.

 

Looking at this objective= ly and also for the sake of progress, however, it would be prudent to have = more than one lower priority cases. In the near future, we may identify additional use cases for lower priority case. Even with on= e use case identified, this does not necessarily mean one priority level pe= r use case. One use case may require multiple lower priority levels, depend= ing on applications.

 

Any value from 9 to 12 se= ems reasonable to me. But, without all use cases identified at the present = time, I propose 10 (JJacques’ proposal) or 11.

 

Thanks,=

 

Jay

 

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Monday, October 26, 2015 8:11 AM
To: dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Hi

 

Please see my comments al= so in line. I think we are close to finalise our choice on the different po= ints  of this thread

 

Best regards<= /o:p>

 

JJacques

 

De := DiME [mailto:dime-bounces@ietf.org] De la part de Lee, Jay
Envoy=E9 : vendredi 23 octobre 2015 18:57
=C0 : dime@ietf.= org
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime= ] #92 (drmp): Range of priority levels)

 

Please see my comments in= line.

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Friday, October 23, 2015 8:02 AM
To: dime@ietf.org=
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Please see my comment= s inline.

Steve

On 10/23/15 4:00 AM, DOLLY, MARTIN C wrote:

See inline

 

From: DiME [= mailto:dime-boun= ces@ietf.org] On Behalf Of Lee, Jay
Sent: Friday, October 23, 2015 1:59 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) <jean-jacques.trottin@alcatel-lucent.com>; dime@ietf.org
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Some further comments fro= m my side:

 

*/ If we need to assign (= but not specify) a value to the default case, we need to make it clear that= this value can be overwritten by operators, and the value is for some use cases like e.g., equipment having the same value when leav= ing the factory, so that there would be no misunderstanding.

mcd- ok=

SRD> I think the current proposed text makes this= clear.
[JL] Agree that the current text is OK especi= ally when we use ‘May’ in place of ‘Should’<= o:p>

[JJ] OK

.

 

mcd-ok

SRD> I'm okay with making this a MAY.<= /p>

[JL]  Agreed<= o:p>

[JJ] Also in favor of a M= AY

 

mcd- value should allow f= or assigning lower values, though a carrier can assign what they want in th= eir network, there needs to be a common meaning at the interconnection point

SRD> I'm open to any value we decide on.  If= there are real use cases that require pushing the default value more to th= e middle then we should do so.  At this point I've heard one use case = for the default being something other then the lowest value, thus the proposal to use priority_14 as the default.  <= o:p>

[JJ] Regarding use cases,= there may be

- &nbs= p;        The case where for “normal” u= sers, an application use the default value for most of its requests except = some which have a lower priority

- &nbs= p;        the case where besides “normal̶= 1; user (and high priority users), some users have lower priorities, e.g. S= ome Machine type Communications (MTC) devices.

So potentially more than = one low priority level would be needed.

We also have chosen a rat= her large range of values (16) , allowing flexibility for an operator when = they define the number of priorities they want , leaving possibility to future additions. If PRIORITY _14 is the default, it leaves= only one lower priority and an operator  cannot add a second one &nbs= p;except by choosing  a default value other than the 14  value.

Then as, in practice, we = may expect a range of low priority smaller than  the range of high pri= ority values, this is why the default value was proposed to be in the range 9-12  . Then I proposed 10 so to do a proposal but I am = open on another value.

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       &! nbsp;&nbs p;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =           

mcd-ok

SRD> I don't see a compelling argument to move be= yond 16. 
In addition, it isn't clear to me that there is value in defining an extens= ibility mechanism beyond what is already supported by Diameter.  Doing= so would add significant complexity to the DRMP mechanism for something th= at, in my view, has a low probability of being used.

I propose that we not allow extending the DRMP AVP.  Rather we require= that any extension require a new AVP.  We can then leave it to the do= cument that proposes the extension to deal with determining whether send th= e DRMP AVP or the newly defined DRMPv2 AVP. 
[JL] When we proposed that the range be exten= ded to 16, we thought that ‘16’ was large enough and future pro= of.

I am okay with having = an extensibility bit, if other companies want it. That said, I agree that i= t has a low probability of being used and added complexity.

[JJ] JJ I also agree t= hat with 16 values , the offered range is large enough in practice. This po= int is only to check if it would be easy to do an extension, if we have thi= s requirement in the future.  I agree with Steve that for an extensibility, it will require a new AVP in a new d= ocument rather than to define a set of reserved values in the DRMP AVP. &nb= sp;A point is that it will require an additional parsing effort for a node = to look for this second AVP even if it is not present most of the time.  

 

SRD> I agree that I don't see value in the +9= to -9 proposal.

[JL] Agreed

[J] I presented this seco= nd  approach  so to review the possible alternatives as we usuall= y do before selecting the solution, this alternative being already used in a recent RFC.   That being said, I am fine with the enum= erated DRMP AVP.

 

Best regards<= /o:p>

 

JJacques  

 

From: DiME [mailto:dime-bounce= s@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Thursday, October 22, 2015 9:39 AM
To: dime@ietf.org=
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

Hi

 

1.      PRIORITY_14 as default priority value onl= y allows one level of lower priority (PRIORITY_15)  than the default o= ne; this seems not enough.  As use cases, we may have  some Machine type Communication (LTC) devices that may have lower priorities th= at normal communications without priority.  Even within a Diameter app= lication, some commands may have a lower priority as having a secundary imp= ortance.

 =

Then which default  value ?

- &nbs= p;      it could be PRIORITY_8 in the middle, or = if we prefer to have a  larger range for higher priorities  than = for lower priorities,  the default value could be  e.g. PRIORITY_= 10,  giving 9 higher priorities and 5 lower priorities than the default one. I = would have a preference for this value PRIORITY_10.

 

2.      About extensibility, the current range of= 16 values is already large, but we can have  a reserved value to indi= cate a further extension. With  an enumerated AVP, there is no possibility to add new values. 

 

3.      I also had a look to some other IETF RFCs= addressing priorities that Ken mentioned, so to see if we can benefit from= these approaches although done for different contexts.

- &nbs= p;      in RFC 4412 (Resource-Priority Header in = SIP), wps and ets namespaces have a range of 5 values (0 to 4) with 0 as th= e highest priority  . But I have not found some indication  (I may have missed it) about the default priority  (I mean a SIP requ= est without  Resource-Priority Header compared  to a SIP request = with the Header). Implicitly, I would assume a SIP request without  Re= source-Priority Header corresponds to  the lowest priority.  DRMP has a similar approach but with  a larger range and also l= ower priorities.

 

- &nbs= p;      RFC  6710 (priority for SMTP),  = ;uses another encoding of the priority values with an integer between -9 an= d +9. Lower priorities  are negative an higher priority being posi= tive. When a value increases, it means a higher priority, so the opposite  = to DRMP, wps or ets.  But the value 0 is here naturally the default va= lue. So this is an encoding alternative  to the  Enumerated type = of the DRMP AVP which avoids the question of the default value.

Note: RFC  67= 10 also defines some Priority Assignment Policies using a subset of the ran= ge.

 

   SMTP server= s compliant with this specification are not

   required to supp= ort all 19 distinct priority levels (i.e., to treat

   each priority va= lue as a separate priority), ….  That is, an

   implementation t= hat only supports N priority levels (where N < 19)

   will internally = round up a syntactically valid priority value that

   isn't supported = to the next higher supported number (or to the

   highest supporte= d priority, if the value is higher than any supported priority).

- &nbs= p;      This raises the question to have this typ= e of  guideline if considered useful.

 

So to have your feedback

 

Best regards<= /o:p>

 

JJacques

 

De : DiME= [mailto:dime-bounces@ietf.org] De la part de DOLLY, MARTIN C
Envoy=E9 : jeudi 15 octobre 2015 12:33
=C0 : Lee, Jay; ken carlberg; Steve Donovan
Cc : dime@ietf.org
Objet : Re: [Dime] diff-serb and two other ideas (was Re: [dime= ] #92 (drmp): Range of priority levels)

 

A couple thoughts:=

1. &nb= sp;    There needs to be a default value defined= by the standard, so that equipment have the same value leaving the factory=

2. &nb= sp;    This value can be over written based on l= ocal policy

3. &nb= sp;    Should have an extensibility bit in order= to and more values in the future

 

 

From: DiME [= mailto:dime-boun= ces@ietf.org] On Behalf Of Lee, Jay
Sent: Thursday, October 15, 2015 6:16 AM
To: ken carlberg <carlberg@g11.org.uk>; Steve Donovan <srdonovan@usdonovans.com&= gt;
Cc: dime@ietf.org=
Subject: Re: [Dime] diff-serb and two other ideas (was Re: [dime] #9= 2 (drmp): Range of priority levels)

 

From my side, some more d= iscussion on Steve’s mail may be needed.

 

‘Should’ vs. = ‘Must’:

One can say that ‘S= hould’ is not mandatory. But, in practice, this is a fairly strong st= atement, and often taken as required. So in this sense, the proposed Note is certainly helpful. But, since we allow operators to override the v= alue, I don’t see the reason why we use ‘Should’. My sugg= estion is using ‘May’.

 

PRIORITY_14 priority:

Since operators can overw= rite it, I was not too concerned about it. But if we want to put some value= , why ‘14’? A value lower than 14 is suggested in order to allow more rooms for lower priorities.

 

Jay

 

From: DiME [mailto:dime-bounce= s@ietf.org] On Behalf Of ken carlberg
Sent: Wednesday, October 14, 2015 8:40 AM
To: Steve Donovan
Cc: dime@ietf.org=
Subject: [Dime] diff-serb and two other ideas (was Re: [dime] #92 (d= rmp): Range of priority levels)

 

with respect to the diff-serv example brought up bel= ow, some thing to add to that discussion is that it starts off with separat= e and distinct forwarding behavior whose marked packets provide segmentatio= n of other IP traffic.  The availability of only 6 bits to play with (along with the headaches of transitive trust)= also discouraged a line of thought to define end-to-end priority handling = versus a per diff-serv domain treatment.  RFC-4594 did provide configu= ration guidelines, but that’s a different story.

 

So back to a couple of ideas to consider.=

 

1) reserved space.  if we go back to the diff-s= erv model, the diff-serv working group agreed to set aside a set of values = that was reserved for experimental use that could be re-assigned some time = in the future.  I’m not suggesting that there should be space set side for experiments, but rather it may be prude= nt to set aside a reserved set of bits/values so that one doesn't need to d= efine a new AVP if in the future there was a need to define added values be= yond the 5 (plus some fudge factor) already mentioned on the list. 

 

2) sets of users.  previous work (e.g., rfc-441= 2, rfc-6710) recognized that there can be several sets of users/services th= at are distinct from each other and yet need to prioritize the traffic. &nb= sp;I bring this up because the draft already identifies two sets of users in sections 5.1 and 5.2 (note: I’m assu= ming that the latter is aimed at the general public and related to 911/112/= 999 type calls, which should probably be more specific in the draft).  = ;And there is also the potential of Firstnet users in the US.

 

As a side note, the distinction and separation of ge= neral public and other prioritized users in public phone infrastructures is= not exclusive to the US, so the group should not be concerned that this is= a US centric effort.  There has been GTPS in the UK, as well as other systems in other countries.  The RFC= is a bit dated, but feel free to go over rfc-4190 for added background.

 

and just to reiterate.  I’m not making re= commendations in the above — just bringing up some food for thought.<= o:p>

 

-ken

 

 

On Oct 14, 2015, at 10:12 AM, Steve Donovan <srdonovan@usdonov= ans.com> wrote:

 

Jay,

The current text is a SHOULD level require= ment:

   When there is a mix of transa= ctions specifying priority in request
   messages and transactions tha= t do not have the priority specified,
   transactions that do not have= a specified priority SHOULD be treated
   as having the PRIORITY_14 pri= ority.

As such, operators can choose to either no= t implement a priority or define a different value for their network.

I propose adding the following note after = this paragraph to further explain why it is a SHOULD and not a MUST:=

      Note: There= are scenarios where operators might want to 
      specify a d= ifferent default value for transactions that do not
      have an exp= licit priority.  In this case, the operator defined
      local polic= y would override the use of PRIORITY_14 as
      the default= priority.

This leaves the ability for there to be de= terministic behavior in Diameter networks that require a default to be defi= ned and are happy with the specified default.  It also gives operators= the ability to define a different behavior, most likely with some priority handling/mapping at the edge of the network= .

Does this address your concerns?
Regards,

Steve

On 10/14/15= 2:59 AM, Lee, Jay wrote:

 

 

 

 

 

 

 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Tuesday, Oct= ober 13, 2015 10:55 AM
To: Shaikh, Viqar = A; Janet P Gunn; DOLLY, MARTIN C
Cc: DiME; <= a href=3D"mailto:dime@ietf.org" target=3D"_blank">dime@ietf.org<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">; Pollini, Gregory P
Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 

=B7     &nbs= p; 1) ULR with Prio-0

=B7     &nbs= p; 2) ULR with Prio-1

=B7     &nbs= p; 3) ULR with Prio-2

=B7     &nbs= p; 4) ULR with no priority AVP

 

 

 

 

 

 

De :<= /span> Shaikh, Viqar A [mailto:vshaikh@a= ppcomsci.com] 
Envoy=E9 : sa= medi 3 octobre 2015 01:21
=C0 : MORAND = Lionel IMT/OLN; Janet P Gunn; DOLLY, MARTIN C
Cc : DiME; dime@ietf.org; Pollini, Gregory P
Objet : RE: [= Dime] [dime] #92 (drmp): Range of priority levels

 

Hello all,

 

Note tha= t the 3GPP priority, e.g., Priority-Level AVP (ARP AVP) in TS 29.212 t= akes 15 values, value 1 the highest, 15 the lowest, and value 0 not defined.

 

Having 15 rat= her than 16 would be useful from an interworking point of view on Diameter = interfaces connecting to the EPS.  

 

Also, my unde= rstanding has been that the default value is per local policy. 

 

My 2 cents....

Viqar 

<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">From: DiME [dime-bounces@i= etf.org] on behalf of lionel.morand@orange.com [lionel.= morand@orange.com]
Sent: Thursday, Oc= tober 01, 2015 3:36 AM
To: Janet P Gunn; = DOLLY, MARTIN C
Cc: DiME; dime@ietf.org
Subject: Re: [Dime= ] [dime] #92 (drmp): Range of priority levels

 

 

 

Regards,

 

Lionel

 

 

De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn
Envoy=E9 : me= rcredi 30 septembre 2015 22:53
=C0 : DOLLY, = MARTIN C
Cc : DiME; dime@ie= tf.org
Objet : Re: [= Dime] [dime] #92 (drmp): Range of priority levels

 

Same here. &nb= sp;The "default priority" should be a matter of local policy. 

Janet

This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreement or government initiative exp= ressly permitting the use of e-mail for such purpose. 



From:        &= quot;DOLLY, MARTIN C" <md31= 35@att.com> 
To:        S= teve Donovan <srdonova= n@usdonovans.com>, "dime@ietf.org" <dime@ietf.org>&nbs= p;
Date:        0= 9/30/2015 04:40 PM 
Subject:        Re: [Dime] [dime] #92 (drmp): Range of priority levels 
Sent by:        "DiME" <dime-= bounces@ietf.org>




Me as well 
  
From: DiME [mailto:dime-bounces@iet= f.org]=  On Behalf Of Steve Dono= van
Sent: Wednesday, Sept= ember 30, 2015 4:38 PM
To: dime@ietf.org Subject: = ;Re: [Dime] [dime] #92 (drmp): Range of priority= levels 
  
I'm okay with Jay's proposal on not specifying a default value= .

Steve 
On 9/30/15 3:27 PM, Lee, Jay wrote: 
Hi Steve and all,=  
  
For the first proposal, as I indicated, I support increasing t= he number of priority levels up to 16. 
  
I am also fine with the second proposal. My question is: do we= need to mandate this feature, as individual operators have different situa= tions? Perhaps some flexibility should be allowed? Instead of mandating it, we can include the statement that when there is no DRMP A= VP, this correspond to ‘normal traffic’ without a particular hi= gh or low priority. Then each operator can map this default to a value (e.g= ., 8 or something else) that they feel appropriate. 
  
Thanks, 
  
Jay <= br>


__________________________________________= _____ 
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 d=
es informations confidentielles ou
privilegiees et ne doivent donc
pas etre
diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce
message par erreur, veuillez le signa=
ler
a l'expediteur

et le detruire ainsi que les pieces j=
ointes. Les messages electroniques


etant susceptibles d'alteration,


Orange decline

toute responsabilite si ce message a =
ete altere, deforme ou falsifie.


Merci.


 


This message


and its attachments may contain confidential or p=
rivileged 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 s=
ender and delete this


message and its attachments.

As emails may


be altered, Orange is not liable for messages tha=
t have been modified,


changed or falsified.


Thank


you.


_____________________________________=
___________________________________________________________________________=
_________
 
Ce message et
ses pieces jointes peuvent contenir d=
es informations confidentielles ou
privilegiees et ne doivent donc
pas etre
diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce
message par erreur, veuillez le signa=
ler
a l'expediteur

et le detruire ainsi que les pieces j=
ointes. Les messages electroniques


etant susceptibles d'alteration,


Orange decline

toute responsabilite si ce message a =
ete altere, deforme ou falsifie.


Merci.


 


This message


and its attachments may contain confidential or p=
rivileged 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 s=
ender and delete this


message and its attachments.

As emails may


be altered, Orange is not liable for messages tha=
t have been modified,


changed or falsified.


Thank


you.


&nbs=
p;


_______________________________________________


DiME mailing


list


DiME@ietf.org

https://www.ietf.org/m=
ailman/listinfo/dime


__________________________________________= _____
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailm= an/listinfo/dime

 

 

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

 

_____________________= __________________________
DiME mailing list
DiME@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dime

--_000_C026C31E3CD6CA43953D6D95AB48048004A38CCASAC1EXP009uswin_--